Le basculement automatisé est à peu près indispensable pour de nombreuses applications - la disponibilité est considérée comme acquise. Il est assez difficile d'accepter qu'une application soit indisponible pendant 20 ou 30 minutes car quelqu'un doit être appelé pour se connecter et enquêter sur la situation avant d'agir.
Dans le monde réel, les configurations de réplication ont tendance à se développer avec le temps pour devenir complexes, parfois désordonnées. Et il y a des contraintes. Par exemple, tous les nœuds d'une configuration ne constituent pas un bon candidat maître. Peut-être que le matériel diffère et que certaines des répliques ont un matériel moins puissant car elles sont dédiées à la gestion de certains types spécifiques de charge de travail ? Peut-être êtes-vous en train de migrer vers une nouvelle version de MySQL et certains des esclaves ont déjà été mis à jour ? Vous préférez ne pas avoir de maître dans une version plus récente répliquant vers d'anciennes répliques, car cela peut interrompre la réplication. Si vous avez deux centres de données, un actif et un pour la reprise après sinistre, vous préférerez peut-être choisir des candidats maîtres uniquement dans le centre de données actif, pour garder le maître à proximité des hôtes d'application. Ce ne sont que des exemples de situations où vous pourriez avoir besoin d'une intervention manuelle pendant le processus de basculement. Heureusement, de nombreux outils de basculement ont la possibilité de prendre le contrôle du processus en utilisant des listes blanches et des listes noires. Dans cet article de blog, nous aimerions vous montrer quelques exemples de la manière dont vous pouvez influencer l'algorithme de ClusterControl pour sélectionner les candidats maîtres.
Configuration de la liste blanche et de la liste noire
ClusterControl vous donne la possibilité de définir à la fois une liste blanche et une liste noire de répliques. Une liste blanche est une liste de répliques destinées à devenir des candidats maîtres. Si aucun d'entre eux n'est disponible (soit parce qu'ils sont en panne, soit parce qu'il y a des transactions errantes, soit parce qu'il existe d'autres obstacles qui empêchent l'un d'entre eux d'être promu), le basculement ne sera pas effectué. De cette façon, vous pouvez définir quels hôtes sont disponibles pour devenir un candidat maître. Les listes noires, en revanche, définissent les répliques qui ne conviennent pas pour devenir un candidat maître.
Ces deux listes peuvent être définies dans le fichier de configuration cmon pour un cluster donné. Par exemple, si votre cluster a l'identifiant "1", vous souhaitez modifier "/etc/cmon.d/cmon_1.cnf". Pour la liste blanche, vous utiliserez la variable « replication_failover_whitelist », pour la liste noire, ce sera une « replication_failover_blacklist ». Les deux acceptent une liste séparée par des virgules de "host:port".
Considérons la configuration de réplication suivante. Nous avons un maître actif (10.0.0.141) qui a deux réplicas (10.0.0.142 et 10.0.0.143), tous deux agissent comme des maîtres intermédiaires et ont chacun un réplica (10.0.0.144 et 10.0.0.147). Nous avons également un maître de secours dans un centre de données séparé (10.0.0.145) qui a une réplique (10.0.0.146). Ces hôtes sont destinés à être utilisés en cas de sinistre. Les répliques 10.0.0.146 et 10.0.0.147 agissent en tant qu'hôtes de secours. Voir la capture d'écran ci-dessous.
Étant donné que le deuxième centre de données est uniquement destiné à la reprise après sinistre, nous ne voulons pas qu'aucun de ces hôtes soit promu en tant que maître. Dans le pire des cas, nous prendrons des mesures manuelles. L'infrastructure du deuxième centre de données n'est pas adaptée à la taille du centre de données de production (il y a trois répliques de moins dans le centre de données DR), donc des actions manuelles sont de toute façon nécessaires avant de pouvoir promouvoir un hôte dans le centre de données DR. Nous ne souhaitons pas non plus qu'une réplique de sauvegarde (10.0.0.147) soit promue. Nous ne voulons pas non plus qu'une troisième réplique de la chaîne soit choisie en tant que maître (même si cela pourrait être fait avec GTID).
Configuration de la liste blanche
Nous pouvons configurer une liste blanche ou une liste noire pour nous assurer que le basculement sera géré à notre goût. Dans cette configuration particulière, l'utilisation de la liste blanche peut être plus appropriée - nous définirons quels hôtes peuvent être utilisés pour le basculement et si quelqu'un ajoute un nouvel hôte à la configuration, il ne sera pas pris en considération comme candidat maître jusqu'à ce que quelqu'un décide manuellement qu'il est ok pour l'utiliser et l'ajouter à la liste blanche. Si nous utilisions une liste noire, l'ajout d'un nouveau réplica quelque part dans la chaîne pourrait signifier que ce réplica pourrait théoriquement être automatiquement utilisé pour le basculement, à moins que quelqu'un ne dise explicitement qu'il ne peut pas être utilisé. Restons prudents et définissons une liste blanche dans notre fichier de configuration de cluster (dans ce cas, il s'agit de /etc/cmon.d/cmon_1.cnf car nous n'avons qu'un seul cluster) :
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Nous devons nous assurer que le processus cmon a été redémarré pour appliquer les modifications :
service cmon restartSupposons que notre maître s'est écrasé et ne peut pas être atteint par ClusterControl. Une tâche de basculement sera lancée :
La topologie ressemblera à ci-dessous :
Comme vous pouvez le voir, l'ancien maître est désactivé et ClusterControl ne tentera pas de le récupérer automatiquement. Il appartient à l'utilisateur de vérifier ce qui s'est passé, de copier les données éventuellement non répliquées sur le candidat maître et de reconstruire l'ancien maître :
Ensuite, il suffit de quelques changements de topologie et nous pouvons ramener la topologie à l'état d'origine, en remplaçant simplement 10.0.0.141 par 10.0.0.142 :
Configuration de la liste noire
Nous allons maintenant voir comment fonctionne la liste noire. Nous avons mentionné que, dans notre exemple, ce n'est peut-être pas la meilleure option, mais nous allons l'essayer à titre d'illustration. Nous mettrons sur liste noire tous les hôtes sauf 10.0.0.141, 10.0.0.142 et 10.0.0.143 car ce sont les hôtes que nous voulons voir comme candidats maîtres.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Nous allons également redémarrer le processus cmon pour appliquer les modifications de configuration :
service cmon restartLe processus de basculement est similaire. Encore une fois, une fois le plantage du maître détecté, ClusterControl lancera une tâche de basculement.
Quand une réplique peut ne pas être un bon candidat Master
Dans cette courte section, nous aimerions discuter plus en détail de certains des cas dans lesquels vous ne souhaitez peut-être pas promouvoir une réplique donnée pour devenir un nouveau maître. J'espère que cela vous donnera quelques idées sur les cas où vous devrez peut-être envisager d'induire un contrôle plus manuel du processus de basculement.
Différentes versions de MySQL
Tout d'abord, si votre réplica utilise une version de MySQL différente de celle du maître, ce n'est pas une bonne idée de la promouvoir. De manière générale, une version plus récente est toujours interdite car la réplication de la nouvelle vers l'ancienne version de MySQL n'est pas prise en charge et peut ne pas fonctionner correctement. Ceci concerne principalement les versions majeures (par exemple, 8.0 répliquant vers 5.7) mais la bonne pratique consiste à éviter complètement cette configuration, même si nous parlons de petites différences de version (5.7.x + 1 -> 5.7.x). La réplication d'une version inférieure à une version supérieure / plus récente est prise en charge car elle est indispensable pour le processus de mise à niveau, mais vous préféreriez néanmoins éviter cela (par exemple, si votre maître est sur 5.7.x + 1, vous préférez ne pas le remplacer avec une réplique sur 5.7.x).
Différents rôles
Vous pouvez attribuer différents rôles à vos répliques. Vous pouvez choisir l'un d'entre eux pour qu'il soit disponible pour les développeurs afin de tester leurs requêtes sur un jeu de données de production. Vous pouvez utiliser l'un d'entre eux pour la charge de travail OLAP. Vous pouvez utiliser l'un d'eux pour les sauvegardes. Quoi qu'il en soit, vous ne voudriez généralement pas promouvoir une telle réplique en maître. Toutes ces charges de travail supplémentaires non standard peuvent entraîner des problèmes de performances en raison de la surcharge supplémentaire. Un bon choix pour un candidat maître est une réplique qui gère une charge "normale", plus ou moins le même type de charge que le maître actuel. Vous pouvez alors être certain qu'il gérera la charge principale après le basculement s'il l'a gérée avant cela.
Différentes spécifications matérielles
Nous avons mentionné différents rôles pour les répliques. Il n'est pas rare de voir également différentes spécifications matérielles, en particulier en conjonction avec différents rôles. Par exemple, un esclave de sauvegarde n'a probablement pas besoin d'être aussi puissant qu'une réplique standard. Les développeurs peuvent également tester leurs requêtes sur une base de données plus lente que la production (principalement parce que vous ne vous attendriez pas au même niveau de simultanéité sur la base de données de développement et de production) et, par exemple, le nombre de cœurs de processeur peut être réduit. Les configurations de reprise après sinistre peuvent également être réduites en taille si leur rôle principal est de suivre la réplication et il est prévu que la configuration DR devra être mise à l'échelle (à la fois verticalement, en dimensionnant l'instance et horizontalement, en ajoutant plus de répliques) avant que le trafic puisse y être redirigé.
Répliques retardées
Certaines des répliques peuvent être retardées - c'est un très bon moyen de réduire le temps de récupération si des données ont été perdues, mais cela en fait de très mauvais candidats maîtres. Si une réplique est retardée de 30 minutes, soit vous perdrez ces 30 minutes de transactions, soit vous devrez attendre (probablement pas 30 minutes car, très probablement, la réplique peut rattraper son retard plus rapidement) pour que la réplique applique toutes les transactions retardées. ClusterControl vous permet de choisir si vous voulez attendre ou si vous voulez basculer immédiatement, mais cela fonctionnerait bien pour un très petit décalage - des dizaines de secondes au plus. Si le basculement est censé prendre quelques minutes, il est tout simplement inutile d'utiliser une telle réplique et c'est donc une bonne idée de la mettre sur liste noire.
Centre de données différent
Nous avons mentionné les configurations DR réduites, mais même si votre deuxième centre de données est adapté à la taille de la production, il peut toujours être judicieux de conserver les basculements dans un seul DC. Pour commencer, vos hôtes d'application actifs peuvent être situés dans le centre de données principal. Ainsi, le déplacement du maître vers un DC de secours augmenterait considérablement la latence pour les requêtes d'écriture. En outre, en cas de division du réseau, vous souhaiterez peut-être gérer manuellement cette situation. MySQL n'a pas de mécanisme de quorum intégré, il est donc assez difficile de gérer correctement (de manière automatique) la perte de réseau entre deux centres de données.
