MySQL ne limite pas le nombre d'esclaves que vous pouvez connecter au serveur maître dans une topologie de réplication. Cependant, à mesure que le nombre d'esclaves augmente, ils auront un impact sur les ressources maîtres car les journaux binaires devront être servis à différents esclaves travaillant à des vitesses différentes. Si l'attrition des données sur le maître est élevée, le service des journaux binaires à lui seul peut saturer l'interface réseau du maître.
Une solution classique à ce problème consiste à déployer un serveur binlog – un serveur proxy intermédiaire qui se trouve entre le maître et ses esclaves. Le serveur binlog est configuré en tant qu'esclave du maître et, à son tour, agit en tant que maître de l'ensemble d'esclaves d'origine. Il reçoit les événements du journal binaire du maître, n'applique pas ces événements, mais les sert à tous les autres esclaves. De cette façon, la charge sur le maître est considérablement réduite, et en même temps, le serveur binlog sert les binlogs plus efficacement aux esclaves puisqu'il n'a pas à faire d'autre traitement de serveur de base de données.
Ripple est un serveur binlog open source développé par Pavel Ivanov. Un article de blog de Percona, intitulé MySQL Ripple :La première impression d'un serveur MySQL Binlog, donne une très bonne introduction au déploiement et à l'utilisation de Ripple. J'ai eu l'occasion d'explorer Ripple plus en détail et je voulais partager mes observations à travers ce post.
1. Prise en charge de la réplication basée sur GTID
Ripple ne prend en charge que le mode GTID, et non la réplication basée sur les fichiers et la position. Si votre maître s'exécute en mode non-GTID, vous obtiendrez cette erreur de Ripple :
Échec de la lecture du paquet :une erreur s'est produite lors de la lecture du paquet du serveur :le thread d'envoi de la réplication ne peut pas démarrer en mode AUTO_POSITION :ce serveur a GTID_MODE =OFF au lieu de ON.
Vous pouvez spécifier Server_id et UUID pour le serveur ripple à l'aide des options de la ligne cmd : -ripple_server_id et -ripple_server_uuid
Les deux sont des paramètres facultatifs, et s'ils ne sont pas spécifiés, Ripple utilisera le server_id=112211 par défaut et l'uuid sera généré automatiquement.
2. Connexion au maître à l'aide de l'utilisateur et du mot de passe de réplication
Lors de la connexion au maître, vous pouvez spécifier l'utilisateur et le mot de passe de réplication à l'aide des options de ligne de commande :
-ripple_master_user et -ripple_master_password
3. Point de terminaison de connexion pour le serveur Ripple
Vous pouvez utiliser les options de ligne de commande -ripple_server_ports et -ripple_server_address pour spécifier les points de terminaison de connexion pour le serveur Ripple. Assurez-vous de spécifier le nom d'hôte ou l'adresse IP accessible par le réseau de votre serveur Ripple en tant que -rippple_server_address. Sinon, par défaut, Ripple se liera à localhost et vous ne pourrez donc pas vous y connecter à distance.
4. Configuration des esclaves du serveur Ripple
Vous pouvez utiliser la commande CHANGE MASTER TO pour connecter vos esclaves à répliquer à partir du serveur Ripple.
Pour vous assurer que Ripple peut authentifier le mot de passe que vous utilisez pour vous y connecter, vous devez démarrer Ripple en spécifiant l'option -ripple_server_password_hash
Par exemple, si vous démarrez le serveur ripple avec la commande :
rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip> -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'
vous pouvez utiliser la commande CHANGE MASTER TO suivante pour vous connecter depuis l'esclave :
CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Notez que le hachage du mot de passe spécifié pour le serveur Ripple correspond au mot de passe texte utilisé dans la commande CHANGE MASTER TO. Actuellement, Ripple ne s'authentifie pas sur la base des noms d'utilisateur et accepte tout nom d'utilisateur non vide tant que le mot de passe correspond.
Explorer le serveur MySQL Binlog - RippleClick To Tweet5. Gestion du serveur Ripple
Il est possible de surveiller et de gérer le serveur Ripple en utilisant le protocole MySQL à partir de n'importe quel client MySQL standard. Il existe un ensemble limité de commandes prises en charge que vous pouvez voir directement dans le code source sur la page GitHub de mysql-ripple.
Certaines des commandes utiles sont :
SELECT @@global.gtid_executed;– Pour voir le GTID SET du serveur Ripple en fonction de ses journaux binaires téléchargés.STOP SLAVE;– Pour déconnecter le serveur Ripple du maître.START SLAVE;– Pour connecter le serveur Ripple au maître.
Problèmes connus et suggestions d'amélioration
1. Je n'ai pas vu d'option pour configurer un canal de réplication SSL d'un serveur Ripple vers le maître
En conséquence, le serveur Ripple ne pourra pas se connecter à un maître qui impose des connexions cryptées. Toute tentative de connexion entraînera l'erreur :
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Failed to connected to host: <Hosname>, port: 3306, err: Failed to connect: Connections using insecure transport are prohibited while --require_secure_transport=ON.
2. Je n'ai pas pu faire fonctionner le serveur Ripple avec l'option de semi-synchronisation
J'ai démarré le serveur Ripple en utilisant l'option -ripple_semi_sync_slave_enabled=true
En le connectant, le maître a pu détecter le serveur Ripple comme un esclave activé pour la semi-synchronisation.
mysql> show status like 'rpl%';
------------------------------------------------------
| Variable_name | Value |
------------------------------------------------------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_slave_status | OFF |
------------------------------------------------------
Cependant, essayer d'exécuter une transaction en mode semi-synchronisé a attendu rpl_semi_sync_master_timeout qui était de 180000
mysql> create database d12;
Query OK, 1 row affected (3 min 0.01 sec)
J'ai pu voir que la semi-synchronisation était désactivée sur le maître :
mysql> show status like 'rpl%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | OFF |
| Rpl_semi_sync_slave_status | OFF |
+--------------------------------------------+-------+
Extrait correspondant des journaux d'erreurs mysql :
2020-03-21T10:05:56.000612Z 52 [Note] Start binlog_dump to master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [Note] Start semi-sync binlog_dump to slave (server_id: 112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000010, pos: 350), semi-sync up to file , position 4.
2020-03-21T10:08:55.874044Z 2 [Note] Semi-sync replication switched OFF.
Un problème similaire a été signalé ici sur la page MySQL Ripple Github.
3. Problème lors de l'utilisation de la réplication parallèle pour les esclaves du serveur Ripple
J'ai vu que le thread SQL sur l'esclave s'arrêtait souvent avec l'erreur :
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name /mysql_data/relaylogs/relay-log.000005, position 27023962 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly.
L'analyse du journal de relais et de la position ci-dessus a révélé que le « numéro de séquence » de la transaction à ce stade a été réinitialisé à 1. J'ai recherché la cause d'une rotation de binlog qui se produit sur le maître d'origine. Généralement, pour les esclaves directs, il y a un événement de rotation en raison duquel les journaux de relais tourneraient également en fonction de la rotation du journal binaire maître. Mon évaluation est que de telles conditions peuvent être détectées et que la réinitialisation du numéro de séquence peut être gérée par des threads parallèles. Mais lorsque le numéro de séquence change sans la rotation des journaux de relais, nous voyons les threads parallèles échouer.
Cette observation est signalée comme le problème :échec du thread parallèle esclave lors de la synchronisation à partir du serveur binlog #26
4. L'utilitaire mysqlbinlog ne fonctionne pas sur les journaux binaires produits par le serveur Ripple
La tentative d'exécution de l'utilitaire mysqlbinlog sur le journal binaire a entraîné l'erreur :
ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 43, event_type: -106
Ce problème est soulevé ici :impossible d'ouvrir les fichiers journaux binaires à l'aide de l'utilitaire mysqlbinlog. #25
Il est reconnu par l'auteur comme un problème connu. Je pense qu'il serait utile de prendre en charge cet utilitaire à des fins de débogage.
C'est le rapport pour l'instant de mes tests rapides. Je prévois de mettre à jour ce billet de blog au fur et à mesure que je rencontrerai d'autres découvertes sur Ripple. Dans l'ensemble, je l'ai trouvé simple et direct à utiliser et a le potentiel de devenir un standard pour les serveurs binlog dans les environnements MySQL.
|
