Comment resynchronisez-vous la base de données maître MySQL avec les modifications de la base esclave si le maître se déconnecte?

MySQL Server 1 fonctionne en tant que maître.
MySQL Server 2 fonctionne en tant qu'esclave.

Avec les deux bases de données en ligne, elles sont en "parfaite synchronisation". Si Slave se déconnecte, il n'y a aucun problème si Master reste en ligne; ils reprendront la synchronisation une fois que l'esclave sera de nouveau en ligne.

Outre la configuration du serveur, j'ai redirigé la connexion (avec le code JSP) pour la base de données esclave si le maître se déconnecte (j'ai testé bien sûr avec /etc/init.d/mysqld stop).

Lorsque le maître revient en ligne, existe-t-il une méthode automatique pour synchroniser le maître avec les mises à jour esclaves?

Une bonne façon de réaliser quelque chose de cette nature est de configurer la réplication maître-maître ou la réplication circulaire. Cela ne doit pas être confondu avec la réplication MultiMaster.

La configuration de la réplication circulaire est en fait très simple si vous avez configuré la réplication maître-esclave. Voici ce que vous devez faire pour le configurer.

Pour cet exemple, nous supposerons que la réplication maître-esclave est active mais vous rencontrerez un peu de temps d'arrêt (1-2 minutes):

Étape 1) Ajoutez cette ligne à /etc/my.cnf sur le maître.

mises à jour log-slave

Étape 2) Ajoutez ces lignes à /etc/my.cnf sur l'esclave:

log-bin = mysql-bin (ou avoir tout ce que le maître a pour cela) log-slave-updates

AVERTISSEMENT: voici le bref moment d'arrêt !!!

Étape 3) Sur l'esclave, service redémarrage mysql

Cela activera les journaux binaires sur l'esclave

Étape 4) Sur le maître, arrêtez mysql

Étape 5) Utilisez rsync pour copier le dossier / var / lib / mysql de l'esclave vers le maître.

AVERTISSEMENT: Voici le plus long moment d'arrêt !!!

Étape 6) Sur l'esclave, arrêtez le service mysql

Étape 7) Sur l'esclave, découvrez le dernier journal binaire

Étape 8) Sur l'esclave, découvrez la taille de fichier du dernier journal binaire

Étape 9) Utilisez rsync pour copier le dossier / var / lib / mysql de l'esclave vers le maître. Cela devrait être une copie plus rapide.

Étape 10) Sur le maître, éditez la
ligne 2 de master.info avec le dernier journal binaire de l'esclave.
Ligne 3 de master.info avec la taille de fichier du dernier journal binaire de l'esclave.
Ligne 4 de master.info avec l'IP de l'esclave.
La ligne 5 est l'ID utilisateur de l'utilisateur de réplication (NE PAS TOUCHER) La
ligne 6 est le mot de passe de l'utilisateur de réplication (NE PAS TOUCHER)

Étape 11) Supprimez tous les journaux binaires et le fichier d'index des journaux binaires du maître.

Étape 12) Sur l'esclave, lancez mysql, attendez 15 secondes

Étape 13) Sur le maître, lancez mysql service

Étape 14) Sur le maître, exécutez STOP SLAVE; AFFICHER LE STATUT DE MAÎTRE;

Étape 15) Sur l'esclave, exécutez CHANGE MASTER TO MASTER_HOST = 'IP of Slave', MASTER_USER = 'userid of replication user from Step10', MASTER_PASSWORD = 'password of replication user from Step10', MASTER_LOG_FILE = 'log binary from Step14', MASTER_LOG_POS = LogPos de l'étape 14.

Étape 16) Sur l'esclave, exécutez START SLAVE;

Étape 17) Sur le maître, exécutez START SLAVE;

J'ai effectué des étapes similaires à cela pour une autre question StackExchange à laquelle j'ai répondu .

Essaie !!!

Pas avec la réplication asynchrone, ce que propose MySQL. Vous venez de frapper le clou proverbial de la raison pour laquelle la réplication MySQL `` prête à l'emploi '' (version antérieure à 5.5) n'est pas une solution à haute disponibilité en soi. Les choses s'améliorent légèrement avec 5.5 avec la réplication semi-synchrone (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html) mais au prix d'un temps de transaction plus lent pendant que le maître attend le ack de l'esclave.

Si accepter la possibilité de perte de données lorsque le maître tombe en panne n'est pas une option, je dirais qu'une configuration plus sophistiquée que le simple maître / esclave est en règle.

La réplication Master to Master a été jugée plus problématique que bénéfique par de nombreuses personnes célèbres de MySQL (même MySQL AB lui-même ne le recommande plus comme solution de haute disponibilité). Donc, je pense que l'utilisation de la configuration DRBD pour garder le maître actif et l'esclave passif synchronisés en utilisant des copies de niveau bloc est ce dont vous avez réellement besoin ici.

À mon humble avis, tout d'abord, dans une configuration non multi-maître (maître / esclave), votre esclave ne devrait jamais prendre d'écritures. L'esclave my.cnf doit être configuré et le serveur démarré avec:

# Flag to not take writes from network
read-only

Ensuite, pour résoudre le problème d'un maître désynchronisé avec un esclave inscriptible prenant accidentellement des écritures, vous devez différencier les données sur les deux hôtes. S'il n'y a pas de collision de clés, vous devez promouvoir votre ancien hôte esclave en tant que maître et réimaginer votre ancien maître en tant qu'hôte esclave se reproduisant à partir du nouveau maître. (il pourrait y avoir / probablement des problèmes de données ici)

Enfin, si ce scénario de panne / arrêt est même une possibilité à l'avenir , prenez le temps de configurer les deux hôtes en tant que multi-maître (log-bin, id-serveur, décalages, etc.). Cela vous aidera à atténuer les pannes et les temps d'arrêt dans une certaine mesure.

Si vous devez exécuter maître / esclave , obtenez au moins quelques points bonus pour séparer les connexions utilisateur en lecture et en écriture dans votre ACL et vos applications.