Pour MariaDB, MySQL et Percona, le commutateur d’auto-clustering de Stack Harbor PaaS construit une grappe de base de données de production depuis l’assistant de topologie. La grappe est livrée avec la réplication, l’auto-découverte des nouveaux membres, une couche de répartition de charge intégrée et l’exclusion automatique des nœuds injoignables.
Les bénéfices sont concrets :
- Haute disponibilité — réplication préconfigurée : primaire-secondaire, primaire-primaire, Galera, XtraDB.
- Scalabilité et auto-découverte — les nœuds ajoutés par redimensionnement horizontal rejoignent automatiquement la grappe.
- Répartition de charge — chaque grappe reçoit deux nœuds ProxySQL qui séparent le trafic de lecture et d’écriture.
- Bascule automatique — les nœuds inaccessibles ou trop en retard sont exclus de la grappe puis réintégrés une fois à jour.
Activer l’auto-clustering
Cliquez sur New Environment, choisissez MariaDB / MySQL / Percona, puis activez Auto-Clustering. Un menu de schémas apparaît avec les options propres au moteur :
- MariaDB — primaire-secondaire, primaire-primaire, Galera.
- MySQL — primaire-secondaire, primaire-primaire.
- Percona — primaire-secondaire, primaire-primaire, XtraDB.
Choisissez le schéma, fixez le nombre de nœuds, configurez le reste de l’environnement comme d’habitude.
Ce que vous obtenez d’office
Deux nœuds ProxySQL devant la grappe
Toute grappe MariaDB / MySQL / Percona reçoit par défaut deux nœuds ProxySQL placés devant la couche base de données. Si vous n’en avez pas besoin, vous pouvez les exclure au stade de la topologie. Vous ne pourrez pas les ajouter plus tard — cette décision est permanente une fois la grappe créée.
Identifiants générés, ou les vôtres
La plateforme génère des identifiants de base de données à la création et vous les envoie par courriel. Pour les remplacer par les vôtres, cliquez sur Variables et ajoutez deux entrées avant d’appliquer :
DB_USERDB_PASS
Appliquez, et les identifiants personnalisés vous sont envoyés par courriel avec les mêmes détails d’accès (phpMyAdmin sur le primaire, point d’entrée de la grappe).
Le scale-out étend la grappe
Pour les topologies primaire-secondaire et primaire-primaire, le scale-out ajoute un nouveau secondaire en clonant un secondaire existant. Une fois le clonage terminé, le nouveau nœud rattrape par lecture du binlog. La source étant un secondaire (pas le primaire), le binlog n’expire pas pendant l’opération et le scale-out se boucle dans une fenêtre courte.
Isolation des couches via SLB
Pour chaque couche de la grappe, vous choisissez si elle est exposée à l’extérieur de l’environnement via le SLB de la plateforme. Servez-vous-en pour n’exposer que le point d’entrée ProxySQL quand les applications vivent dans le même environnement, ou pour exposer plus de couches quand une application externe a besoin d’un accès direct.
Après l’installation — détails d’accès
La plateforme vous envoie plusieurs courriels une fois la grappe prête :
- phpMyAdmin sur le primaire — interface web et identifiants pour la gestion interactive de la base.
- Point d’entrée de la grappe — nom d’hôte et identifiants utilisés par votre application. Le nom d’hôte est
proxy.${envName}.${platformDomain}. - Panneau web ProxySQL — UI en lecture pour les statistiques de connexion, la performance des requêtes et la santé des backends.
Si vous créez des comptes base de données personnalisés après la mise en route et que vous voulez qu’ils fonctionnent via ProxySQL, vous devez les ajouter à la table mysql_users de chaque nœud ProxySQL. Depuis un shell sur chaque nœud ProxySQL :
MYSQL_PWD=admin mysql -h 127.0.0.1 -P6032 -uadmin -e \
"INSERT INTO mysql_users (username,password,default_hostgroup) VALUES ('<username>', '<password>', 2);"
MYSQL_PWD=admin mysql -h 127.0.0.1 -P6032 -uadmin -e \
"LOAD MYSQL USERS TO RUNTIME; SAVE MYSQL USERS TO DISK;"Sans cette étape, les connexions issues d’un compte base de données nouvellement créé échoueront au niveau du proxy.
Quel schéma de réplication choisir
Primaire-secondaire
Le motif le plus courant. Un nœud accepte les écritures ; les lectures peuvent être réparties sur les secondaires. Plus : bonne cohérence en écriture, faible latence d’écriture (le primaire commit localement avant de propager), le débit en lecture suit le nombre de secondaires, les secondaires peuvent servir aux sauvegardes et à l’analytique sans impacter le primaire. Moins : pas de bascule automatique à la défaillance du primaire — la promotion est manuelle ou pilotée par un outil externe.
Primaire-primaire
Deux primaires avec réplication asynchrone entre eux. Le scale-out ajoute des secondaires, répartis équitablement entre les deux primaires. Plus : les écritures peuvent être équilibrées entre les deux primaires, la récupération à la défaillance d’un primaire est plus simple. Moins : toujours asynchrone — des écritures concurrentes conflictuelles restent possibles si votre application ne partitionne pas les clés d’écriture.
Galera (MariaDB) et XtraDB (Percona)
Réplication synchrone multi-primaire : chaque transaction est diffusée à tous les nœuds de la grappe au moment du commit. Plus : lectures et écritures peuvent atteindre n’importe quel nœud, le scaling des lectures et des écritures est automatique, retirer ou ajouter un nœud n’exige pas de coordination manuelle, la protection contre la perte de données est forte parce que rien n’est validé tant que tous les membres ne l’ont pas reçu, l’application n’a pas besoin de connaître la séparation lecture / écriture. Moins : la latence d’écriture inclut le membre le plus lent ; la grappe est plus sensible aux conditions réseau entre membres.
Pages connexes
- Qu’est-ce que l’auto-clustering — quand l’activer et ce qui est configuré.
- Auto-clustering via l’assistant de topologie — référence au niveau de l’assistant.
- Auto-clustering PostgreSQL — équivalent PostgreSQL de cette page.
- Auto-clustering MongoDB — pour les charges NoSQL.
- Aperçu de l’hébergement BD, grappe multi-régions et les modules de récupération, sauvegarde / restauration et diagnostic de corruption.