Versions Compared

Old Version 19

changes.mady.by.user jtel Support

Saved on

compared with

New Version 20

changes.mady.by.user jtel Support

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Content imported from a Scroll Translations translation file.

...

Sv translation
languagede

Guter Server ermitteln

Zuerst muss entschieden werden, welcher der "guter" Server ist. Wenn HAPROXY im Betrieb ist, dann ist der guter Master der auf den die Daten derzeit geschrieben werden. 


HAPROXY umstellen

Falls es ein HAPROXY gibt, dann die Server auf der Kaputten Master Seite aus der Verteilung herausnehmen (auch den Slave auf dieser Seite).


Auf BEIDE Master Server


Translations Ignore


Code Block
STOP SLAVE;


Auf den KAPUTTEN Master Server eine Sicherung der guten Master DB anfertigen

Vor Release 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


Ab Release 3.12 bitte folgenden Befehl nutzen:

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

In Versionen 3.12, 3.14 und 3.15:

Wenn sich jemand am Portal Anmeldet, während der Dump gezogen wird, geht das schief. Anbei eine SQL abfrage. Wenn die Zeit sich nach dem ausführen der Abfrage ändert, hat ein Login stattgefunden.

Wenn das passiert, muss der Dump erneut gezogen werden und währenddessen dauerhaft geprüft werden, ob ein Login stattgefunden hat. Nur wenn dem nicht so ist, kann man den Dump Fehlerfrei auf den Slave replizieren.

SELECT Max(dtAcdLoggedIn) FROM Users;

In Versionen 3.11 und abwärts sowie Version 3.16 besteht dieses Problem nicht.


Auf den KAPUTTEN Master Server, den Slave resetten, und Sicherung einspielen

Translations Ignore


Code Block
RESET SLAVE; 
SOURCE master.sql;





Auf den KAPUTTEN Master Server aus den master.sql die Master Position ermitteln, und dann den Slave reinitialisieren


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;




Auf den KAPUTTEN Master Server den Slave Prüfen

Translations Ignore


Code Block
SHOW SLAVE STATUS\G




Erst wenn alles OK, und die Replikation aktuell ist, dann weitermachen.
Den Status kann man mit folgenden Befehl beobachten:


Translations Ignore


Code Block
watch 'mysql -u root -p<PASSWORD> -e "SHOW SLAVE STATUS\G" 2>/dev/null'



Auf den KAPUTTEN Master Server alle Tabellen locken und Master Position notieren

Translations Ignore


Code Block
FLUSH TABLES WITH READ LOCK; 
SHOW MASTER STATUS;



Die Positionen von SHOW MASTER STATUS werden im folgenden Kommando benötigt.

Auf den GUTEN Master Server die Replikation neu positionieren und starten 

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;




Auf den KAPUTTEN Master Server die Tabellen Locks aufheben

Translations Ignore


Code Block
UNLOCK TABLES;



Master und Slaves Prüfen

Auf allen Servern nun 

Translations Ignore


Code Block
SHOW SLAVE STATUS\G




und prüfen dass alles richtig läuft

Es ist normalerweise nicht nötig, die Slaves die an beide Master hängen ebenfalls zu wiederherstellen. Wenn doch, können diese mit der normalen Prozedur für das Wiederherstellen des Slaves neu initialisiert werden.

Sv translation
languagefr

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 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


Translations Ignore


Code Block
STOP SLAVE;


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 que la décharge est en cours d'extraction, cela va mal se passer. 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É

Translations Ignore


Code Block
UNLOCK TABLES;




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.