Stratégie de récupération pour la réplication Master-Master

J'ai implémenté une solution HA pour mysql basée sur la réplication maître-maître. Il y a un mécanisme sur la partie frontale qui garantit qu'une seule base de données sera lue / écrite à un moment donné (c'est-à-dire que nous n'utilisons que la réplication pour HA).

J'ai confirmé que la réplication fonctionne comme prévu, mais je m'interroge sur le scénario de défaillance et la récupération. En particulier, je m'inquiète de ce qui se passe lorsqu'un maître échoue dans un état irrécupérable et doit être recréé à partir de l'autre maître:

• Comme l'autre maître est en direct et probablement utilisé, je ne peux pas le verrouiller et créer des vidages à partir de mysqldump(nos bases de données sont modérément volumineuses et mysqldumppeuvent facilement prendre des heures après quelques mois d'utilisation).
• Même en supposant que j'ai un vidage, il est crucial que la position du journal des événements comme indiqué par SHOW MASTER STATUS corresponde au vidage en cours après le verrouillage de la base de données.

La solution simple au premier problème est d'utiliser une troisième base de données faisant office de sauvegarde, à partir de laquelle je peux faire le mysqldump. Mais comment puis-je m'assurer que le maître recréé peut démarrer la réplication à partir du maître en cours d'exécution de manière cohérente?

Je connais deux approches de base à ce problème. Premièrement, si vous exécutez InnoDB au lieu de Myisam, vous pouvez effectuer la sauvegarde dans une transaction (--single-transaction --lock-tables = FALSE), qui combinée avec --flush-logs (non requis mais agréable) et --master-data vous donnera une sauvegarde cohérente avec les informations de position de réplication. Les journaux de vidage réinitialiseront les journaux avant la création du vidage, ce qui signifie que la position sera toujours 106, et --master-data mettra le nom et la position du fichier journal directement dans le fichier de vidage. Bien sûr, vous devez l'exécuter sur le maître pour que --master-data fonctionne.

La deuxième façon, que vous avez mentionnée, consiste à utiliser un troisième hôte pour créer les sauvegardes. Dans ce cas, vous devez arrêter la réplication, assurez-vous que la base de données est en lecture seule (bien qu'en réalité, toutes vos répliques doivent être en lecture seule car cela n'affecte pas les écritures de la réplication), puis créez votre sauvegarde ET enregistrez la position de réplication. Vous ne pouvez pas utiliser --master-data dans ce cas. Au lieu de cela, vous pourriez faire quelque chose comme ceci:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Si jamais vous avez besoin de restaurer à partir de cette sauvegarde, vous exécutez la restauration puis configurez la réplication où les deux paramètres master_log_file et master_log_pos proviennent du fichier DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Remarque: vous pouvez ET DEVRIEZ tester cela à partir d'une autre réplique.

Remarque supplémentaire: si vous disposez d'un pool de répliques (par exemple, si vous avez séparé les lectures des écritures pour une application Web), il est possible que les répliques soient désynchronisées avec le nouveau maître; cela peut se produire si le basculement se produit pendant une période d'E / S d'écriture importante, car les réplicas sont diffusés de manière asynchrone et il n'y a aucune garantie que votre veille se trouve à la même position que les autres répliques lorsque vous basculez. Cependant, cela ne m'est pas encore arrivé ...