MySQL dans une topologie en étoile

Il existe une raison spécifique pour laquelle ce que vous proposez est impossible à réaliser avec MyISAM et InnoDB.

Une topologie en étoile justifie que le maître soit le centre de l'univers, et non l'esclave. La réplication MySQL n'a pas été conçue pour qu'un esclave puisse lire simultanément à partir de plusieurs maîtres. Il ne peut lire qu'à partir d'un seul maître à la fois. Le site CHANGER LE MAÎTRE EN connecte un esclave à un, et un seul, maître.

Selon le livre Comprendre les mécanismes internes de MySQL , page 219, paragraphe 2, sous le sous-titre "Multi-Master" dit ce qui suit :

La réplication MySQL n'était pas à l'origine écrit avec un support multi-maître en tête l'esprit. Un esclave est nativement capable de répliquer un seul maître. Un patch assez patch assez simple peut être créé pour permettre un esclave de recueillir des mises à jour de plusieurs maîtres sans résolution de conflit. résolution de conflits. Cela a été fait à un moment donné, mais pour un certain nombre de raisons n'a pas dans la branche principale du projet l'arbre des sources. Un patch plus complexe pour permettant une certaine résolution des conflits a été conflit était prévu à un moment donné, mais pour un certain nombre pour un certain nombre de raisons, il n'a pas été développement. Il peut toujours être être implémentée dans le futur.

Le livre MySQL haute performance : Optimisation, sauvegardes, réplication et plus encore a un encadré en haut de la page 364 (Chapitre 8 : Topologies de réplication) dont le titre est "MySQL ne supporte pas la réplication multimaster" . La boîte comporte les paragraphes suivants :

Nous utilisons le terme multimaître réplication très spécifiquement à décrire un esclave avec plus d'une maître. Indépendamment de ce que l'on a pu on vous a dit, MySQL (contrairement à certains d'autres serveurs de bases de données) ne supporte pas la configuration illustrée illustrée par la figure 8-6. Cependant, nous vous montrons quelques façons d'émuler réplication multimaître plus loin dans ce chapitre .

Malheureusement, de nombreuses personnes utilisent ce terme pour décrire toute configuration où il y a plus d'un maître dans l'ensemble de la topologie, comme la topologie " arborescente " présentée plus loin dans ce chapitre. D'autres personnes l'utilisent pour pour décrire ce que nous appelons la réplication maître-maître maître, où les serveurs sont mutuellement maître et esclave.

Ces problèmes de terminologie causent beaucoup confusion et même des disputes, donc nous pensons qu'il est préférable d'être prudent avec noms. Imaginez simplement combien il sera difficile difficile de communiquer si MySQL ajoute le support d'un esclave avec deux maîtres ! Quel terme utiliserez-vous pour décrire cela si vous n'avez pas réservé "réplication multimaître" pour cet cette fin ?

Bien que les techniques d'émulation énumérées aux pages 373-375 sous le sous-titre "Emulation de la réplication multimaître" soient théoriquement possibles (en utilisant le moteur de stockage BLACKHOLE) et qu'elles aient été mises en œuvre avec succès par d'autres pour émuler seulement deux maîtres, elles ne pourront jamais supporter la topologie que vous proposez.

Je m'étais adressé cette question avant . En fait, la réponse que j'ai donnée ici est constamment appliquée avec succès. C'est pourquoi les vendeurs d'assurance peuvent apporter un ordinateur portable au domicile d'une personne et recueillir des données sur une personne qui demande une assurance. Le vendeur peut éventuellement se connecter à un ordinateur central pour télécharger la demande d'un nouveau client. À son tour, l'ordinateur central peut télécharger les dernières informations de l'actuaire afin de calculer au prorata le coût de la police pour le demandeur. Le principe est le même que pour la connexion d'un ordinateur portable à un ordinateur central, un ordinateur portable à la fois.