Les journaux binaires (binlogs) contiennent des enregistrements de toutes les modifications apportées aux bases de données. Ils sont nécessaires à la réplication et peuvent également être utilisés pour restaurer des données après une sauvegarde. Un serveur binlog est essentiellement un référentiel de journaux binaires. Vous pouvez le considérer comme un serveur dont l'objectif est de récupérer les journaux binaires d'un maître, tandis que les serveurs esclaves peuvent s'y connecter comme s'ils se connectaient à un serveur maître.
Certains avantages d'avoir un serveur binlog par rapport à un maître intermédiaire pour répartir la charge de travail de réplication sont :
- Vous pouvez passer à un nouveau serveur maître sans que les esclaves remarquent que le serveur maître réel a changé. Cela permet une configuration de réplication plus hautement disponible où la réplication est hautement prioritaire.
- Réduisez la charge sur le maître en ne servant que le serveur binlog de Maxscale au lieu de tous les esclaves.
- Les données du journal binaire du maître intermédiaire ne sont pas une copie directe des données reçues du journal binaire du maître réel. Ainsi, si la validation de groupe est utilisée, cela peut entraîner une réduction du parallélisme des validations et une réduction subséquente des performances des serveurs esclaves.
- L'esclave intermédiaire doit ré-exécuter chaque instruction SQL, ce qui ajoute potentiellement de la latence et des retards dans la chaîne de réplication.
Dans cet article de blog, nous allons examiner comment remplacer un maître intermédiaire (un relais hôte esclave vers d'autres esclaves dans une chaîne de réplication) par un serveur binlog fonctionnant sur MaxScale pour une meilleure évolutivité et de meilleures performances .
Architecture
Nous avons essentiellement une configuration de réplication MariaDB v10.4 à 4 nœuds avec un MaxScale v2.3 assis au-dessus de la réplication pour distribuer les requêtes entrantes. Un seul esclave est connecté à un maître (maître intermédiaire) et les autres esclaves répliquent à partir du maître intermédiaire pour servir les charges de travail de lecture, comme illustré dans le schéma suivant.
Nous allons transformer la topologie ci-dessus en ceci :
En gros, nous allons supprimer le rôle de maître intermédiaire et le remplacer par un serveur binlog fonctionnant sur MaxScale. Le maître intermédiaire sera converti en esclave standard, tout comme les autres hôtes esclaves. Le service binlog écoutera sur le port 5306 sur l'hôte MaxScale. Il s'agit du port auquel tous les esclaves se connecteront pour une réplication ultérieure.
Configuration de MaxScale en tant que serveur Binlog
Dans cet exemple, nous avons déjà un MaxScale assis au-dessus de notre cluster de réplication agissant comme un équilibreur de charge pour nos applications. Si vous n'avez pas de MaxScale, vous pouvez utiliser ClusterControl pour déployer, allez simplement dans Actions de cluster -> Ajouter un équilibreur de charge -> MaxScale et remplissez les informations nécessaires comme suit :
Avant de commencer, exportons la configuration MaxScale actuelle dans un fichier texte pour la sauvegarde. MaxScale a un indicateur appelé --export-config à cet effet mais il doit être exécuté en tant qu'utilisateur maxscale. Ainsi, la commande à exporter est :
$ su -s /bin/bash -c '/bin/maxscale --export-config=/tmp/maxscale.cnf' maxscaleSur le maître MariaDB, créez un utilisateur esclave de réplication appelé 'maxscale_slave' à utiliser par MaxScale et attribuez-lui les privilèges suivants :
$ mysql -uroot -p -h192.168.0.91 -P3306
MariaDB> CREATE USER 'maxscale_slave'@'%' IDENTIFIED BY 'BtF2d2Kc8H';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale_slave'@'%';
MariaDB> GRANT SELECT ON mysql.roles_mapping TO 'maxscale_slave'@'%';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale_slave'@'%';
MariaDB> GRANT REPLICATION SLAVE ON *.* TO 'maxscale_slave'@'%';Pour les utilisateurs de ClusterControl, accédez à Gérer -> Schémas et utilisateurs pour créer les privilèges nécessaires.
Avant d'aller plus loin dans la configuration, il est important d'examiner l'état actuel et la topologie de nos serveurs principaux :
$ maxctrl list servers
┌────────┬──────────────┬──────┬─────────────┬──────────────────────────────┬───────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_757 │ 192.168.0.90 │ 3306 │ 0 │ Master, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_758 │ 192.168.0.91 │ 3306 │ 0 │ Relay Master, Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_759 │ 192.168.0.92 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
├────────┼──────────────┼──────┼─────────────┼──────────────────────────────┼───────────┤
│ DB_760 │ 192.168.0.93 │ 3306 │ 0 │ Slave, Running │ 0-38001-8 │
└────────┴──────────────┴──────┴─────────────┴──────────────────────────────┴───────────┘Comme nous pouvons le voir, le maître actuel est DB_757 (192.168.0.90). Prenez note de ces informations car nous allons configurer le serveur binlog pour répliquer à partir de ce maître.
Ouvrez le fichier de configuration MaxScale dans /etc/maxscale.cnf et ajoutez les lignes suivantes :
[replication-service]
type=service
router=binlogrouter
user=maxscale_slave
password=BtF2d2Kc8H
version_string=10.4.12-MariaDB-log
server_id=9999
master_id=9999
mariadb10_master_gtid=true
filestem=binlog
binlogdir=/var/lib/maxscale/binlogs
semisync=true # if semisync is enabled on the master
[binlog-server-listener]
type=listener
service=replication-service
protocol=MariaDBClient
port=5306
address=0.0.0.0Un peu d'explication - Nous créons deux composants - service et listener. Le service est l'endroit où nous définissons la caractéristique du serveur binlog et comment il doit fonctionner. Des détails sur chaque option peuvent être trouvés ici. Dans cet exemple, nos serveurs de réplication fonctionnent avec une réplication semi-synchrone, nous devons donc utiliser semisync=true pour qu'il se connecte au maître via la méthode de réplication semi-synchrone. L'écouteur est l'endroit où nous mappons le port d'écoute avec le service binlogrouter à l'intérieur de MaxScale.
Redémarrez MaxScale pour charger les modifications :
$ systemctl restart maxscaleVérifiez que le service binlog est démarré via maxctrl (regardez la colonne État) :
$ maxctrl show service replication-serviceVérifiez que MaxScale écoute maintenant un nouveau port pour le service binlog :
$ netstat -tulpn | grep maxscale
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:3307 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 0.0.0.0:5306 0.0.0.0:* LISTEN 4850/maxscale
tcp 0 0 127.0.0.1:8989 0.0.0.0:* LISTEN 4850/maxscaleNous sommes maintenant prêts à établir un lien de réplication entre MaxScale et le maître.
Activer le serveur Binlog
Connectez-vous au serveur maître MariaDB et récupérez le fichier binlog actuel et sa position :
MariaDB> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| binlog.000005 | 4204 | | |
+---------------+----------+--------------+------------------+Utilisez la fonction BINLOG_GTID_POS pour obtenir la valeur GTID :
MariaDB> SELECT BINLOG_GTID_POS("binlog.000005", 4204);
+----------------------------------------+
| BINLOG_GTID_POS("binlog.000005", 4204) |
+----------------------------------------+
| 0-38001-31 |
+----------------------------------------+De retour au serveur MaxScale, installez le package client MariaDB :
$ yum install -y mysql-client
Connectez-vous à l'écouteur du serveur binlog sur le port 5306 en tant qu'utilisateur maxscale_slave et établissez un lien de réplication vers le maître désigné. Utilisez la valeur GTID récupérée du maître :
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SET @@global.gtid_slave_pos = '0-38001-31';
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.90', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=3306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Binlog Dump
Master_Host: 192.168.0.90
Master_User: maxscale_slave
Master_Port: 3306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 38001
Master_Info_File: /var/lib/maxscale/binlogs/master.ini
Slave_SQL_Running_State: Slave running
Gtid_IO_Pos: 0-38001-31Remarque :la sortie ci-dessus a été tronquée pour n'afficher que les lignes importantes.
Pointage des esclaves vers le serveur Binlog
Maintenant, sur mariadb2 et mariadb3 (les esclaves finaux), changez le maître pointant vers le serveur MaxScale binlog. Comme nous fonctionnons avec la réplication semi-synchronisée activée, nous devons d'abord les désactiver :
(mariadb2 & mariadb3)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update itRemarque :la sortie ci-dessus a été tronquée pour n'afficher que les lignes importantes.
Dans my.cnf, nous devons commenter les lignes suivantes pour désactiver la semi-synchronisation à l'avenir :
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONÀ ce stade, le maître intermédiaire (mariadb1) réplique toujours à partir du maître (mariadb0) tandis que d'autres esclaves se répliquent à partir du serveur binlog. Notre topologie actuelle peut être illustrée comme le schéma ci-dessous :
La dernière partie consiste à changer le pointage maître du maître intermédiaire (mariadb1 ) après que tous les esclaves qui s'y attachaient ne sont plus là. Les étapes sont fondamentalement les mêmes avec les autres esclaves :
(mariadb1)$ mysql -uroot -p
MariaDB> STOP SLAVE;
MariaDB> SET global rpl_semi_sync_master_enabled = 0; -- if semisync is enabled
MariaDB> SET global rpl_semi_sync_slave_enabled = 0; -- if semisync is enabled
MariaDB> CHANGE MASTER TO MASTER_HOST = '192.168.0.95', MASTER_USER = 'maxscale_slave', MASTER_PASSWORD = 'BtF2d2Kc8H', MASTER_PORT=5306, MASTER_USE_GTID = slave_pos;
MariaDB> START SLAVE;
MariaDB> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.95
Master_User: maxscale_slave
Master_Port: 5306
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_Server_Id: 9999
Using_Gtid: Slave_Pos
Gtid_IO_Pos: 0-38001-32Remarque :La sortie ci-dessus a été tronquée pour n'afficher que les lignes importantes.
N'oubliez pas de désactiver également la réplication semi-synchrone dans my.cnf :
#loose_rpl_semi_sync_slave_enabled=ON
#loose_rpl_semi_sync_master_enabled=ONNous pouvons vérifier que le service de routeur binlog a maintenant plus de connexions via maxctrl CLI :
$ maxctrl list services
┌─────────────────────┬────────────────┬─────────────┬───────────────────┬───────────────────────────────────┐
│ Service │ Router │ Connections │ Total Connections │ Servers │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rw-service │ readwritesplit │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ rr-service │ readconnroute │ 1 │ 1 │ DB_757, DB_758, DB_759, DB_760 │
├─────────────────────┼────────────────┼─────────────┼───────────────────┼───────────────────────────────────┤
│ replication-service │ binlogrouter │ 4 │ 51 │ binlog_router_master_host, DB_757 │
└─────────────────────┴────────────────┴─────────────┴───────────────────┴───────────────────────────────────┘De plus, les commandes d'administration de réplication courantes peuvent être utilisées à l'intérieur du serveur MaxScale binlog, par exemple, nous pouvons vérifier les hôtes esclaves connectés en utilisant cette commande :
(maxscale)$ mysql -u maxscale_slave -p'BtF2d2Kc8H' -h127.0.0.1 -P5306
MariaDB> SHOW SLAVE HOSTS;
+-----------+--------------+------+-----------+------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+--------------+------+-----------+------------+
| 38003 | 192.168.0.92 | 3306 | 9999 | |
| 38002 | 192.168.0.91 | 3306 | 9999 | |
| 38004 | 192.168.0.93 | 3306 | 9999 | |
+-----------+--------------+------+-----------+------------+À ce stade, notre topologie ressemble à ce que nous avions prévu :
Notre migration de la configuration principale intermédiaire vers la configuration du serveur binlog est maintenant terminée.
