Quelle est la différence entre 5.6 et 5.5 dans MySQL

Différences : 1. Dans la version 5.5, les paramètres binlog et POS ne peuvent pas être omis dans la configuration maître-esclave, mais dans la version 5.6, ces deux paramètres peuvent être omis ; 2. Dans la version 5.5, la réplication multi-thread n'est pas prise en charge ; , et la réplication synchrone est constituée de threads et de files d'attente uniques, et la réplication multithread est prise en charge dans la version 5.6.

L'environnement d'exploitation de ce tutoriel : système windows10, version mysql8.0.22, ordinateur Dell G3.

Quelle est la différence entre 5.6 et 5.5 dans MySQL ?

Améliorations dans 5.6 :

1 Dans 5.5 et les versions précédentes de MySQL, pour la configuration maître-esclave, changez master pour qu'il soit configuré sur le nœud esclave pour indiquer binlog. et PLV. Dans la version 5.6 et versions ultérieures, ces deux paramètres peuvent être omis. MySQL peut trouver automatiquement des points de synchronisation via le mécanisme GTID interne. Il nous suffit de spécifier l'adresse IP, le nom d'utilisateur, le mot de passe et le port du maître.

2.5.6 prend en charge la réplication multithread

Dans la version 5.5, la réplication synchrone est monothread et mise en file d'attente et ne peut être exécutée qu'une par une. Dans la version 5.6, plusieurs bibliothèques peuvent être copiées en même temps (remarque : le multithreading n'est toujours pas autorisé dans la même bibliothèque).

Le paramètre UUID sera impliqué dans 5.6

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

Remarque : cet UIID sera automatiquement généré au premier démarrage de MySQL et écrit dans auto.cnf. Les responsables ne recommandent pas de modifier cette valeur. Et server_uuid et GTID sont étroitement liés.

GTID : Identifiant global de transaction

Lors de l'utilisation de cette fonction, chaque soumission de transaction générera un identifiant unique dans le journal binaire, composé de l'UUID et de l'ID de transaction. L'ID de transaction soumis pour la première fois est 1, et il augmente séquentiellement par la suite.

Lorsque GTID est activé, il n'est pas nécessaire de trouver le journal binlog et le point POS lorsque l'esclave effectue une réplication synchrone. Méthode d'écriture directe

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;

Si vous avez déjà activé GTID, vous ne pouvez plus utiliser la méthode traditionnelle de changement maître en, et une erreur sera signalée, comme suit :

ERROR 1776 (HY000) : Paramètres MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE et RELAY_LOG_POS ne peuvent pas être définis lorsque MASTER_AUTO_POSITION est actif.

Workflow GTID :

1. Soumettez une transaction sur le maître et écrivez-la dans le binlog

2. l'esclave reçoit et écrit le journal de relais Enter, l'esclave lit ce GTID et définit la valeur de gtid_next. Par exemple :

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

Dites ensuite à l'esclave que la prochaine transaction doit utiliser GTID et l'écrire dans son propre binlog.

3. L'esclave vérifie et confirme que le gtid n'est pas utilisé, alors il commence à exécuter la transaction et l'écrit dans son propre binlog.

4. Puisque la valeur de gtid_next n'est pas vide, l'esclave n'essaiera pas de générer un nouveau gtid, mais obtiendra le GTID via la synchronisation maître-esclave.

De plus, si vous souhaitez utiliser la méthode GTID pour la synchronisation maître-esclave, vous devez également ajouter la configuration suivante à my.cnf :

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

Ensuite, exportez mysqldump -uroot -proot -q --single-transaction -R - sur le maître E --triggers -B hellodb > /root/hello.sql

Importer mysql sur l'esclave -uroot -proot < lignes de code ci-dessous) :

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

Limitations du GTID :

1. La réplication du GTID est basée sur les transactions et ne prend pas en charge MyISAM, ce qui peut entraîner l'attribution de plusieurs GTID à la même transaction.

2. L'instruction create table...select n'est pas prise en charge. Parce que cette instruction sera divisée en deux transactions : créer une table et insérer, et si ces deux transactions se voient attribuer le même GTID, l'insertion sera ignorée par la base de données de secours.

3. La création et la suppression de tables temporaires ne sont pas prises en charge

Démonstration de réplication multithread :

Exécutez les commandes suivantes sur l'esclave :

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

S'il y a un grand nombre d'opérations d'insertion sur le maître à ce moment. , vous pouvez les exécuter sur le slave> ; select * from mysql.slave_worker_infoG Vous devriez pouvoir voir que le worker_id change constamment, indiquant que la réplication multithread fonctionne.

Explication : slave_parallel_workers peut réaliser une réplication simultanée multithread sur l'esclave. Cependant, il ne peut prendre en charge la réplication simultanée qu'entre plusieurs bases de données sous une seule instance et ne peut pas réellement réaliser la réplication simultanée de plusieurs tables. Par conséquent, lorsqu'il y a une charge simultanée importante, l'esclave ne peut toujours pas rattraper le maître à temps et doit trouver des moyens d'optimiser (par exemple : essayez de diviser une table dans une bibliothèque en plusieurs bibliothèques selon la logique métier pour économiser , afin que lors des opérations d'écriture, l'esclave puisse activer la réplication multithread, réduisant ainsi le délai de synchronisation.)

De plus, il est recommandé de modifier my.cnf et d'ajouter 2 lignes (le fichier info_file par défaut est un fichier et n'est pas écrit à la base de données)

relay_log_info_repository = table
master_info_repository = table

Cela seul ne suffit pas, ces deux tables sont MyISAM par défaut. Si ce n'est pas sûr, vous devez les convertir

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

De cette façon, vous pouvez éviter que la table ne soit endommagée, et vous. Vous pouvez le réparer vous-même après qu'il soit endommagé.

Réplication maître-esclave en mode GTID, la solution à l'erreur incontournable lors de la synchronisation :

Si vous voyez l'erreur de synchronisation "La clé XXX du nœud esclave n'existe pas" sur l'esclave

Nous pouvons essayer de utilisez l'ancienne méthode sur 5.5

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

Vous trouverez une erreur lors de l'exécution, l'invite est la suivante :

可以看出运行在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视频教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!