MySQL double maître

Question

Pour mon projet actuel, nous envisageons de configurer une topologie de réplication à maître double pour une configuration géographiquement séparée. un db sur la côte est américaine et l'autre au japon. Je suis curieux de savoir si quelqu'un a essayé cela et quelle a été son expérience.

De plus, je suis curieux de savoir quelles sont mes autres options pour résoudre ce problème; nous envisageons des files de messages.

Merci!

Answer 1

Juste une note sur les aspects techniques de votre plan: vous devez savoir que MySQL ne prend pas officiellement en charge la réplication multi-maîtres (seul MySQL Cluster prend en charge la réplication synchrone).

Mais il y a au moins un & hack " cela rend possible la réplication multi-maîtres même avec une configuration de réplication MySQL normale. Veuillez consulter la "Réplication multimaître MySQL" de Patrick Galbraith pour une solution éventuelle. Je n'ai aucune expérience de cette configuration, je n'ose donc pas juger de la faisabilité de cette approche.

Answer 2

Plusieurs éléments doivent être pris en compte lors de la réplication géographique des bases de données. Si vous effectuez cette opération pour des raisons de performances, assurez-vous que votre modèle de réplication prend en charge la cohérence de vos données. car cela peut prendre du temps d’apporter le courant de réplication dans les deux ou plusieurs endroits. Si votre débit ou vos temps de réponse entre les emplacements ne sont pas satisfaisants, la réplication active peut ne pas être la meilleure option.

Answer 3

Configurer mysql en tant que maître double fonctionne vraiment bien si le scénario est correct. Mais je ne suis pas sûr que cela convienne très bien à votre scénario.

Tout d’abord, la configuration double maître dans mysql est vraiment une configuration en anneau. Le serveur A est défini en tant que maître de B, tandis que B est défini en même temps en tant que maître de A, de sorte que les deux serveurs agissent à la fois en tant que maître et esclave. La réplication fonctionne en envoyant un journal binaire contenant les instructions SQL que l'esclave insère à sa guise, ce qui est généralement tout de suite. Mais si vous le martelez avec des insertions locales, il faudra un certain temps pour le rattraper. Les insertions d'esclaves sont séquentielles au passage, vous ne tirerez donc aucun avantage des cœurs multiples, etc.

L’utilisation principale de dual master mysql est la redondance au niveau du serveur avec le basculement automatique (souvent à l’aide de Hearbeat sur Linux). Si l'on exclut mysql-cluster (pour diverses raisons), il s'agit du seul basculement automatique utilisable pour mysql. La configuration pour le double maître de base se trouve facilement sur google . Le battement de coeur est un peu plus de travail. Mais ce n’est pas vraiment ce que vous demandiez, car cela se comporte vraiment comme un serveur de base de données unique.

Si vous souhaitez une configuration double maître parce que vous souhaitez toujours écrire dans une base de données locale (écrivez-les simultanément), vous devez écrire votre application en gardant cela à l'esprit. Vous ne pouvez jamais avoir de valeurs auto-incrémentées dans la base de données, et lorsque vous avez des valeurs uniques, vous devez vous assurer que les deux emplacements n'écrivent jamais la même valeur. Par exemple, l'emplacement A pourrait écrire des numéros uniques impairs et l'emplacement B pourrait écrire même des numéros uniques. La raison en est que vous n'êtes pas assuré que les serveurs sont synchronisés à un moment donné. Par conséquent, si vous avez inséré une ligne unique dans A, puis une ligne unique superposée dans B avant que le second serveur ne se rattrape, avoir un système cassé. Et si quelque chose se brise en premier, tout le système s’arrête.

Pour résumer: c’est possible, mais vous aurez besoin de faire très attention si vous construisez un logiciel professionnel.

Answer 4

En raison de l’architecture un-à-plusieurs de la réplication MySQL, vous devez disposer d’un anneau de réplication avec plusieurs maîtres: c’est-à-dire que chacun se réplique dans une boucle. Pour deux, ils se répliquent l'un sur l'autre. Cela a été pris en charge depuis la v3.23.

Auparavant, j'ai travaillé avec la v3.23 avec un grand nombre de clients afin de fournir exactement ce que vous demandez. Nous avons utilisé des tunnels SSH sur Internet pour effectuer la réplication. Cela nous a pris un certain temps pour le rendre fiable et plusieurs fois, nous avons dû faire une copie binaire d’une base de données à une autre (heureusement, aucune d’elles ne dépassait 2 Go ni n’avait besoin d’un accès 24 heures sur 24). De plus, la réplication dans la v3 n’était pas aussi stable que dans la v4, mais même dans la v5, elle s’arrêtera si elle détecte une erreur quelconque.

Pour faire face au retard inévitable de la réplication, nous avons restructuré l’application afin qu’elle ne repose pas sur les champs AUTOINCREMENT (et supprimions cet attribut des tables). Ceci était relativement simple en raison de la couche d'accès aux données que nous avions développée; au lieu d'utiliser mysql_insert_id () pour les nouveaux objets, il a tout d'abord créé le nouvel ID et l'a inséré avec le reste de la ligne. Nous avons également implémenté les identifiants de sites que nous avons stockés dans la moitié supérieure, car ils étaient BIGINT . Cela signifiait également que nous n'avions pas à modifier l'application lorsque nous avions un client qui souhaitait disposer de la base de données à trois endroits. : -)

Ce n’était pas robuste à 100%. InnoDB gagnait juste en visibilité et nous ne pouvions pas utiliser facilement les transactions, même si nous y avions pensé. Il y avait donc parfois des conditions de concurrence lorsque deux objets essayaient d'être créés avec le même identifiant. Cela signifiait qu'un échouait et nous avons essayé de le signaler dans l'application. Cependant, le travail de quelqu'un consistait toujours à surveiller la réplication et à régler le problème quand il se cassait. Il est important de résoudre ce problème avant de trop nous désynchroniser, car dans quelques cas, les bases de données étaient utilisées dans les deux sites et deviendraient rapidement difficiles à réintégrer si nous devions en reconstruire un.

C’était un bon exercice, mais je ne le referais pas. Pas dans MySQL.