Déterminer le bon serveur Il faut d'abord décider quel est le "bon" serveur. Si HAPROXY est en service, alors le bon maître est celui sur lequel les données sont actuellement écrites.
rediffuser Rediffuser HAPROXY S'il y a une HAPROXIE, supprimez les serveurs sur le brisé côté master de la distribution (également l'esclave de ce côté).
Sur LES DEUX serveurs master
Faites une sauvegarde de la bonne Master DB sur le Serveur principal BRISÉ Précédent à la version 3.12 : | Translations Ignore |
|---|
| Code Block |
|---|
mysqldump -h<GOOD_MASTER> -uroot -p<PASSWORD> --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > master.sql |
|
A partir de la version 3.12, veuillez utiliser la commande suivante : | Translations Ignore |
|---|
| Code Block |
|---|
mysqldump -h<GOOD_MASTER> -uroot -p<PASSWORD> --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > master.sql |
|
| Warning |
|---|
Dans les versions 3.12, 3.14 et 3.15 : Si quelqu'un se connecte au portail alors pendant que la décharge est en cours d'extractionle vidage est extrait, cela va mal se passertourner. Ci-joint une requête SQL. Si l'heure change après l'exécution de la requête, c'est qu' une connexion a eu lieu. Si cela se produit, la décharge doit être à nouveau retirée et, dans l'intervalle, il faut vérifier en permanence si une connexion a eu lieu. Si ce n'est pas le cas, le dépôt peut être reproduit sans erreur à l'esclave. SELECT Max(dtAcdLoggedIn) FROM Users; Dans les versions 3.11 et inférieures et la version 3.16, ce problème n'existe pas. |
Dans le Serveur maître BRISÉ, réinitialiser l'esclave et restaurer la sauvegarde | Translations Ignore |
|---|
| Code Block |
|---|
RESET SLAVE; SOURCE master.sql; |
|
Dans le Serveur maître BRISÉ, déterminer la position du maître à partir du master.sql, puis réinitialiser l'esclave
| Translations Ignore |
|---|
| Code Block |
|---|
CHANGE MASTER TO MASTER_HOST = '<GOOD_MASTER>', MASTER_USER = 'repl', MASTER_PASSWORD = '<PASSWORD>', MASTER_LOG_FILE='<NAME_LOGFILE>', MASTER_LOG_POS=<POSITION_LOGFILE>; START SLAVE; |
|
Dans leServeur maître BRISÉ Vérifier l'esclave | Translations Ignore |
|---|
| Code Block |
|---|
SHOW SLAVE STATUS\G |
|
Seulement si tout va bien et que la réplication est à jour, alors continuez. L'état peut être surveillé avec la commande suivante :
| Translations Ignore |
|---|
| Code Block |
|---|
watch 'mysql -u root -p<PASSWORD> -e "SHOW SLAVE STATUS\G" 2>/dev/null' |
|
Dans le Serveur maître BRISÉ verrouiller toutes les tables et noter la position du maître | Translations Ignore |
|---|
| Code Block |
|---|
FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; |
|
Les postes de SHOW MASTER STATUS sont requis dans la commande suivante. Dans le BON serveur maître, repositionner et commencer la réplication. | Translations Ignore |
|---|
| Code Block |
|---|
CHANGE MASTER TO MASTER_HOST = '<SECOND_MASTER>', MASTER_USER = 'repl', MASTER_PASSWORD = '<PASSWORD>', MASTER_LOG_FILE='<NAME_LOGFILE>', MASTER_LOG_POS=<POSITION_LOGFILE>; START SLAVE; |
|
Déverrouillez les tableaux sur le Serveur maître BRISÉ
Contrôler les maîtres et les esclaves Sur tous les serveurs maintenant | Translations Ignore |
|---|
| Code Block |
|---|
SHOW SLAVE STATUS\G |
|
et vérifier que tout fonctionne bien Il n'est généralement pas nécessaire de rétablir les esclaves attachés aux deux maîtres. Si c'est le cas, ils peuvent être réinitialisés avec la procédure normale de récupération des esclaves. | 