Dans nos blogs précédents, nous avons expliqué pourquoi vous avez besoin d'un basculement de base de données et expliqué le fonctionnement d'un mécanisme de basculement. Je partage ceci au cas où vous auriez des questions sur les raisons pour lesquelles vous devriez configurer un mécanisme de basculement pour votre base de données MySQL. Si tel est le cas, veuillez lire nos articles de blog précédents.
Comment configurer le basculement automatique
L'avantage d'utiliser MySQL ou MariaDB pour gérer automatiquement votre basculement est qu'il existe des outils disponibles que vous pouvez utiliser et implémenter dans votre environnement. Des solutions open source aux solutions de niveau entreprise. La plupart des outils ne sont pas seulement capables de basculement, il existe d'autres fonctionnalités telles que le basculement, la surveillance et les fonctionnalités avancées qui peuvent offrir plus de capacités de gestion pour votre cluster de base de données MySQL. Ci-dessous, nous passerons en revue les plus courants que vous pouvez utiliser.
Utilisation de MHA (haute disponibilité principale)
Nous avons abordé ce sujet avec MHA avec ses problèmes les plus courants et comment les résoudre. Nous avons également comparé MHA avec MRM ou avec MaxScale.
Configurer avec MHA pour une haute disponibilité n'est peut-être pas facile, mais il est efficace et flexible car il existe des paramètres réglables que vous pouvez définir pour personnaliser votre basculement. MHA a été testé et utilisé. Mais à mesure que la technologie progresse, MHA a pris du retard car il ne prend pas en charge GTID pour MariaDB et il n'a pas poussé de mises à jour au cours des 2 ou 3 dernières années.
En exécutant le script masterha_manager,
masterha_manager --conf=/etc/app1.cnfOù un exemple /etc/app1.cnf doit ressembler à ceci,
[server default]
user=cmon
password=pass
ssh_user=root
# working directory on the manager
manager_workdir=/var/log/masterha/app1
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app1
[server1]
hostname=node1
candidate_master=1
[server2]
hostname=node2
candidate_master=1
[server3]
hostname=node3
no_master=1Des paramètres tels que no_master et candidate_master doivent être cruciaux lorsque vous définissez la liste blanche des nœuds souhaités comme étant votre maître cible et les nœuds que vous ne voulez pas être un maître.
Une fois défini, vous êtes prêt à avoir un basculement pour votre base de données MySQL en cas de panne sur le primaire ou le maître. Le script masterha_manager gère le basculement (automatique ou manuel), prend des décisions sur le moment et l'endroit du basculement et gère la récupération de l'esclave lors de la promotion du maître candidat pour l'application des journaux de relais différentiels. Si la base de données maître meurt, MHA Manager se coordonne avec l'agent de nœud MHA car il applique les journaux de relais différentiels aux esclaves qui n'ont pas les derniers événements binlog du maître.
Découvrez ce que fait l'agent de nœud MHA et ses scripts impliqués. Fondamentalement, c'est le script que le gestionnaire MHA appellera lors du basculement. Il attendra son mandat de MHA Manager pendant qu'il recherche le dernier esclave contenant les événements binlog et copie les événements manquants de l'esclave à l'aide de scp et les applique à lui-même. Comme mentionné, il applique les journaux de relais, purge les journaux de relais ou enregistre les journaux binaires.
Si vous souhaitez en savoir plus sur les paramètres réglables et comment personnaliser votre gestion du basculement, consultez la page wiki des paramètres pour MHA.
Utiliser Orchestrator
Orchestrator est un outil de gestion de la haute disponibilité et de la réplication MySQL et MariaDB. Il est publié par Shlomi Noach sous les termes de la licence Apache, version 2.0. Il s'agit d'un logiciel open source qui gère le basculement automatique, mais il y a des tonnes de choses que vous pouvez personnaliser ou faire pour gérer votre base de données MySQL/MariaDB en dehors de la récupération ou du basculement automatique.
L'installation d'Orchestrator peut être simple ou directe. Une fois que vous avez téléchargé les packages spécifiques requis pour votre environnement cible, vous êtes alors prêt à enregistrer votre cluster et vos nœuds à surveiller par Orchestrator. Il fournit une interface utilisateur pour laquelle il est très facile à gérer, mais qui contient de nombreux paramètres réglables ou un ensemble de commandes que vous pouvez utiliser pour atteindre votre gestion du basculement.
Considérons que vous avez enfin configuré et que l'enregistrement du cluster en ajoutant notre nœud principal ou maître peut être effectué par la commande ci-dessous,
$ orchestrator -c discover -i pupnode21:3306
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: pupnode21
2021-01-07 12:32:31 DEBUG Cache hostname resolve pupnode21 as pupnode21
2021-01-07 12:32:31 DEBUG Connected to orchestrator backend: orchestrator:[email protected](127.0.0.1:3306)/orchestrator?timeout=1s
2021-01-07 12:32:31 DEBUG Orchestrator pool SetMaxOpenConns: 128
2021-01-07 12:32:31 DEBUG Initializing orchestrator
2021-01-07 12:32:31 INFO Connecting to backend 127.0.0.1:3306: maxConnections: 128, maxIdleConns: 32
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.222
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.222 as 192.168.40.222
2021-01-07 12:32:31 DEBUG Hostname unresolved yet: 192.168.40.223
2021-01-07 12:32:31 DEBUG Cache hostname resolve 192.168.40.223 as 192.168.40.223
pupnode21:3306Maintenant, nous avons ajouté notre cluster.
Si un nœud principal tombe en panne (panne matérielle ou panne), Orchestrator détecter et trouver le nœud le plus avancé à promouvoir en tant que nœud principal ou maître.
Maintenant, nous avons deux nœuds restants dans le cluster alors que le principal est en panne .
$ orchestrator-client -c topology -i pupnode21:3306
pupnode21:3306 [unknown,invalid,10.3.27-MariaDB-log,rw,ROW,>>,downtimed]
$ orchestrator-client -c topology -i pupnode22:3306
pupnode22:3306 [0s,ok,10.3.27-MariaDB-log,rw,ROW,>>]
+ pupnode23:3306 [0s,ok,10.3.27-MariaDB-log,ro,ROW,>>,GTID]Utiliser MaxScale
MariaDB MaxScale a été pris en charge en tant qu'équilibreur de charge de base de données. Au fil des ans, MaxScale a grandi et mûri, étendu avec plusieurs fonctionnalités riches et qui inclut le basculement automatique. Depuis la sortie de MariaDB MaxScale 2.2, il introduit plusieurs nouvelles fonctionnalités, notamment la gestion du basculement du cluster de réplication. Vous pouvez lire notre blog précédent concernant le mécanisme de basculement MaxScale.
L'utilisation de MaxScale est sous BSL bien que le logiciel soit disponible gratuitement mais vous oblige à au moins acheter un service avec MariaDB. Cela peut ne pas convenir, mais si vous avez acquis les services d'entreprise MariaDB, cela peut être un grand avantage si vous avez besoin de la gestion du basculement et de ses autres fonctionnalités.
L'installation de MaxScale est facile mais la mise en place de la configuration requise et la définition de ses paramètres ne l'est pas, et cela nécessite que vous compreniez le logiciel. Vous pouvez vous référer à leur guide de configuration.
Pour un déploiement rapide et rapide, vous pouvez utiliser ClusterControl pour installer MaxScale pour vous dans votre environnement MySQL/MariaDB existant.
Une fois installé, la configuration de votre base de données Moodle peut être effectuée en pointant votre hôte vers l'adresse IP ou le nom d'hôte MaxScale et le port de lecture-écriture. Par exemple,
Pour quel port 4008 est votre lecture-écriture pour votre service d'écoute. Par exemple, voici la configuration suivante du service et de l'écouteur pour mon MaxScale.
$ cat maxscale.cnf.d/rw-listener.cnf
[rw-listener]
type=listener
protocol=mariadbclient
service=rw-service
address=0.0.0.0
port=4008
authenticator=MySQLAuth
$ cat maxscale.cnf.d/rw-service.cnf
[rw-service]
type=service
servers=DB_123,DB_122,DB_124
router=readwritesplit
user=maxscale_adm
password=42BBD2A4DC1BF9BE05C41A71DEEBDB70
max_slave_connections=100%
max_sescmd_history=15000000
causal_reads=true
causal_reads_timeout=10
transaction_replay=true
transaction_replay_max_size=32Mi
delayed_retry=true
master_reconnection=true
max_connections=0
connection_timeout=0
use_sql_variables_in=master
master_accept_reads=true
disable_sescmd_history=falseDans la configuration de votre moniteur, vous ne devez pas oublier d'activer le basculement automatique ou également d'activer la jonction automatique si vous souhaitez que le maître précédent ne se rejoigne pas automatiquement lors de la remise en ligne. Ça se passe comme ça,
$ egrep -r 'auto|^\[' maxscale.cnf.d/replication_monitor.cnf
[replication_monitor]
auto_failover=true
auto_rejoin=1Notez que les variables que j'ai indiquées ne sont pas destinées à une utilisation en production, mais uniquement à cet article de blog et à des fins de test. La bonne chose avec MaxScale, une fois que le primaire ou le maître tombe en panne, MaxScale est assez intelligent pour promouvoir le candidat idéal ou le meilleur candidat pour assumer le rôle du maître. Par conséquent, pas besoin de changer votre IP et votre port car nous avons utilisé l'hôte/l'IP de notre nœud MaxScale et son port comme point de terminaison une fois que le maître tombe en panne. Par exemple,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘Le nœud DB_123 qui pointe vers 192.168.40.221 est le maître actuel. La terminaison du nœud DB_123 déclenchera MaxScale pour effectuer un basculement et il ressemblera à ceci,
[192.168.40.223:6603] MaxScale> list servers
┌────────┬────────────────┬──────┬─────────────┬─────────────────┬──────────────────────────┐
│ Server │ Address │ Port │ Connections │ State │ GTID │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_124 │ 192.168.40.223 │ 3306 │ 0 │ Slave, Running │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_123 │ 192.168.40.221 │ 3306 │ 0 │ Down │ 3-2003-876,5-2001-219541 │
├────────┼────────────────┼──────┼─────────────┼─────────────────┼──────────────────────────┤
│ DB_122 │ 192.168.40.222 │ 3306 │ 0 │ Master, Running │ 3-2003-876,5-2001-219541 │
└────────┴────────────────┴──────┴─────────────┴─────────────────┴──────────────────────────┘Bien que notre base de données Moodle soit toujours opérationnelle, car notre MaxScale pointe vers le dernier maître qui a été promu.
$ mysql -hmaxscale.local.domain -umoodleuser -pmoodlepassword -P4008
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.3.27-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> select @@hostname;
+------------+
| @@hostname |
+------------+
| 192.168.40.222 |
+------------+
1 row in set (0.001 sec)Utiliser ClusterControl
ClusterControl peut être téléchargé gratuitement et propose des licences pour Community, Advance et Enterprise. Le basculement automatique n'est disponible que sur Advance et Enterprise. Le basculement automatique est couvert par notre fonctionnalité de récupération automatique qui tente de récupérer un cluster défaillant ou un nœud défaillant. Si vous souhaitez plus de détails sur la façon d'effectuer cette opération, consultez notre article précédent Comment ClusterControl effectue la récupération et le basculement automatiques de la base de données. Il offre des paramètres réglables qui sont très pratiques et faciles à utiliser. Veuillez également lire notre article précédent sur Comment automatiser le basculement de base de données avec ClusterControl.
La gestion de votre basculement automatique pour votre base de données Moodle doit au moins nécessiter une adresse IP virtuelle (VIP) en tant que point de terminaison pour votre client d'application Moodle interfaçant votre backend de base de données. Pour ce faire, vous pouvez déployer Keepalived avec HAProxy (ou ProxySQL - selon votre choix d'équilibreur de charge) en plus. Dans ce cas, votre point de terminaison de base de données Moodle doit pointer vers l'adresse IP virtuelle, qui est essentiellement attribuée par Keepalived une fois que vous l'avez déployée, comme nous vous l'avons montré précédemment lors de la configuration de MaxScale. Vous pouvez également consulter ce blog pour savoir comment procéder.
Comme mentionné ci-dessus, des paramètres réglables sont disponibles que vous pouvez simplement définir via votre /etc/cmon.d/cmon_
- replication_check_binlog_filtration_bf_failover
- replication_check_external_bf_failover
- replication_failed_reslave_failover_script
- replication_failover_blacklist
- replication_failover_events
- replication_failover_wait_to_apply_timeout
- replication_failover_whitelist
- replication_onfail_failover_script
- Replication_post_failover_script
- replication_post_unsuccessful_failover_script
- replication_pre_failover_script
- replication_skip_apply_missing_txs
- replication_stop_on_error
ClusterControl est très flexible lors de la gestion du basculement, vous pouvez donc effectuer certaines tâches avant ou après le basculement.
Conclusion
Il existe d'autres excellents choix lors de la configuration et de la gestion automatique de votre basculement pour votre base de données MySQL pour Moodle. Cela dépend de votre budget et de ce pour quoi vous devrez probablement dépenser de l'argent. L'utilisation de logiciels open source nécessite une expertise et nécessite plusieurs tests pour se familiariser car il n'y a pas de support que vous pouvez exécuter lorsque vous avez besoin d'aide autre que la communauté. Avec les solutions d'entreprise, cela a un prix mais vous offre un soutien et une facilité car le travail fastidieux peut être diminué. Notez que si le basculement est utilisé par erreur, cela peut endommager votre base de données s'il n'est pas correctement géré et géré. Concentrez-vous sur ce qui est le plus important et sur la façon dont vous êtes capable des solutions que vous utilisez pour gérer le basculement de votre base de données Moodle.
