Maison > base de données > tutoriel mysql > La différence entre le cluster MySQL et le maître-esclave

La différence entre le cluster MySQL et le maître-esclave

(*-*)浩
Libérer: 2020-09-15 16:46:37
original
16674 Les gens l'ont consulté

La différence entre cluster et maître-esclave dans mysql : la cohérence des données est assurée entre maître et esclave via la réplication mysql par rapport à la méthode de synchronisation des données du cluster mysql, elle est asynchrone. Comme il est asynchrone, il peut y avoir un léger retard dans la copie des données entre le maître et l'esclave, et des incohérences peuvent survenir.

La différence entre le cluster MySQL et le maître-esclave

Cours recommandé : Tutoriel MySQL.

La cohérence des données est assurée entre maître et esclave grâce à la réplication mysql. Par rapport à la méthode de synchronisation des données du cluster mysql, elle est asynchrone.

Le cluster utilise PXC (Percona XtraDB Cluster), les données multi-nœuds sont synchronisées en temps réel (lecture et écriture)

A propos de maître-esclave

Maître-esclave peut assurer la séparation de la lecture et de l'écriture, c'est-à-dire que l'opération d'écriture est sur le maître et l'opération de lecture est sur l'esclave. Il existe également plusieurs modes maître-esclave. ne parlez que d'un maître et de plusieurs esclaves.

Par exemple, il existe deux modules commerciaux. Un module écrit en continu les enregistrements de commandes, etc., et l'autre module génère des rapports. Si la séparation de lecture et d'écriture n'est pas adoptée à ce moment, les opérations de lecture et d'écriture le seront. entrer en collision, ce qui peut provoquer des conflits et affecter les performances, si la lecture et l'écriture sont séparées, il n'est pas nécessaire d'envisager de lire et d'écrire la même table pour affecter les performances, et plusieurs esclaves peuvent bien partager la pression sur le serveur et réduire la pression sur un une seule machine.

Le maître et l'esclave utilisent la réplication MySQL pour assurer la cohérence des données. Par rapport à la méthode de synchronisation des données du cluster, elle est asynchrone. En raison de l'asynchrone, il peut y avoir un léger retard dans la copie des données entre le maître et l'esclave. . Des retards et des incohérences se produiront.

La différence entre le cluster MySQL et le maître-esclave

Réplication : le nœud maître doit activer binlog, définir un identifiant de serveur unique (unique dans le réseau local), définir l'identifiant de serveur du nœud esclave, et le binlog enregistre toutes les informations sur le maître. L'opération sera copiée dans le relaylog du nœud esclave et relue sur le nœud esclave.

Mais le maître-esclave présente également des inconvénients. L'un est qu'il ne répond pas à la haute disponibilité. Le maître est en panne et doit être commuté manuellement. L'activité sera interrompue et n'est pas autorisée. 🎜>L'autre est que les données sont incohérentes et non cohérentes. Il existe de nombreuses raisons possibles. Voici quelques-unes des plus courantes

    Le temps d'arrêt est inattendu. peut endommager les fichiers binlog ou relaylog, entraînant une incohérence maître-esclave (il y a un article dans ce blog, qui a été corrigé après le temps d'arrêt)
  • Si défini sql_log_bin=0. est exécuté avant que la bibliothèque principale n'effectue des modifications, la bibliothèque principale n'enregistrera pas le binlog et la bibliothèque esclave ne pourra pas modifier cette partie des données
  • Le format du binlog de la bibliothèque principale is Statement, ce qui peut provoquer une incohérence maître-esclave après la synchronisation avec la bibliothèque esclave.
  • Le nœud esclave n'est pas défini en lecture seule, écrit les données par erreur
  • Les versions des instances maître et esclave sont incohérentes, surtout lorsque la version supérieure est le maître et la version inférieure est l'esclave, les fonctions prises en charge par la base de données maître peuvent ne pas être prises en charge par la base de données esclave. la fonction n'est pas prise en charge
  • BUG MySql
  • Ensuite, vous devez faire attention aux points suivants lorsque vous l'utilisez

    Le binlog de la bibliothèque principale adopte le format ROW
  • Les versions de la base de données des instances maître et esclave doivent être cohérentes
  • La bibliothèque principale doit contrôler les autorisations du compte. Vous pouvez exécuter set sql_log_bin=0
  • Activer la lecture seule à partir de la bibliothèque et ne pas autoriser l'écriture humaine
  • Effectuez régulièrement une vérification de cohérence maître-esclave

À propos du clusterLe plus grand avantage du cluster est le temps réel synchronisation des données, haute disponibilité et les données de chaque nœud sont synchronisées. Cohérent, contrairement au maître-esclave, où une incohérence des données se produit parfois, et haute disponibilité, tout temps d'arrêt du nœud n'affectera pas l'entreprise.

Mais l'inconvénient est la performance, la performance d'écriture. Chaque opération d'écriture sera synchronisée entre tous les nœuds. Il y a des gains et des pertes, ce qui garantit une haute disponibilité et la cohérence des données.

Dans le cluster, il y a un nœud de gestion et plusieurs nœuds SQL et nœuds de données. La réplication synchrone est utilisée entre les nœuds de données pour garantir la cohérence des données entre les nœuds. Généralement, elle est soumise en deux étapes. est la suivante

    Lorsque le maître exécute l'instruction de validation, la transaction est envoyée à l'esclave et l'esclave commence à se préparer à la soumission de la transaction
  • Chaque esclave doit préparer la transaction puis envoyer un message OK (ou ABORT) au maître, indiquant que la transaction est prête (ou que la transaction ne peut pas être préparée)
  • Le maître attend que tous les esclaves envoient un message OK ou ABORT
  • Si le maître reçoit des messages OK de tous les esclaves, il enverra un message de validation à tous les esclaves, indiquant à l'esclave de soumettre le transaction ;

Si le maître reçoit un message ABORT d'un esclave, il envoie un message ABORT à tous les esclaves, indiquant à l'esclave d'abandonner la transaction.

    Chaque esclave attend un message OK ou ABORT du maître
  • Si l'esclave reçoit une demande de validation, il validera la transaction et l'envoyer au Maître envoie une confirmation que la transaction a été validée ;

Si l'Esclave reçoit une demande d'annulation, il annulera toutes les modifications et libérera les ressources qu'il occupe, annulant ainsi la transaction, puis enverra à Masterv la confirmation que le la transaction a été interrompue.

  • Lorsque le maître recevra la confirmation de tous les esclaves, il signalera que la transaction a été validée (ou abandonnée), puis passera à la transaction suivante

Étant donné que la réplication synchrone nécessite un total de 4 transferts de messages, la vitesse de mise à jour des données du cluster mysql est plus lente que celle du mysql autonome. Par conséquent, le cluster MySQL doit fonctionner dans un réseau local supérieur au Gigabit. Les nœuds peuvent utiliser deux cartes réseau et les groupes de nœuds sont directement connectés pour garantir la vitesse de mise à jour des données.

La différence entre le cluster MySQL et le maître-esclave

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!

Étiquettes associées:
source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal