Dans un blog précédent, nous avions expliqué comment migrer une configuration Moodle autonome vers une configuration évolutive basée sur une base de données en cluster. La prochaine étape à laquelle vous devrez penser est le mécanisme de basculement - que faites-vous si et quand votre service de base de données tombe en panne.
Un serveur de base de données défaillant n'est pas inhabituel si vous avez la réplication MySQL comme base de données Moodle, et si cela se produit, vous devrez trouver un moyen de récupérer votre topologie en promouvant par exemple un serveur de secours pour devenir un nouveau serveur principal. Le basculement automatique de votre base de données Moodle MySQL améliore la disponibilité des applications. Nous vous expliquerons comment fonctionnent les mécanismes de basculement et comment intégrer le basculement automatique dans votre configuration.
Architecture haute disponibilité pour la base de données MySQL
Une architecture à haute disponibilité peut être obtenue en regroupant votre base de données MySQL de différentes manières. Vous pouvez utiliser la réplication MySQL, configurer plusieurs répliques qui suivent de près votre base de données principale. En plus de cela, vous pouvez mettre un équilibreur de charge de base de données pour diviser le trafic en lecture/écriture et répartir le trafic entre les nœuds en lecture-écriture et en lecture seule. L'architecture de haute disponibilité de la base de données utilisant la réplication MySQL peut être décrite comme suit :
Il se compose d'une base de données principale, de deux répliques de base de données et d'équilibreurs de charge de base de données (dans ce blog, nous utilisons ProxySQL comme équilibreurs de charge de base de données) et keepalived en tant que service pour surveiller les processus ProxySQL. Nous utilisons l'adresse IP virtuelle comme une connexion unique à partir de l'application. Le trafic sera distribué à l'équilibreur de charge actif en fonction de l'indicateur de rôle dans keepalived.
ProxySQL est capable d'analyser le trafic et de comprendre si une requête est une lecture ou une écriture. Il transmettra ensuite la demande au(x) hébergeur(s) approprié(s).
Basculement sur la réplication MySQL
MySQL Replication utilise la journalisation binaire pour répliquer les données du primaire vers les répliques. Les répliques se connectent au nœud principal, et chaque modification est répliquée et écrite dans les journaux de relais des nœuds de réplique via IO_THREAD. Une fois les modifications stockées dans le journal de relais, le processus SQL_THREAD procède à l'application des données dans la base de données répliquée.
Le paramètre par défaut pour le paramètre read_only dans un réplica est activé. Il est utilisé pour protéger la réplique elle-même de toute écriture directe, de sorte que les modifications proviendront toujours de la base de données principale. Ceci est important car nous ne voulons pas que la réplique diverge du serveur principal. Le scénario de basculement dans MySQL Replication se produit lorsque le principal n'est pas accessible. Il peut y avoir plusieurs raisons à cela; par exemple, des pannes de serveur ou des problèmes de réseau.
Vous devez promouvoir l'un des réplicas en principal, désactiver le paramètre de lecture seule sur le réplica promu afin qu'il puisse être accessible en écriture. Vous devez également modifier l'autre réplica pour vous connecter au nouveau principal. En mode GTID, vous n'avez pas besoin de noter le nom du journal binaire et la position à partir de laquelle reprendre la réplication. Cependant, dans la réplication traditionnelle basée sur le journal binaire, vous devez absolument connaître le dernier nom de journal binaire et la position à partir de laquelle continuer. Le basculement dans la réplication basée sur binlog est un processus assez complexe, mais même le basculement dans la réplication basée sur GTID n'est pas anodin non plus, car vous devez faire attention à des choses comme les transactions errantes. Détecter une panne est une chose, puis réagir à la panne dans un court délai n'est probablement pas possible sans automatisation.
Comment ClusterControl active le basculement automatique
ClusterControl a la capacité d'effectuer un basculement automatique pour votre base de données Moodle MySQL. Il existe une fonction de récupération automatique pour le cluster et le nœud qui déclenchera le processus de basculement lorsque la base de données principale tombe en panne.
Nous allons simuler comment le basculement automatique se produit dans ClusterControl. Nous allons faire planter la base de données principale et voir simplement sur le tableau de bord ClusterControl. Ci-dessous la topologie actuelle du cluster :
La base de données principale utilise l'adresse IP 10.10.10.11 et les répliques sont :10.10.10.12 et 10.10.10.13. Lorsque le crash se produit sur le primaire, ClusterControl déclenche une alerte et un basculement démarre comme indiqué dans l'image ci-dessous :
L'un des réplicas sera promu au rang principal, ce qui entraînera la topologie comme dans l'image ci-dessous :
L'adresse IP 10.10.10.12 sert désormais le trafic d'écriture en tant que principal, et nous nous retrouvons également avec une seule réplique qui a l'adresse IP 10.10.10.13. Côté ProxySQL, le proxy détectera automatiquement le nouveau primaire. Le groupe d'hôtes (HG10) dessert toujours le trafic d'écriture qui a le membre 10.10.10.12 comme indiqué ci-dessous :
Hostgroup (HG20) peut toujours servir le trafic de lecture, mais comme vous pouvez le voir le nœud 10.10.10.11 est hors ligne à cause du crash :
Une fois que le serveur défaillant principal revient en ligne, il ne sera pas automatiquement -introduit dans la topologie de la base de données. Cela permet d'éviter de perdre des informations de dépannage, car la réintroduction du nœud en tant que réplica peut nécessiter le remplacement de certains journaux ou d'autres informations. Mais il est possible de configurer la jonction automatique du nœud défaillant.
