Haute disponibilité d’un cluster MariaDB avec MaxScale

Cahier des charges

Un audit interne a mis en évidence un point faible classique. Un unique serveur MariaDB centralisait les bases de données de Zabbix, Guacamole, GLPI et Nextcloud. Ce serveur représentait un SPOF et sa panne aurait entraîné l’arrêt de l’ensemble des services applicatifs.

Solutions choisies

J’ai mis en place une réplication asynchrone maître-esclave entre deux nœuds MariaDB, pilotée par MaxScale comme proxy intelligent. MaxScale répartit les écritures vers le maître et les lectures vers l’esclave, et surveille le cluster pour basculer automatiquement en cas de panne. Les flux sont chiffrés en SSL/TLS avec des certificats issus de la CA interne. Les sauvegardes s’exécutent sur le nœud esclave, pour ne jamais dégrader les performances du maître.

Mise en œuvre

Environnement technique :
MariaDB - MaxScale - GTID - TLS

1. Installation et durcissement des deux serveurs MariaDB, sur des VMs distinctes

2. Installation de MaxScale sur un nœud dédié, distinct des deux serveurs MariaDB

3. Configuration de la réplication asynchrone maître-esclave, synchronisée par GTID pour tracer les transactions et simplifier les bascules

4. Configuration des journaux binaires au format ROW, et restriction du nœud esclave en lecture seule

5. Sécurisation des flux de réplication par certificats SSL/TLS issus de la CA interne

6. Configuration de MaxScale pour le Read/Write splitting et la surveillance du cluster toutes les 5 secondes

7. Mise en place de MariaDB Backup sur le nœud esclave, pour ne pas dégrader les performances du maître

8. Validation du failover automatique et de la procédure de switchover manuel

Tests et imprévus

Le test de sauvegarde et de restauration complète a été validé sans accroc. Le failover automatique du maître vers l’esclave a également été confirmé, conformément au comportement attendu de MaxScale. Le test de switchover, une bascule manuelle et réversible, a en revanche révélé un problème. Une fragmentation du privilège SUPER dans les versions récentes de MariaDB a cassé la procédure standard. J’ai dû revoir les droits de l’utilisateur MaxScale, reconfigurer l’utilisateur de réplication en mode miroir sur le nouveau maître, puis rétablir le serveur d’origine comme maître nominal via l’API REST de MaxScale. Ce problème n’était documenté nulle part et ne s’est révélé qu’en pratique.

Bilan

Le cluster répond à l’objectif de haute disponibilité fixé au départ, à savoir un failover automatique fonctionnel, et une procédure de switchover corrigée après le problème de privilège SUPER. Passer à un cluster Galera à trois nœuds en réplication synchrone multi-maître éliminerait le risque de perte de données inhérent à l’asynchrone. C’est l’évolution que j’envisagerais si ce projet devait passer en production.