Construire un cluster InnoDB à partir de mysql 5.7 sur centos 7

Bonjour à tous!

Une fois qu'une tâche est apparue sur le travail - il semble y avoir un cluster de test innoDB configuré sur plusieurs machines virtuelles avec centos 7.5, vous devez l'étudier et ajouter quelques nœuds supplémentaires. Vous pouvez vous casser et vous moquer à votre guise. Cela semble tentant.

Avant cela, je n'avais aucune expérience avec un tel cluster, mais Google pour vous aider.
À quelques exceptions près, tous les liens qu'il contient et dans Yandex se trouvaient soit sur dev.mysql.com, soit sur cet article sur Habr . Il semble qu'un cluster de deux nœuds ait été configuré dessus.

Eh bien, j'ai lu l'article, j'ai été quelque peu surpris de la complexité de l'ajout de nœuds et du manque de nombreux détails, mais bon. Avec un péché, j'ai ajouté la moitié d'un nouveau nœud (certaines commandes n'étaient pas utiles, certaines cassaient généralement tout), après quoi j'ai commencé à expérimenter avec le redémarrage des nœuds, etc.

Après plusieurs approches et d'innombrables morts de cellules nerveuses, le cluster n'a pas pu le supporter. Un nœud ne voulait en aucun cas être ajouté, l'autre raccrochait lors de toute tentative d'accès à la base de données, le troisième prétendait que tout était en ordre. J'ai dû tirer et repartir de zéro.

Lors de la création d'un nouveau cluster, malheureusement, de nombreux problèmes et incohérences sont apparus. Peut-être que le point est dans les versions logicielles, j'ai essayé mysql 5.7. Peut-être dans la distribution. En conséquence, j'ai arrêté les tentatives irréfléchies de tout faire sur un morceau de papier et j'ai commencé à le configurer en tapant. Et google.

Quelques soirées et nuits agréables et le groupe se sont rassemblés et ont même refusé de s'effondrer.
En même temps, la méthode de sa création était sensiblement différente des tentatives précédentes et je voulais la partager, car Sur Internet, je n'ai pas trouvé d'autres instructions compréhensibles détaillées pertinentes pour la configuration du cluster inndoDB.

Nous avons donc trois machines virtuelles identiques avec le Centos 7.5 minimal 1804 nouvellement installé et selinux et firewalld désactivés:

1.1.1.1
1.1.1.2
1.1.1.3

Pour le travail, j'ai utilisé mysql 5.7, nous l'utilisons donc. Commençons par 1.1.1.1:

1. Installez le dépôt mysql-community:

rpm -i https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm 

Désactivez le référentiel pour 8, allumez-le pour 5.7 et vérifiez - si tout va bien, installez mysql:

 yum install yum-utils yum-config-manager --disable mysql80-community yum-config-manager --enable mysql57-community yum repolist yum install mysql-community-server mysql-shell 

2. Nous apportons /etc/my.cnf à ce formulaire:

 [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock symbolic-links=0 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid bind-address=0.0.0.0 port=3301 # Replication part server_id=1 gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW plugin-load = group_replication.so # Group replication part transaction_write_set_extraction=XXHASH64 loose-group_replication_start_on_boot = OFF loose-group_replication_local_address = 1.1.1.1:33011 loose-group_replication_bootstrap_group = OFF report_port = 3301 report_host = 1.1.1.1 

Ici 3301 est le port sur lequel mysql écoutera, et 33011 est le port sur lequel les nœuds communiquent entre eux.

3. Lancez mysql et effectuez la configuration préliminaire:

 systemctl start mysqld grep 'password' /var/log/mysqld.log mysql_secure_installation 

4. Eh bien, créez un cluster, ainsi qu'un utilisateur distinct pour le gérer. Si vous connaissez à l'avance les adresses IP des nœuds, vous pouvez immédiatement les répertorier dans ipWhitelist. Nous prétendons que nous ne connaissons pas encore 1.1.1.2. et 1.1.1.3:

 mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.1:3301 > dba.checkInstanceConfiguration() > cl=dba.createCluster('TestCluster', {ipWhitelist: '1.1.1.1'}) > dba.configureLocalInstance() > cl.status() 

C'est fait! cl.status devrait produire quelque chose comme ceci:

 { "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" } 

Lors du changement de cluster, il sera nécessaire d'exécuter la commande dba.configureLocalInstance () localement sur tous les nœuds pour enregistrer les modifications:

 WARNING: On instance '1.1.1.1:3301' membership change cannot be persisted since MySQL version 5.7.23 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the <Dba>.configureLocalInstance command locally to persist the changes. 

Parce que nous allons ajouter quelques nœuds supplémentaires, nous ne fermons pas la connexion avec le serveur 1.1.1.1, cela nous sera utile.

Essayons maintenant d'ajouter le nœud 1.1.1.2 au cluster. Pour ce faire, nous y exécutons toutes les mêmes commandes jusqu'à 3 étapes inclus, sans oublier de changer server_id, loose-group_replication_local_address et report_host.

4. Nous exécutons le 1.1.1.2:

 mysql -p > set GLOBAL group_replication_allow_local_disjoint_gtids_join=ON; 

J'ai essayé de définir cette variable via mysqlsh, en passant en mode sql, mais les actions ne l'ont pas affectée dans mysql. Suivant:

 mysqlsh > \c 127.0.0.1:3301 > dba.configureLocalInstance("127.0.0.1:3301", {mycnfPath: "/etc/my.cnf", clusterAdmin: "cladmin", clusterAdminPassword: "SomePassword!123"}) > \c cladmin@1.1.1.2:3301 > dba.checkInstanceConfiguration() 

5. Revenez au premier nœud 1.1.1.1. Si vous avez fermé la connexion, vous pouvez vous connecter rapidement au cluster comme ceci:

 mysqlsh --uri cladmin@1.1.1.1:3301 --cluster > \sql > STOP GROUP_REPLICATION; > SET GLOBAL group_replication_ip_whitelist="1.1.1.1,1.1.1.2"; > START GROUP_REPLICATION; > \js > cluster.addInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2'}) > cluster.status() 

Pour une raison quelconque, lors de l'ajout d'un nœud sans l'option ipWhitelist, il ne lui est pas automatiquement transmis, nous le spécifions donc manuellement.
Si votre liste blanche est initialement configurée pour tous les nœuds ou un sous-réseau, les commandes en mode SQL peuvent être ignorées.

N'oubliez pas d'exécuter dba.configureLocalInstance () sur tous les nœuds pour enregistrer la configuration.

Le cluster de leurs deux nœuds s'est avéré:

 { "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE", "statusText": "Cluster is NOT tolerant to any failures.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" } 

Eh bien, il y a un cluster de deux nœuds, mais dans le "Cluster n'est PAS tolérant aux pannes". Mode
Ajoutez un troisième, l'algorithme est fondamentalement le même que l'ajout d'un deuxième.

Si vous devez à nouveau modifier la liste blanche, vous devez exécuter les commandes sur le nœud r / w, car sur les nœuds R / O, cela ne semble pas conduire à quoi que ce soit. Dans ce cas, les nœuds R / O tomberont et ils devront être reconnectés, signalant simultanément une nouvelle liste blanche.
Dans notre cas:

 > cluster.rejoinInstance('cladmin@1.1.1.2:3301', {ipWhitelist: '1.1.1.1,1.1.1.2,1.1.1.3'}) 

Eh bien, encore une fois, n'oubliez pas d'exécuter dba.configureLocalInstance () sur tous les nœuds pour enregistrer la configuration.

Un cluster de trois nœuds ressemble à ceci:

 { "clusterName": "TestCluster", "defaultReplicaSet": { "name": "default", "primary": "1.1.1.1:3301", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "1.1.1.1:3301": { "address": "1.1.1.1:3301", "mode": "R/W", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.2:3301": { "address": "1.1.1.2:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" }, "1.1.1.3:3301": { "address": "1.1.1.3:3301", "mode": "R/O", "readReplicas": {}, "role": "HA", "status": "ONLINE" } } }, "groupInformationSourceMember": "mysql://cladmin@1.1.1.1:3301" } 

Si le cluster s'est effondré à l'état d'un nœud, il devra être démarré avec le paramètre loose-group_replication_bootstrap_group = ON dans /etc/my.cnf
Après le démarrage, le paramètre devra être désactivé à nouveau, sinon ce nœud sera toujours séparé du cluster et conservera le sien.

L'installation de mysql-router est bien décrite ici , donc je ne vois aucun sens à la duplication.

C'est tout, c'est tout, j'espère que quelqu'un trouvera mon expérience utile.

Merci de votre attention.