2 votes

Comment effectuer la réplication des données pour les bases de données sur une configuration de conteneur Docker multi-serveur ?

Setup Sketch

Pour mettre en place une topologie de Disaster Recovery en utilisant Docker, est-il possible d'effectuer une réplication de données d'un serveur à l'autre sans utiliser de couche d'orchestration (swarm/Kubernetes) ? Comment configurer MySQL Master-Master ou Master-Slave sur une configuration à 2 serveurs ?

Ce que je ne veux PAS :

  1. Réplication des données à l'aide d'un espace disque partagé
  2. Pas d'outil/logiciel tiers
  3. Pas de Swarm ou de Kubernetes

Je comprends que pour un système de reprise après sinistre correct, il est recommandé que le système de secours se trouve dans une région totalement différente, et qu'il est acceptable qu'il y ait un retard dans la réplication des données. Ce que je veux savoir, c'est si les deux conteneurs Docker seront en mesure de communiquer correctement entre eux ? Y a-t-il quelque chose qui doit être configuré ? Ou est-ce qu'ils communiqueront normalement comme ils l'auraient fait sans docker ?

4voto

Martin Broadhurst Points 3777

Les services hautement disponibles sont つい construit avec seulement deux nœuds. Vous avez besoin au moins trois, pour atténuer les problèmes de cerveau divisé. Dans le cas d'une distribution géographique, ce problème est encore plus important que pour les services physiquement co-localisés ; n'essayez pas de l'ignorer si vous tenez à vos données et à votre temps de disponibilité. Si vous ne pouvez pas vous permettre d'avoir trois nœuds, il vaut mieux ne pas faire de HA du tout, ou vos tentatives pour obtenir un meilleur service ne feront qu'empirer les choses.

Ceci étant établi, je vous suggère d'utiliser Galera. Il s'agit d'une réplication multi-maître intégrée à MariaDB moderne (un clone de MySQL par le même auteur, un remplacement direct). Comme prévu, il faut trois nœuds, mais seuls deux d'entre eux doivent être des serveurs à part entière, et le troisième peut être ce qu'on appelle un nœud d'arbitrage (conçu pour départager les participants dans un processus de sélection du quorum).

Vous créez donc deux conteneurs contenant des données et une troisième machine jouant le rôle d'arbitre. Vous pouvez également faire du troisième nœud un serveur à part entière, mais ne l'utiliser que pour effectuer des sauvegardes de bases de données, afin que les serveurs primaires ne soient pas bloqués lorsque la sauvegarde est en cours d'exécution. Il est également préférable d'en faire une source SST privilégiée, de sorte que si un serveur redémarre et a besoin d'un SST, il n'étouffera pas l'autre pendant le processus SST. Il est important que le troisième nœud soit situé au troisième endroit, et non pas au même endroit que les deux serveurs principaux, de sorte qu'il puisse être un véritable facteur de rupture d'égalité.

J'utilise une telle installation Galera géographiquement dispersée, les instances MariaDB communiquent via des VPN et cela fonctionne bien.

2voto

Rick James Points 1796

Deux serveurs de base de données, physiquement proches l'un de l'autre, permettront d'atteindre l'objectif.

  • Il y aura toujours un certain décalage entre le primaire et la réplique, mais il sera probablement inférieur à 1 ms.
  • Le réplica ne commencera pas à exécuter une requête répliquée tant qu'il n'aura pas fait un COMMIT sur le Primary. (Tant que vos écritures n'affectent qu'un petit nombre de lignes, ce délai est également inférieur ou égal à quelques millisecondes.
  • S'il s'agit d'un système maître-maître, chacun est autorisé à recevoir des écritures et chacun est à la fois "maître" et "esclave". Cependant, je recommande de n'écrire que sur l'un d'entre eux à la fois ; l'autre est simplement en attente à chaud.
  • M-M est M-S déjà mis en place dans les deux sens, ce qui permet un basculement simplifié.
  • Le fait que chaque serveur de base de données se trouve dans un conteneur Docker ne devrait pas avoir d'importance.
  • Mais le fait d'avoir deux machines séparées permet d'assurer le DR, alors que deux Dockers dans un seul serveur ne protègent pas contre les défaillances de la carte mère, du disque, etc.
  • Les éléments nécessaires au basculement font partie de la version standard de MySQL/MariaDB, mais l'exécution d'un basculement reste manuelle.
  • Si l'une des deux machines tombe en panne, vous devez déployer des efforts non négligeables (et du temps) pour reconstruire l'autre machine.
  • Deux machines situées dans la même plaine inondable, la même faille sismique, la même allée de tornades, etc. -- Pour un véritable DR, il faut une séparation géographique. Mais cela entraîne une latence entre les serveurs. On ne peut pas tout avoir !

Voir aussi Galera Cluster (livré avec MariaDB ; ou peut être ajouté à MySQL). Avec ce système, 3 "nœuds", un par serveur, permettent un basculement et une réparation automatiques.

Pour autant que je sache, Docker n'introduit pas d'obstacles supplémentaires. Peut-être que quelqu'un d'autre pourra me répondre. S'il y a plusieurs instances MySQL dans plusieurs Dockers, alors il y a un problème pour séparer les numéros de port.

PS. dba.stackoverflow.com est un meilleur site pour les questions relatives à MySQL/MariaDB.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X