MySQL InnoDB Cluster : exploitation courante et scénarios de panne (MySQL Shell 8.4)

Pas une installation : runbook par scénarios pour l'exploitation courante et la reprise après panne d'un InnoDB Cluster déjà en service (Group Replication + MySQL Router, mis en place avec l'AdminAPI de MySQL Shell). Choisissez une carte de scénario : contrôle de santé, ajout de membre (clone / incremental) et retrait (force compris), réintégration d'un membre tombé, redémarrage après arrêt complet du cluster (rebootClusterFromCompleteOutage), forceQuorumUsingPartitionOf en cas de perte de la majorité, changement planifié de primary, ajout / nouveau bootstrap de Router, options du cluster (consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction) et rescan() pour les métadonnées. Chaque scénario suit l'ordre diagnostic → filet de sécurité → mise en œuvre → vérification → suites. Pour créer le cluster pour la première fois, ouvrez le guide d'installation d'InnoDB Cluster ; pour la réplication source–replica classique, le guide d'exploitation de la réplication ; pour la migration 8.0 → 8.4, le guide de mise à niveau.

Topologie: 3–9 nœuds MySQL (single-primary) + MySQL Router

Scénarios

• État du cluster et contrôle de santé (tout va-t-il bien ?) — Lecture seule : cluster.status({extended: 1}), rôle/état/version des membres, files d'application, liste des Routers et error log ; rien n'est modifié, aucune interruption. En cas de doute ou après une alerte, commencez ici ; la dernière étape vous oriente vers le bon scénario.
• Ajouter un nouveau membre (addInstance : clone / incremental) — Vous voulez ajouter un nouveau nœud MySQL au cluster, augmenter la tolérance (3 → 5) ou réintégrer un nœud retiré. Le cluster reste ouvert en écriture ; pendant le clone, le donor subit une charge disque/réseau, et le nouveau nœud redémarre.
• Retirer un membre (removeInstance, force si nécessaire) — Vous voulez retirer définitivement un nœud du cluster (restitution de matériel, réduction), ou le nœud est perdu et doit être supprimé des métadonnées (force). Le retrait d'un secondary n'entraîne pas d'interruption ; celui du primary provoque une coupure d'écriture de quelques secondes.
• Réintégrer un membre tombé (MISSING / ERROR / OFFLINE) — Un membre a redémarré, a subi une coupure réseau ou a été exclu du groupe (expelled) ; la majorité fonctionne et l'application peut écrire. Avec rejoinInstance, le membre récupère ce qui lui manque et revient ; aucune interruption du cluster.
• Tout le cluster est arrêté : le redémarrer (rebootClusterFromCompleteOutage) — Tous les nœuds se sont arrêtés puis rallumés, à la suite d'une coupure électrique, d'un incident datacenter ou hyperviseur ; Group Replication ne tourne sur aucun membre, l'application ne peut pas écrire (l'interruption se prolonge). Le cluster est redémarré à partir du membre le plus à jour.
• Perte de la majorité (NO_QUORUM) : forcer le quorum avec les membres restants — La plupart des membres ont disparu en même temps (p. ex. 2 sur 3), les membres restants ont arrêté les écritures avec NO_QUORUM (les écritures restent bloquées). Si vous êtes certain que les membres disparus sont réellement arrêtés, le cluster est relancé avec la partition restante. Une mauvaise utilisation crée un split-brain ; la perte d'un seul membre (majorité intacte) ne relève pas de ce scénario.
• Changement planifié de primary (setPrimaryInstance) — Pour une maintenance (patch OS, matériel), l'équilibrage de charge ou un exercice de DR, vous voulez transférer de façon planifiée le rôle de primary à un secondary donné. Les écritures attendent quelques secondes, les transactions ouvertes sont terminées ; Router redirige de lui-même vers le nouveau primary.
• Ajouter un Router ou refaire son bootstrap — Vous voulez installer Router sur un nouveau serveur d'application, refaire le bootstrap d'un Router (montée de version, cluster recréé, avertissement routerErrors) ou nettoyer d'anciens enregistrements de Router. Pendant le nouveau bootstrap, les connexions applicatives passant par ce Router sont brièvement coupées.
• Modifier les options du cluster (consistency, expelTimeout, memberWeight…) — Vous voulez régler la cohérence au failover, le délai d'exclusion d'un membre lors d'instabilités réseau, la priorité de failover, la réintégration automatique ou le comportement d'un membre en cas d'erreur. La modification se fait cluster en marche, sans redémarrage ; consistency s'applique aux nouvelles sessions.
• Aligner les métadonnées sur le groupe réel (rescan) — cluster.status() mentionne un membre absent des métadonnées ou un ancien enregistrement qui ne fait plus partie du groupe (START GROUP_REPLICATION lancé à la main, ancien membre non supprimé, serveur réinstallé). Aucune interruption ; seules les métadonnées sont mises à jour.

Avant de commencer

• MySQL Shell … et MySQL … sont installés sur les nœuds concernés ; le cluster a été créé avec le guide d'installation d'InnoDB Cluster ou de façon équivalente avec l'AdminAPI (les métadonnées existent). Le root du système peut se connecter sans mot de passe avec le client local mysql. Prenez le nom du cluster du formulaire dans dba.getCluster().getName(), et les adresses des membres dans les lignes ip:port de la topologie de cluster.status().
• Le mot de passe du compte … est connu (identique sur chaque nœud). MySQL Shell demande le mot de passe à chaque connexion ; avec --save-passwords=never, il ne l'enregistre pas.
• Les nœuds se joignent mutuellement sur les ports MySQL (……:……, ……) et sur les ports de communication de Group Replication.
• Sur le nouveau nœud, MySQL … est installé dans la même version mineure que les membres du cluster (condition du clone), GTID est activé, server_id diffère de celui des autres nœuds et les paramètres Group Replication du guide d'installation figurent dans my.cnf ; les ports firewall/SELinux sont ouverts.
• Le serveur Router joint les nœuds sur le port MySQL… et peut accéder à repo.mysql.com….
• L'approbation du changement, la fenêtre de maintenance (si nécessaire) et la communication avec l'équipe applicative sont prêtes.

Phases du guide

• État : cluster, membres et Router (lecture seule) — Obtenir et enregistrer l'état détaillé du cluster · Contrôler les membres et les files en SQL · Parcourir les messages d'erreur de Group Replication · Contrôler le routage RW/RO via Router · Interpréter le résultat et choisir le bon scénario
• 1. Diagnostic : le nouveau nœud et le cluster sont-ils prêts ? — Vérifier la version et l'identité du nouveau nœud · Vérifier l'état du cluster et les versions des membres
• 2. Filet de sécurité — Enregistrer la topologie actuelle
• 3. Mise en œuvre : ajouter le membre — Configurer le nouveau nœud et créer le compte d'administration · Faire vérifier l'éligibilité du nouveau nœud par le cluster · Ajouter le nœud au cluster (…)
• 4. Vérification — Vérifier que le nouveau membre est ONLINE
• 5. Suites — Mettre à jour Router, la supervision et l'inventaire
• 1. Diagnostic : le retrait du membre est-il sans risque ? — Afficher l'état du membre cible et la tolérance restante
• 2. Filet de sécurité — Enregistrer la topologie actuelle
• 3. Mise en œuvre : retirer le membre — Retirer le membre du cluster… (force)…
• Si le nœud retiré avec force revient — Arrêter et nettoyer Group Replication sur le nœud revenu
• 4. Vérification — Vérifier les membres restants
• 5. Suites — Nombre impair, Router et supervision
• 1. Diagnostic : pourquoi le membre est-il tombé, peut-il être réintégré ? — État du membre cible vu par le cluster · Afficher l'état de MySQL et de Group Replication sur le nœud cible · Contrôle des transactions errant (présentes sur la cible, absentes du cluster)
• 2. Filet de sécurité — Enregistrer l'état actuel
• 3. Mise en œuvre : réintégrer le membre — Réintégrer le membre avec rejoinInstance
• 4. Vérification — Vérifier que le membre est ONLINE
• 5. Suites — Cause racine et réintégration automatique
• 1. Diagnostic : tout le cluster est-il réellement arrêté, quel est le membre le plus à jour ? — Démarrer MySQL sur chaque nœud et afficher l'état de Group Replication · Demander à Shell le membre le plus à jour (dryRun)
• 2. Filet de sécurité — Enregistrer l'ensemble GTID de tous les nœuds
• 3. Mise en œuvre : démarrer le cluster depuis le membre le plus à jour — Redémarrer le cluster
• 4. Vérification — Vérifier que tous les membres sont ONLINE
• 5. Suites — Router, application et cause racine
• 1. Diagnostic : le quorum est-il réellement perdu ? — Afficher l'état du cluster depuis le nœud resté en service
• 2. Filet de sécurité : isoler les membres disparus — S'assurer que les nœuds disparus sont arrêtés (fencing) · Enregistrer l'état de la partition restante
• 3. Mise en œuvre : forcer le quorum — Établir le quorum avec la partition restante
• 4. Vérification et retour des membres disparus — Vérifier que les écritures sont rouvertes · Réintégrer les membres disparus (…)
• 5. Suites — Revoir la topologie
• 1. Diagnostic : la cible peut-elle devenir primary ? — Vérifier l'état et les versions des membres
• 2. Filet de sécurité — Enregistrer l'état actuel
• 3. Mise en œuvre : changer de primary — Transférer le rôle de primary à …