1. Présentation de MMM
1. Qu'est-ce que MMM
MMM (gestionnaire de réplication maître-maître pour MySQL, gestionnaire de réplication maître-maître MySQL) est un ensemble de programmes de script qui prennent en charge le basculement double maître et la gestion quotidienne double maître. MMM est développé en langage Perl, et surveille et gère principalement la réplication MySQL maître-maître (double maître). Bien qu'elle soit appelée réplication double maître, un seul maître est autorisé à écrire en même temps en entreprise, et l'autre de sauvegarde Le maître fournit un service de lecture partielle pour accélérer le préchauffage du maître de secours lors de la commutation maître-maître. On peut dire que le programme de script MMM réalise la fonction de basculement d'une part, et d'autre part, son module interne supplémentaire. Les outils peuvent également réaliser l'équilibrage de charge en lecture de plusieurs esclaves.
2. Scénarios d'application
MMM fournit des méthodes automatiques et manuelles pour supprimer l'adresse IP virtuelle d'un serveur avec un délai de réplication élevé dans un groupe de serveurs.En même temps, il peut également sauvegarder les données et réaliser la synchronisation des données entre deux nœuds. Étant donné que MMM ne peut pas garantir entièrement la cohérence des données, MMM convient aux scénarios qui ne nécessitent pas une cohérence élevée des données mais qui souhaitent garantir au maximum la disponibilité de l'entreprise. Pour les entreprises qui ont des exigences élevées en matière de cohérence des données, il n'est pas recommandé d'adopter une architecture à haute disponibilité telle que MMM.
3. Fonctionnalités de MMM
MMM est un ensemble de scripts flexibles
implémentés sur la base du langage perl,
utilisé pour surveiller et basculer la réplication mysql,
gérer la configuration de la réplication MySQL Master-Master
4. Description de l'architecture haute disponibilité MMM
mmm_mon : processus de surveillance, responsable de tout le travail de surveillance, déterminant et traitant toutes les activités de rôle de nœud. Ce script doit être exécuté sur la machine du superviseur.
mmm_agent : le processus de l'agent s'exécutant sur chaque serveur MySQL, termine le travail de vérification de la surveillance et effectue des réglages de service à distance simples. Ce script doit être exécuté sur la machine supervisée.
mmm_control : un script simple qui fournit des commandes pour gérer le processus mmm_mond.
Le côté superviseur de mysql-mmm fournira plusieurs adresses IP virtuelles (VIP), dont une VIP accessible en écriture et plusieurs VIP lisibles. Grâce à la gestion de la supervision, ces adresses IP seront liées au MySQL disponible. Lorsque la machine tombe en panne, le superviseur migre le VIP à un autre MySQL.
5. Utilisateur et autorisation
Pendant tout le processus de surveillance, il est nécessaire d'ajouter un yaourt d'autorisation pertinent à MySQL afin que MySQL puisse prendre en charge la maintenance de la machine de surveillance. Les utilisateurs autorisés incluent un utilisateur mmm_monitor et un utilisateur mmm_agent. Si vous souhaitez utiliser l'outil de sauvegarde MMM, vous devez également ajouter un utilisateur mmm_tools.
2. Environnement du cas
1. Configuration du serveur
2. Environnement serveur
systemctl stop firewalld && systemctl disable firewalld
setenforce 0
3 Modifiez le nom d'hôte
hostnamectl set-hostname master1
su
maître1 maître2 esclave1 esclave2 moniteur
3. Mise en œuvre du cas
1. Construire une architecture MySQL multi-maître et multi-esclave
(1) Installer mysql sur les nœuds master1, master2, slave1 et slave2
(2) Modifier le fichier de configuration de master1
[client]
port = 3306
default-character- set=utf8
socket=/usr /local/mysql/mysql.sock
[mysql]
port = 3306
default-character-set=utf8
socket=/usr/local/mysql/mysql.sock
auto-rehash
[mysqld]
user = mysql
basedir =/usr/local/mysql
datadir=/usr/local/mysql/data
port=3306
character-set-server=utf8
pid-file=/usr/local/mysql/mysqld.pid
socket=/usr/local/mysql/ mysql.sock
server-id= 1
log-error=/usr/local/mysql/data/mysql_error.log
general_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
slow_query_log=ON
slow_query_log_file=mysql_slow_query.log
long_query_time=5
binlog-ignore-db=mysql,information_schema
log_bin=mysql_bin
log_slave_updates=true
sync_binlog=1
innodb_flush_log_at _trx_commit=1
auto_increment_increment=2
auto_increment_offset =1
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,PIPES_AS_CONCAT,ANSI_QUOTES
redémarrer mysqld
systemctl redémarre mysqld
Paramètre Description
......
server-id = 1
#Le server-id de chaque hôte Mysql ne peut pas être le même
log-error=/usr/local/mysql/data/mysql_error.log
#Error log
general_log=ON
#Journal des requêtes générales
general_log_file= /usr/local/mysql/data/mysql_general.log
slow_query_log=ON
#Lenteur du journal des requêtes
slow_query_log_file=mysql_slow_query.log
long_query_time=5
binlog-ignore-db=mysql,information_schema
#Pas besoin de synchroniser le nom de la bibliothèque
log_bin=mysql_bin
#Ouvrir le journal binaire Pour la réplication de données maître-esclave log_slave_updates
=true
#Autoriser l'esclave à écrire dans son propre journal binaire lors de la copie de données depuis le maître to innodb_flush_log_at_trx_commit =1 #"Paramètre Double 1", MySQL écrira les données mises en cache dans le fichier journal chaque fois que la transaction est validée, et les videra sur le disque
auto_increment_increment=2
#Combien de champs d'auto-incrémentation sont incrémentés à la fois
auto_increment_offset=1
#Valeur initiale des champs d'auto-incrémentation
(3) Modifiez les trois autres mysql et redémarrez le service
Copiez le fichier de configuration sur les trois autres serveurs de base de données et redémarrez le serveur mysql
Remarque : L'ID de serveur dans le fichier de configuration ne peut pas être le même et doit être modifié
(4) Configurez la réplication maître-maître et les deux serveurs maîtres se répliquent
① Exécutez les autorisations accordées à l'esclave sur les deux serveurs maîtres et n'avez pas besoin de s'exécuter sur le serveur esclave
serveur master1 (192.168.10.20
mysql> accorde l'esclave de réplication sur *.* à 'replication'@'192.168.10.%' identifié par '123456' ;
mysql> flush privilèges ;
mysql> afficher l'état du maître ;
+------------------+----------+-------------+---- ----------------------+-------------------------
| Fichier | Poste | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Se
+------------------+----------+--------------+--- -----------------------+------------------------------
| mysql_bin.000001 | 1023 | | mysql,schéma_information |
+------------------+----------+-------------+---- ----------------------+-----------------
1 ligne dans l'ensemble (0,00 sec)
master2 服务器(192.168.10.30)
mysql> accorde l'esclave de réplication sur *.* à 'replication'@'192.168.10.%' identifié par '123456' ;
mysql> flush privilèges ;
mysql> afficher l'état du maître ;
+------------------+----------+-------------+---- ----------------------+-------------------------
| Fichier | Poste | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Se
+------------------+----------+--------------+--- -----------------------+------------------------------
| mysql_bin.000001 | 1023 | | mysql,schéma_information |
+------------------+----------+-------------+---- ----------------------+-----------------
1 rangée dans le jeu (0,00 sec)
② 在master1 上配置同步
192.168.10.20
changer le maître en master_host='192.168.10.30', master_user='replication', master_password='123456', master_log_file='mysql_bin.000001', master_log_pos=1023 ; démarrer l'esclave ; afficher l'état de l'esclave\G ; #Afficher les threads
IO
et
SQL Est-ce OUI, et le décalage de position est-il correct ?
③ Configurer la synchronisation sur le maître2
192.168.10.30
changer le maître en master_host='192.168.10.20', master_user='replication', master_password='123456', master_log_file='mysql_bin.000001', master_log_pos=1023 ; démarrer l'esclave ; afficher l'état de l'esclave\G ; #Afficher les threads
IO
et
SQL Est-ce OUI, et le décalage de position est correct
(5) Configurer la réplication maître-esclave, et faire
① serveur esclave1 sur deux serveurs esclaves
192.168.10.40
changer le maître en master_host='192.168.10.20',master_user='replication',master_password='123456',master_log_file='mysql_bin.000001',master_log_pos=1023 ;
démarrer l'esclave ;
afficher l'état de l'esclave\G ;
② serveur esclave2
192.168.10.50
changer le maître en master_host='192.168.10.20',master_user='replication',master_password='123456',master_log_file='mysql_bin.000001',master_log_pos=1023 ;
démarrer l'esclave ;
afficher l'état de l'esclave\G ;
(6) Tester la synchronisation maître-maître et maître-esclave
2. Installer et configurer MySQL-MMM
(1) Installer MySQL-MMM sur tous les serveurs
Remarque : S'il n'y a pas de logiciel ci-dessus dans l'entrepôt local, vous devez configurer la source en ligne entrepôt pour chaque serveur en premier.
yum -y installe epel-release && yum -y installe mysql-mmm*
(2) Configurer MySQL-MMM sur master1
192.168.10.20
[root@master1 ~]# cd /etc/mysql-mmm/
[root@master1 mysql-mmm]# cp mmm_common.conf mmm_common.conf.bak
#Avant de modifier le fichier de configuration, sauvegardez d'abord
[root@master1 mysql-mmm] # vim mmm_common.conf
active_master_role writer
<hôte par défaut>
cluster_interface ens33
pid_path /run/mysql-mmm-agent.pid
bin_path /usr/libexec/mysql-mmm/
replication_user replication
##Spécifiez les utilisateurs de réplication maître-maître et maître-esclave, pour être cohérent avec le précédent
replication_password 123456
agent_user mmm_agent
##Spécifier le nom d'utilisateur du processus de l'agent de surveillance
agent_password 123456
</host>
<host db1>
ip 192.168.10.20
mode master
peer db2
##peer set peer database
</host>
<host db2>
ip 192.168.10.30
mode master
peer db1
</host>
<host db3>
ip 192.168.10.40
mode slave
</host>
<host db4>
ip 192.168.10.50
mode slave
</host>
<role writer>
hosts db1, db2
ips 192.168.10.200
##Set to write VIP
mode exclusive
#Un seul hôte peut écrire operation mode
</role>
<role reader>
hosts db3, db4
ips 192.168 .10.201 , 192.168.10.202
## Définir
le mode VIP de lecture équilibré
##Plusieurs hôtes esclaves peuvent exécuter le mode de fonctionnement en lecture
</role>
(3) Copiez le fichier de configuration sur les 4 autres hôtes.
Le contenu du fichier de configuration est le même pour tous les hôtes.
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
scp mmm_common.conf [email protected]:/etc/mysql-mmm /
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
(4) Modifier le fichier de configuration de l'agent mmm_agent.conf
master1 de tous les serveurs de base de données
[root@master1 ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1
##Passez à db1/db2/db3/db4 selon les différents hôtes, la configuration par défaut est db1, donc master1 ne le fait pas besoin d'être modifié
maître2
[root@master2 ~]# vim /etc/mysql-mmm/mmm_agent.conf
inclure mmm_common.conf
this db2
slave1
[root@slave ~]# vim /etc/mysql-mmm/mmm_agent.conf
inclure mmm_common.conf
cet
esclave db3 2
[root@slave2 ~]# vim /etc/mysql-mmm/mmm_agent.conf
inclure mmm_common.conf
cette db4
(5) Modifiez le fichier de configuration de surveillance mmm_mon.conf sur le serveur de surveillance
Monitor Server Monitor (192.168.10.90)
[root@monitor ~]# vim /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf
<monitor>
ip 127.0.0.1
pid_path /run/mysql-mmm-monitor.pid
bin_path /usr/libexec/mysql-mmm
status_path /var/lib/mysql-mmm/mmmm_mond.status
ping_ips 192.168.10.20,192.168.10.30, 192.168.10.40, 192.168.10.50.50 ## Spécifiez l'ip auto_set_online 10 ##
spécifie de tous les serveurs de base de données . kill_host_bin n'existe pas par défaut, bien que # le moniteur lancera un avertissement à ce sujet manquant. Voir la section 5.10 "Kill Host # Functionality" dans la documentation PDF. #
# kill_host_bin /usr/libexec/mysql-mmm/monitor/kill_host
#
</monitor>
<host default>
monitor_user mmm_monitor
##Spécifiez le nom d'utilisateur de mmm_monitor
monitor_password 123456
##Spécifiez le mot de passe de mmm_monitor
</host>
debug 0
(6) Autoriser mmm_agent (processus agent) sur toutes les bases de données
Toutes les bases de données exécutent les instructions suivantes
accorder super,client de réplication,processus sur *.* à 'mmm_agent'@'192.168.10.%' identifié par '123456' ;
privilèges de vidage ;
(7) Accordez
le client de réplication sur *.* à 'mmm_monitor'@'192.168.10.%' identifié par '123456' ;
privilèges de vidage ;
(8) Démarrer mysql-mmm-agent systemctl démarrer mysql-mmm-agent.service && systemctl activer mysql-mmm-agent.service sur tous les serveurs de base de données
(9) Démarrer mysql-mmm-monitor systemctl démarrer mysql-mmm-monitor.service && systemctl activer mysql-mmm-monitor.service sur le serveur de surveillance
(10) Tester le cluster sur le serveur moniteur
① Afficher l'état de chaque nœud
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles : écrivain (192.168.10.200)
db2 (192.168.10.30) maître/EN LIGNE. Rôles :
db3(192.168.10.40) esclave/EN LIGNE. Rôles : lecteur (192.168.10.202)
db4 (192.168.10.50) esclave/EN LIGNE. Rôles : lecteur (192.168.10.201)
② Vérifiez si la fonction de surveillance est parfaite
[root@monitor ~]#mmm_control vérifie tous
les ping db4 [dernière modification : 2021/11/04 16:13:20] OK
db4 mysql [dernière modification : 2021/11/04 16:13:20] OK
db4 rep_threads [dernière modification : 2021/11/04 16:13:20] OK
db4 rep_backlog [dernière modification : 2021/11/04 16:13:20] OK : le backlog est nul
db2 ping [dernière modification : 2021/11/04 16:13 :20] OK
db2 mysql [dernière modification : 2021/11/04 16:13:20] OK
db2 rep_threads [dernière modification : 2021/11/04 16:13:20] OK
db2 rep_backlog [dernière modification : 2021/11/ 04 16:13:20] OK : le backlog est nul
db3 ping [dernière modification : 2021/11/04 16:13:20] OK
db3 mysql [dernière modification : 2021/11/04 16:13:20] OK
db3 rep_threads [dernière modification : 2021/11/04 16:13:20] OK
db3 rep_backlog [dernière modification : 2021/11/04 16:13:20] OK : le backlog est nul
db1 ping [dernière modification : 2021/11/04 16:13:20] OK
db1 mysql [dernière modification : 2021/11/ 04 16:13:20] OK
db1 rep_threads [dernière modification : 2021/11/04 16:13:20] OK
db1 rep_backlog [dernière modification : 2021/11/04 16:13:20] OK : le backlog est nul
③ Désigner l'hôte lié au VIP
[root@monitor ~]#mmm_control move_role writer db2
OK : le rôle 'writer' a été déplacé de 'db1' vers 'db2'. Vous pouvez maintenant attendre un peu et vérifier les nouvelles informations sur les rôles !
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/EN LIGNE. Rôles : lecteur (192.168.10.202)
db4 (192.168.10.50) esclave/EN LIGNE. Rôles : lecteur (192.168.10.201)
[root@monitor ~]#mmm_control move_role writer db1
OK : le rôle 'writer' a été déplacé de 'db2' vers 'db1'. Vous pouvez maintenant attendre un peu et vérifier les nouvelles informations sur les rôles !
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles : écrivain (192.168.10.200)
db2 (192.168.10.30) maître/EN LIGNE. Rôles :
db3(192.168.10.40) esclave/EN LIGNE. Rôles : lecteur (192.168.10.202)
db4 (192.168.10.50) esclave/EN LIGNE. Rôles : lecteur (192.168.10.201)
3. Test de panne
(1) Simuler le temps d'arrêt et la récupération du maître
① Arrêter le service mysql de master1
② Vérifier l'état de la dérive VIP
moniteur
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/HARD_OFFLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/EN LIGNE. Rôles : lecteur (192.168.10.202)
db4 (192.168.10.50) esclave/EN LIGNE. Rôles : lecteur (192.168.10.201)
VIP a dérivé avec succès vers master2, et master1 affiche HARD_OFFLINE
③ Redémarrez le service mysql de master1
maître1
systemctl démarrer mysqld
Après la récupération de master1, le VIP est toujours sur master2 et n'a pas été transféré vers master1
(2) Simuler le temps d'arrêt et la récupération du serveur esclave
① Arrêter le service mysql de slave1
esclave1
systemctl stop mysqld
② Vérifier l'état de la dérive VIP
moniteur
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/HARD_OFFLINE. Rôles :
db4(192.168.10.50) esclave/EN LIGNE. Rôles : lecteur(192.168.10.201), lecteur(192.168.10.202)
Le VIP correspondant à slave1 est pris en charge par slave2
③ Redémarrez le service mysql de slave1
esclave1
systemctl démarrer mysqld
④ Vérifiez si slave1 est restauré
moniteur
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/AWAITING_RECOVERY. Rôles :
db4(192.168.10.50) esclave/EN LIGNE. Rôles : lecteur(192.168.10.201), lecteur(192.168.10.202)
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/EN LIGNE. Rôles :
db4(192.168.10.50) esclave/EN LIGNE. Rôles : lecteur(192.168.10.201), lecteur(192.168.10.202)
[root@monitor ~]#mmm_control show
db1(192.168.10.20) master/ONLINE. Rôles :
db2(192.168.10.30) maître/EN LIGNE. Rôles : écrivain (192.168.10.200)
db3 (192.168.10.40) esclave/EN LIGNE. Rôles : lecteur (192.168.10.202)
db4 (192.168.10.50) esclave/EN LIGNE. Rôles : lecteur (192.168.10.201)
Après une période de transfert, slave1 redevient VIP et continue à travailler
(3) Test client
① Autoriser la connexion pour l'adresse du serveur de surveillance sur le serveur master1
accorder tout sur *.* à 'test'@'192.168.10.90' identifié par '123456';
privilèges de vidage ;
② Connectez-vous avec VIP sur le serveur de surveillance
yum -y install mariadb-server mariadb
systemctl start mariadb.service && systemctl enable mariadb.service
mysql -utest -p123456 -h 192.168.10.200 #Si vous pouvez vous connecter, vous avez réussi
③ Le client crée des données et teste la synchronisation
moniteur