Quels sont les trois modes de réplication Mysql maître et esclave ?

Réplication asynchrone MySQL

La réplication asynchrone MySQL est le mode de réplication par défaut pendant le processus de réplication maître-esclave. La réplication implique trois threads, dont le thread d'E/S maître, le thread d'E/S esclave et le thread SQL esclave. Puisqu'il s'agit d'une réplication asynchrone, la soumission de la transaction maître n'a pas besoin d'être confirmée par l'esclave. Autrement dit, une fois que le thread d'E/S maître a soumis la transaction, il n'a pas besoin d'attendre la réponse de l'esclave I. /O thread. Le maître ne garantit pas que le binlog sera écrit dans le relais dans le journal ; une fois que l'E/S esclave a écrit le binlog dans le journal du relais, il est exécuté de manière asynchrone par le thread SQL esclave et appliqué au mysql esclave. Les E/S esclaves ne nécessitent pas de confirmation de réponse de la part de SQL esclave et ne garantissent pas que le journal du relais est entièrement écrit dans MySQL.

Réplication semi-synchrone

Afin de combler les lacunes de la réplication asynchrone traditionnelle, MySQL a introduit la réplication semi-synchrone dans la version 5.5, qui constitue une amélioration par rapport à la réplication asynchrone traditionnelle. Avant que la transaction maître ne soit validée, il faut s'assurer que le journal binlog a été écrit dans le journal de relais de l'esclave. Ce n'est qu'après avoir reçu la réponse de l'esclave au maître que la transaction peut être validée. Malgré cela, la seconde moitié du journal de relais sera toujours transmise au thread SQL pour une exécution asynchrone.

Réplication de groupe

Basé sur les défauts de la réplication asynchrone traditionnelle et de la réplication semi-synchrone - la cohérence des données ne peut pas être garantie, MySQL a officiellement lancé la réplication de groupe (MGR) dans la version 5.7.17.

Un groupe de réplication est composé de plusieurs nœuds. La soumission d'une transaction doit être résolue et approuvée par la majorité des nœuds du groupe (N/2 + 1) avant de pouvoir être soumise. Comme le montre la figure ci-dessus, un groupe de réplication se compose de 3 nœuds. La couche Consensus est la couche de protocole de cohérence. Pendant le processus de soumission de transaction, la communication entre les groupes n'a lieu que lorsque 2 nœuds résolvent (certifient) la transaction. être enfin résolu. Soumettez et répondez.

L'objectif principal de l'introduction de la réplication de groupe est de résoudre le problème d'incohérence des données causé par la réplication asynchrone traditionnelle ou la réplication semi-synchrone. La réplication de groupe s'appuie sur le protocole de cohérence distribuée (une variante du protocole Paxos) pour atteindre la cohérence ultime des données distribuées et fournir une véritable solution de haute disponibilité des données (la question de savoir si elle est réellement hautement disponible reste à discuter). La solution multi-écriture qu’elle propose nous donne l’espoir de parvenir à une solution multi-active.

Dans l'environnement MGR, le nombre de serveurs doit être supérieur à 3 et un nombre impair pour implémenter l'algorithme 2/n+1.

Un groupe de réplication se compose de plusieurs nœuds (instances de base de données). Chaque nœud du groupe conserve sa propre copie de données (Share Nothing) et implémente des messages atomiques et des messages ordonnés globaux via le protocole de cohérence pour implémenter des instances au sein du groupe. Cohérence des données.

Caractéristiques dont dispose désormais la solution MGR

Garantie de cohérence des données : Assurez-vous que la plupart des nœuds du cluster reçoivent les journaux

Prise en charge de l'écriture multi-nœuds : Tous les nœuds du cluster sont pris en charge en mode multi-écriture Écriture (mais en considérant des scénarios de simultanéité de 1 à élevée pour garantir une haute cohérence des données, la production ne choisit pas l'écriture multi-maître et utilise un cluster à maître unique)

Tolérance aux pannes : Assurez-vous que le système est toujours disponible en cas de panne (y compris split brain), la double écriture n'a aucun impact sur le système

L'impact actuel de la solution de MGR

• ne prend en charge que les tables InnoDB, et chaque table doit avoir une clé primaire pour la détection des conflits de l'ensemble d'écriture

• doit être ; activé la fonction GTID, le format de journal binaire doit être défini sur ROW, utilisé pour la sélection principale et le jeu d'écriture

• COMMIT peut provoquer un échec, similaire au scénario d'échec du niveau d'isolement des transactions d'instantané

• Actuellement, un MGR le cluster prend en charge jusqu'à 9 nœuds

• Ne prend pas en charge les clés étrangères et les fonctionnalités de point de sauvegarde, ne peut pas effectuer de détection de contrainte globale et de restauration partielle

• Le journal binaire ne prend pas en charge la somme de contrôle des événements binlog

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!