1. Home
  2. Knowledge Base
  3. Articles (EN/ES/FR)
  4. Rétablissement d’un nœud brisé de Pandora FMS HA

Rétablissement d’un nœud brisé de Pandora FMS HA

Lorsque nous avons un environnement en HA, il peut arriver que le nœud ou le réseau tombe et qu’une désynchronisation se produise, entrant dans le nœud secondaire slave pour fonctionner comme primaire master et le remplacer. Ce problème est connu sous le nom de “nœud brisé” et pour le résoudre, nous devrions suivre le processus suivant :

En résumé, ce que nous allons faire, c’est déplacer une sauvegarde de la base de données principale vers l’esclave une fois que nous aurons réussi à la récupérer et à la resynchroniser par le biais de percona, pacemaker et corosync. En supposant le nom des nœuds 1 et 2 et en étant le nœud 2 celui qui est tombé :

  • Nous mettons le nœud 2 en veille au moyen des commandes suivantes :
node2# pcs node standby node2
  • Nous faisons une sauvegarde du répertoire de données Percona du nœud 2 au cas où, bien que nous ne l’utilisions pas :
node2# systemctl stop mysqld
node2# [ -e /var/lib/mysql.bak ] && rm -rf /var/lib/mysql.bak
node2# mv /var/lib/mysql /var/lib/mysql.bak
  • Nous faisons une sauvegarde de la base de données du nœud maître (nœud1 dans cet exemple) et nous conservons le nom du nœud maître, ainsi que le nom et la position du fichier journal maître dans le cluster (dans cet exemple, nœud1, mysql-bin.000001 et 785) :
node1# [ -e /root/pandoradb.bak ] && rm -rf /root/pandoradb.bak
node1# innobackupex --no-timestamp /root/pandoradb.bak/
node1# innobackupex --apply-log /root/pandoradb.bak/
node1# binlog_info=$(cat /root/pandoradb.bak/xtrabackup_binlog_info)
node1# crm_attribute --type crm_config --name pandoradb_REPL_INFO -s mysql_replication -v "node1|$(echo $binlog_info | awk '{print $1}')|$(echo $binlog_info | awk '{print $2}')"
  • Nous chargeons la base de données du nœud 1 au nœud 2 :
node1# rsync -avpP -e ssh /root/pandoradb.bak/ node2:/var/lib/mysql/
node2# chown -R mysql:mysql /var/lib/mysql
node2# chcon -R system_u:object_r:mysqld_db_t:s0 /var/lib/mysql
  • Nous désactivons le mode de veille du nœud 2 et nettoyons les erreurs :
node2# pcs node unstandby node2
node2# pcs resource cleanup --node node2
  • Nous avons vérifié l’état de la réplication de la base de données :
node2# mysql -uroot -ppandora
mysql> SHOW SLAVE STATUS

S’assurer que Slave_IO_Running et Slave_SQL_Running affichent Yes.

Was this article helpful?

Related Articles

Need Support?

Can't find the answer you're looking for?
Contact Support