Apakah perbezaan antara 5.6 dan 5.5 dalam mysql

Perbezaan: 1. Dalam versi 5.5, parameter binlog dan POS tidak boleh ditinggalkan dalam konfigurasi hamba induk, tetapi dalam versi 5.6, kedua-dua parameter ini boleh diabaikan. Dalam versi 5.5, berbilang benang replikasi tidak disokong. Replikasi segerak adalah satu-benang dan beratur, manakala replikasi berbilang benang disokong dalam versi 5.6.

Persekitaran pengendalian tutorial ini: sistem Windows 10, versi mysql8.0.22, komputer Dell G3.

Apakah perbezaan antara 5.6 dan 5.5 dalam mysql

Peningkatan dalam 5.6:

1 Dalam versi 5.5 dan mysql sebelumnya, konfigurasi master-slave mesti dilakukan dalam konfigurasi Node hamba tukar induk untuk menentukan binlog dan POS. Dalam 5.6 dan kemudian

, kedua-dua parameter ini boleh diabaikan. MySQL secara automatik boleh mencari titik penyegerakan melalui mekanisme GTID dalaman. Kami hanya perlu menentukan IP tuan, nama pengguna dan kata laluan, dan port.

2. 5.6 menyokong replikasi berbilang benang

Dalam 5.5, replikasi segerak adalah satu-benang dan beratur, dan hanya boleh dilaksanakan oleh satu. Dalam 5.6, berbilang perpustakaan boleh disalin pada masa yang sama (nota: multi-threading masih tidak dibenarkan dalam perpustakaan yang sama).

5.6 akan melibatkan parameter UUID

MySQL [(none)]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | ca910cf0-3aec-11e6-9319-b888e3dcfeb8 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

Nota: UIID ini akan dijana secara automatik apabila mysql mula-mula dimulakan dan ditulis ke auto.cnf . Dan server_uuid dan GTID berkait rapat.

GTID: Pengecam transaksi global

Apabila menggunakan fungsi ini, setiap penyerahan transaksi akan menjana pengecam unik dalam binlog, yang terdiri daripada UUID dan ID transaksi. ID transaksi yang diserahkan buat kali pertama ialah 1, dan ia meningkat secara berurutan selepas itu.

Apabila GTID didayakan, hamba tidak perlu mencari log binlog dan titik POS apabila melakukan replikasi segerak. Terus

Tulisan GTID:

change master to
master_HOST=192.168.2.100,
master_PORT=2206,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;
另外传统的写法：
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

Jika GTID telah didayakan sebelum ini, anda tidak boleh lagi menggunakan kaedah induk perubahan tradisional dan ralat akan dilaporkan, seperti berikut:

RALAT 1776 (HY000): Parameter MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE dan RELAY_LOG_POS tidak boleh ditetapkan apabila MASTER_AUTO_POSITION aktif.

🎜>🎜>GTID 1. Hantar transaksi pada tuan dan tuliskannya ke binlog

2. Binlog dihantar kepada hamba menerima dan menulis log geganti Hamba membaca GTID dan menetapkan nilai gtid_next . Contohnya:

set @@SESSION.GTID_NEXT='B0869D03-D332223-35454:3';

Kemudian beritahu hamba bahawa transaksi seterusnya mesti menggunakan GTID dan tulis ke binlognya sendiri .

3. Hamba menyemak dan mengesahkan bahawa gtid tidak digunakan, maka ia mula melaksanakan transaksi dan menulisnya ke binlognya sendiri.

4. Memandangkan nilai gtid_next tidak kosong, hamba tidak akan cuba menjana gtid baharu, tetapi memperoleh GTID melalui penyegerakan tuan-hamba.

Selain itu, jika anda ingin menggunakan kaedah GTID untuk penyegerakan master-slave, anda juga mesti menambah konfigurasi berikut pada my.cnf:

Kemudian eksport mysqldump -uroot - proot pada master -q --single-transaction -R -E --triggers -B hellodb > /root/hello.sql

[mysqld]
log-bin=mysql-bin
binlog_format = mixed
log_slave_updates = ON
gtid-mode = ON
enforce_gtid_consistency = ON

Import mysql pada slave -uroot -proot < sql

Konfigurasikan induk tukar untuk menunjuk pada hamba (6 baris kod berikut):

Penghadan GTID:

change master to
master_HOST=192.168.2.100,
master_PORT=3306,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;

1 pada urus niaga dan tidak Menyokong MyISAM, yang boleh menyebabkan berbilang GTID diberikan setiap satu dalam transaksi yang sama.

2. Cipta jadual...penyataan pilih tidak disokong. Oleh kerana penyata ini akan dibahagikan kepada dua transaksi: buat jadual dan sisipkan, dan jika kedua-dua transaksi ini diberikan GTID yang sama, sisipan akan diabaikan oleh pangkalan data siap sedia.

3. Penciptaan dan pemadaman jadual sementara tidak disokong

Demonstrasi replikasi berbilang benang:

Laksanakan arahan berikut pada hamba:

Jika terdapat sejumlah besar operasi sisipan pada master pada masa ini, anda boleh melaksanakan > replikasi benang berfungsi.

> stop slave;
> set global  slave_parallel_workers = 4;
> start slave;
> show full processlist;可以看到有4个线程 Waitingfor an eventfromCoordinator

Penjelasan: slave_parallel_workers boleh mencapai replikasi serentak berbilang benang pada hamba. Walau bagaimanapun, ia hanya boleh menyokong replikasi serentak antara berbilang pangkalan data di bawah satu contoh, dan tidak boleh benar-benar mencapai replikasi serentak berbilang jadual. Oleh itu, apabila terdapat beban serentak yang besar, hamba masih tidak dapat mengejar tuan dalam masa, dan perlu mencari cara untuk mengoptimumkan (contohnya: cuba bahagikan jadual dalam satu perpustakaan kepada berbilang perpustakaan mengikut logik perniagaan untuk menyimpan mereka, supaya semasa operasi tulis, Hamba boleh memulakan replikasi berbilang benang, mengurangkan kelewatan penyegerakan)

Selain itu, disyorkan untuk mengubah suai my.cnf dan menambah 2 baris (secara lalai, fail_info ini ialah fail dan tidak ditulis ke pangkalan data)

Ini sahaja tidak mencukupi, kedua-dua jadual ini adalah MyISAM Jika tidak selamat, anda perlu menukarnya

relay_log_info_repository = table
master_info_repository = table

Dengan cara ini, anda boleh mengelakkan kerosakan meja dan anda boleh membaikinya sendiri selepas kerosakan.

> alter table slave_master_info engine innodb;
> alter table slave_relay_log_info engine innodb;
> alter table slave_worker_info engine innodb;

Replikasi induk-hamba dalam mod GTID, penyelesaian kepada ralat yang tidak boleh dilangkau semasa penyegerakan:

Jika anda melihat ralat penyegerakan pada hamba "Kunci XXX nod hamba tidak tidak wujud"

Kita boleh cuba menggunakan kaedah lama pada 5.5

Apabila melaksanakan, anda akan mendapati ralat, gesaan adalah seperti berikut:

> stop slave;
> set global sql_slave_skip_counter=1
> start slave;

可以看出运行在GTID模式下，不支持sql_slave_skip_counter这种方式跳过的。

那么可以如下方法来跳过：

> show slave status\G查看如下2行的信息：

Retrieved_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1-2
Executed_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1

第一行表示收到的事务，第二行表示已经执行完的事务。也就是说执行到Retrieved_Gtid_Set时候发生错误了。

因此，我们直接单单跳过这个事务即可。

> stop slave;
> set GTID_NEXT='ca910cf0-3aec-11e6-9319-b888e3dcfeb8:2';     就是这种写法,不要加什么1-2这些玩意
> begin;
> commit;
> set GTID_NEXT="AUTOMATIC";      #把gtid_next设置回来
> start slave;
> show slave status\G   验证下是否IO/SQL都是YES状态。

GTID模式转换为传统模式的方法及注意点：

要转换成传统模式，需要在my.cnf里面注释掉下面2行：

# gtid-mode=ON
# enforce_gtid_consistency = ON

然后重启MySQL。

登进mysql，执行类似如下命令：

> stop slave;
> CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

结果报错了，如下图：

解决方法：

> change master to MASTER_AUTO_POSITION=0;     # 关闭这个参数，这个参数是GTID复制才用到的。
> CHANGE MASTER TO
MASTER_HOST = '192.168.2.11',
MASTER_USER='repluser',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=500,
MASTER_CONNECT_RETRY=10;
> start slave;
> show slave status\G 验证下是否IO/SQL都是YES状态。

推荐学习：mysql视频教程

Atas ialah kandungan terperinci Apakah perbezaan antara 5.6 dan 5.5 dalam mysql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!