![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Hello \u00e0 toutes \/ tous,<\/p>\n
Restaurer tout un cluster actif-actif comme Galera cluster<\/a> \u00e0 un point dans le temps peut \u00eatre une op\u00e9ration fastidieuse, et sous la pression on peut rapidement s’emm\u00ealer les pinceaux. C’est donc une bonne id\u00e9e de pouvoir pratiquer cet exercice au calme, en utilisant un bac \u00e0 sable, via des conteneurs par exemple. Si vous souhaitez refaire l’exercice, vous pourrez retrouver la base sakila utilis\u00e9e dans cet article ici<\/a>.<\/p>\n On se propose aujourd’hui de pr\u00e9senter une m\u00e9thode de restauration d’objet dans un cluster MariaDB Galera \u00e0 3 noeuds:<\/p>\n Un arbitre sera ajout\u00e9 mais ne sera activ\u00e9 que temporairement afin de permettre de maintenir un nombre de votants impair lors du retrait d’un des noeuds. <\/p>\n Le sc\u00e9nario<\/strong>: un utilisateur supprime les donn\u00e9es de la table sakila.rental<\/em>. On souhaite restaurer cette table uniquement. Noter que l’on pourrait restaurer toute la base pour limiter les risques de violation de contraintes lors de la restauration, mais pour simplifier partons du principe que la table vid\u00e9e par erreur est isol\u00e9e du reste du mod\u00e8le de donn\u00e9es. La m\u00e9thode pour restaurer toute la base serait similaire.<\/p>\n 1) Activer l\u2019arbitre et stopper le n\u0153ud 3, afin que l\u2019\u00e9quilibre des votes soit maintenu. Evidemment pour pouvoir restaurer les modifications interm\u00e9diaires, il faut que les logs binaires soient activ\u00e9s. Il y a une petite subtilit\u00e9 sur Galera, comme les modifications peuvent \u00eatre faites en local mais aussi venir de n’importe quel autre noeud du cluster (on rappelle que Galera est un cluster actif\/actif en lecture et en \u00e9criture), il faut pouvoir enregistrer tous les ordres de modification quelle que soit leur provenance. Pour cela on activera en plus de log-bin et log-bin-index, le param\u00e8tre log-slave-updates=1<\/a>. <\/p>\n L’arbitre <\/a>est un composant sp\u00e9cial dans un cluster Galera (on retrouve le m\u00eame principe dans d’autres clusters comme les Replica Sets MongoDB<\/a>, etc…) c’est un noeud qui ne peut pas h\u00e9berger de donn\u00e9es mais peut participer au vote du quorum. En g\u00e9n\u00e9ral comme les clusters n\u00e9cessitent un nombre impair de votants pour limiter les risques de split-brain<\/a>, on l’utilise lorsque l’on ne peut pas d\u00e9ployer plus de 2 noeuds de donn\u00e9es par faute de moyens , volum\u00e9trie, etc… <\/p>\n Il ne contient pas la distribution MariaDB + Galera mais seulement un binaire garbd <\/em>installable via un package sur la plupart des distributions : <\/p>\n Son fichier de configuration est minimaliste, il contient simplement le nom du cluster Galera et la liste des noeuds:<\/p>\n Il peut se d\u00e9marrer via un service systemd qu’il faudra cr\u00e9er \u00e0 la main, mais dans notre cas on ne l’activera qu’\u00e0 la demande donc on ne lancera le processus garbd qu’\u00e0 la main, en mode daemon, de la fa\u00e7on suivante:<\/p>\n On pourrait choisir d’utiliser une burn instance<\/em>, c’est \u00e0 dire une instance qu’on ne d\u00e9ploierait que pour restaurer, r\u00e9exporter, puis qui serait supprim\u00e9e ensuite (par exemple sous forme d’un conteneur Docker ou LXD) . Dans notre cas, nous allons sacrifier un noeud du cluster, et nous allons lui substituer l’arbitre pour maintenir l’\u00e9quilibre des votants. <\/p>\n Donc en premier lieu, nous allons d\u00e9marrer l’arbitre comme vu plus haut, et stopper le noeud galera3 qui sera notre noeud de restauration:<\/p>\n Sur galerarb:<\/p>\n et v\u00e9rifier qu’il est bien vu comme int\u00e9gr\u00e9 au cluster dans le fichier de log d’un autre noeud:<\/p>\n Sur galera3 : <\/p>\n M\u00eame chose, toujours valider dans le log d’un autre noeud que le cluster voit bien les modifications \u00e0 chaque fois:<\/p>\n Je conseille de d\u00e9dier une fen\u00eatre XTERM \u00e0 un tail -f du fichier de log sur l’un des 2 autres noeuds du cluster, dans notre cas galera1 ou galera2. <\/p>\n Nous allons ensuite sortir manuellement galera3 du cluster en commentant sa configuration wsrep:<\/p>\n Il faudra penser \u00e0 d\u00e9sactiver des t\u00e2ches automatiques, en crontab par exemple, notamment des t\u00e2ches de MCO comme des backups de logs binaires qui pourraient perturber notre op\u00e9ration de restauration. <\/p>\n A partir de l\u00e0, notre service est toujours accessible, partiellement car une des tables est vide. En fonction de la criticit\u00e9 de la table, cela peut avoir des cons\u00e9quences importantes sur la disponibilit\u00e9 des applications, donc il ne faut pas tra\u00eener. <\/p>\n Tout d’abord, notre cha\u00eene de backup commence par un backup complet mariabackup, et est compl\u00e9t\u00e9 r\u00e9guli\u00e8rement par des sauvegardes de journaux binaires. Voyons ce que nous avons en local:<\/p>\n Nous avons un backup complet et deux backups de journaux en ligne. Il faut commencer par extraire le backup complet qui a \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9 sous forme de stream et v\u00e9rifier \u00e0 partir de quel binlog et quelle position commence la cha\u00eene de backup. Nous allons cr\u00e9er un sous r\u00e9pertoire ~RESTORE dans lequel nous pourrons reverser tous les fichiers n\u00e9cessaires \u00e0 la restauration. <\/p>\n Le fichier xtrabackup_binlog_info contient les informations de binlog et position recherch\u00e9es (l’\u00e9quivalent du –master-data de mysqldump)<\/p>\n OK donc on sait qu’il faudra restaurer au moins \u00e0 partir du log binaire mariadb-bin.000049, mais dans notre cas il n’est plus en ligne :<\/p>\n Il faudra donc le restaurer \u00e0 partir d’une sauvegarde :<\/p>\n Nous avons le backup complet et le d\u00e9but de la cha\u00eene de sauvegarde, maintenant il faut trouver le point d’arr\u00eat de la restauration, c’est \u00e0 dire la transaction qui pr\u00e9c\u00e8de le delete sur sakila.rental<\/em>. C’est la partie un peu fastidieuse du processus, o\u00f9 il faut partir \u00e0 la p\u00eache au bon fichier et \u00e0 la bonne position:<\/p>\n On voit ici que les deletes concernent des tables diff\u00e9rentes de la table rental<\/em>, ce sont des tables d\u00e9riv\u00e9es mais pas la table d’origine, il faut continuer les recherches dans le second backup:<\/p>\n On a donc trouv\u00e9, le delete se trouve dans le binlog mariadb-bin.000055, reste \u00e0 trouver la position:<\/p>\n Notre transaction est \u00e0 la position 389 dans le fichier mariadb-bin.000055. <\/p>\n En conclusion, notre s\u00e9quence de restauration sera la suivante:<\/strong> Pour restaurer le backup complet mariabackup, il faut couper le noeud 3 et vider son datadir:<\/p>\n Puis pr\u00e9parer le backup et restaurer:<\/p>\n Ne pas oublier de bien r\u00e9attribuer les droits en fin de s\u00e9quence, avant de red\u00e9marrer le service:<\/p>\n Ensuite nous pouvons restaurer notre s\u00e9quence de logs binaires:<\/p>\n Et v\u00e9rifier que les donn\u00e9es de la table rental <\/em>ont bien \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9es, puis les r\u00e9exporter:<\/p>\n N’importe quel noeud en Primary \/ Synced fera l’affaire. La r\u00e9execution du fichier SQL sera ensuite r\u00e9pliqu\u00e9e en synchrone sur l’autre noeud. <\/p>\n V\u00e9rifier que les donn\u00e9es sont bien pr\u00e9sentes sur tous les noeuds galera1, galera2, avant de r\u00e9int\u00e9grer galera3. <\/p>\n Il suffit simplement de d\u00e9commenter les param\u00e8tres wsrep dans le fichier de configuration de MariaDB sur galera3, et red\u00e9marrer le service :<\/p>\n Un SST sera d\u00e9clench\u00e9 pour remettre le noeud galera3 \u00e0 jour depuis un donor <\/em>disponible (ici galera1):<\/p>\n Et enfin nous n’avons plus besoin de l’arbitre, nous sommes revenus en nominal:<\/p>\n Penser \u00e0 bien r\u00e9activer les t\u00e2ches comment\u00e9es sur galera3 pendant la phase de recherche et restauration des donn\u00e9es. Et le tour est jou\u00e9 !<\/p>\n A+ pour d’autre articles ! Hello \u00e0 toutes \/ tous, Restaurer tout un cluster actif-actif comme Galera cluster \u00e0 un point dans le temps peut \u00eatre une op\u00e9ration fastidieuse, et sous la pression on peut rapidement s’emm\u00ealer les pinceaux. C’est donc une bonne id\u00e9e de… Continuer la lecture ![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2022\/02\/galera-1024x255.png\")
<\/p>\nLe principe : <\/h2>\n
\n2) Red\u00e9marrer le n\u0153ud 3 en standalone sans configuration cluster.
\n3) Rechercher dans les journaux binaires soit en ligne soit sauvegard\u00e9s la position correspondant \u00e0 la transaction de suppression des donn\u00e9es de rental<\/em>.
\n4) Restaurer la sauvegarde mariabackup compl\u00e8te puis les journaux dans l\u2019ordre jusqu\u2019\u00e0 cette position (non inclue).
\n5) Apr\u00e8s v\u00e9rification, r\u00e9exporter simplement la table rental<\/em>.
\n6) La r\u00e9importer dans un des deux n\u0153uds actifs, les modifications seront imm\u00e9diatement synchronis\u00e9es avec le n\u0153ud restant.
\n7) R\u00e9int\u00e9grer le n\u0153ud 3 dans le cluster, ce qui red\u00e9clenchera une resynchronisation totale via SST<\/a>.
\n8) Couper l\u2019arbitre qui ne nous sert plus. <\/p>\nPr\u00e9requis : les logs binaires<\/h2>\n
\r\nroot@galera3:~# vi \/etc\/mysql\/my.cnf\r\n(\u2026)\r\nlog_bin\t\t\t= \/var\/log\/mysql\/mariadb-bin\r\nlog_bin_index\t\t= \/var\/log\/mysql\/mariadb-bin.index\r\nlog_slave_updates\t= 1\r\nexpire_logs_days\t= 10\r\n<\/pre>\n
Le r\u00f4le de l’arbitre :<\/h2>\n
\r\nroot@galerarb:~# apt-get install galera-arbitrator-3\r\n<\/pre>\n
\r\nroot@galerarb:~# vi garbd.conf \r\naddress = "gcomm:\/\/10.186.157.38,10.186.157.242,10.186.157.196"\r\ngroup = "TestCluster"\r\n<\/pre>\n
\r\nroot@galerarb:~# \/usr\/bin\/garbd --cfg \/root\/garbd.conf \\ \r\n--daemon --log \/var\/log\/garbd.log\r\n<\/pre>\n
Etape 1 : choix d’un noeud de restauration et \u00e9vinction manuelle du cluster.<\/h2>\n
\r\nroot@galerarb:~# \/usr\/bin\/garbd --cfg \/root\/garbd.conf \\ \r\n--daemon --log \/var\/log\/garbd.log\r\n<\/pre>\n
\r\n(...)\r\n2022-02-16 15:46:54 0 [Note] WSREP: Member 3.0 (garb) synced with group.\r\n(...)\r\n<\/pre>\n
\r\nroot@galera3:~# systemctl stop mariadb.service\r\n<\/pre>\n
\r\n2022-02-17 10:34:27 0 [Note] WSREP: cleaning up b0ccc293 (tcp:\/\/10.186.157.196:4567)\r\n<\/pre>\n
\r\nroot@galera3:~# vi \/etc\/mysql\/mariadb.conf.d\/60-galera.cnf \r\n(...)\r\n# Cluster Configuration\r\n# wsrep_provider = \/usr\/lib\/galera\/libgalera_smm.so\r\n# wsrep_cluster_address = gcomm:\/\/10.186.157.38,10.186.157.242,10.186.157.196\r\n# wsrep_cluster_name = TestCluster\r\n# wsrep_on = ON\r\n\r\nroot@galera3:~# systemctl start mariadb.service\r\n<\/pre>\n
D\u00e9terminer la cha\u00eene compl\u00e8te de fichiers \u00e0 restaurer<\/h2>\n
\r\nroot@galera3:~\/SCRIPTS# ls -lrat \/mariabackup\r\n-rw-r--r-- 1 root root 3666109 Feb 17 10:05 MARIABACKUP__20220217_100457.xb.gz\r\ndrwxr-xr-x 2 mysql mysql 4096 Feb 17 10:24 .\r\n-rw-r--r-- 1 root root 44573785 Feb 17 10:24 BINLOGS_20220217_102428.tar.gz\r\n-rw-r--r-- 1 root root 203021 Feb 17 11:07 BINLOGS_20220217_110741.tar.gz\r\n<\/pre>\n
\r\nroot@galera3:\/mariabackup# mkdir \/mariabackup\/RESTORE\r\nroot@galera3:\/mariabackup# chown -R mysql:mysql \/mariabackup\/RESTORE\r\n\r\nroot@galera3:\/mariabackup# gzip -d MARIABACKUP__20220217_100457.xb.gz\r\nroot@galera3:\/mariabackup# cd RESTORE\/\r\nroot@galera3:\/mariabackup\/RESTORE# mbstream -x < ..\/MARIABACKUP__20220217_100457.xb\r\n\r\nroot@galera3:\/mariabackup\/RESTORE# ls -lrat \r\ntotal 77900\r\ndrwxr-xr-x 3 mysql mysql 4096 Feb 17 10:40 ..\r\n-rw-r----- 1 root root 79691776 Feb 17 10:40 ibdata1\r\ndrwx------ 2 root root 4096 Feb 17 10:40 performance_schema\r\ndrwx------ 2 root root 4096 Feb 17 10:40 mysql\r\ndrwx------ 2 root root 4096 Feb 17 10:40 sakila\r\n-rw-r----- 1 root root 16384 Feb 17 10:40 aria_log.00000001\r\n-rw-r----- 1 root root 578 Feb 17 10:40 xtrabackup_info\r\n-rw-r----- 1 root root 41 Feb 17 10:40 xtrabackup_galera_info\r\n-rw-r----- 1 root root 79 Feb 17 10:40 xtrabackup_checkpoints\r\n-rw-r----- 1 root root 31 Feb 17 10:40 xtrabackup_binlog_info\r\n-rw-r----- 1 root root 389 Feb 17 10:40 mariadb-bin.000049\r\n-rw-r----- 1 root root 2560 Feb 17 10:40 ib_logfile0\r\n-rw-r----- 1 root root 4874 Feb 17 10:40 ib_buffer_pool\r\n-rw-r----- 1 root root 324 Feb 17 10:40 backup-my.cnf\r\n-rw-r----- 1 root root 52 Feb 17 10:40 aria_log_control\r\ndrwxr-xr-x 5 mysql mysql 4096 Feb 17 10:40 .\r\n<\/pre>\n
\r\nroot@galera3:\/mariabackup\/RESTORE# cat xtrabackup_binlog_info\r\nmariadb-bin.000049\t389\t0-1-329\r\n<\/pre>\n
\r\nMariaDB [(none)]> show binary logs ;\r\n+--------------------+-----------+\r\n| Log_name | File_size |\r\n+--------------------+-----------+\r\n| mariadb-bin.000055 | 403132 |\r\n| mariadb-bin.000056 | 2740 |\r\n| mariadb-bin.000057 | 599 |\r\n| mariadb-bin.000058 | 599 |\r\n| mariadb-bin.000059 | 1094 |\r\n| mariadb-bin.000060 | 412 |\r\n| mariadb-bin.000061 | 344 |\r\n+--------------------+-----------+\r\n7 rows in set (0.000 sec)\r\n<\/pre>\n
\r\nroot@galera3:~ # tar -ztvf \/mariabackup\/BINLOGS_20220217_102428.tar.gz | grep 'mariadb-bin.000049'\r\n-rw-rw---- mysql\/adm 30817312 2022-02-17 10:16 mariadb-bin.000049\r\n<\/pre>\n
\r\nroot@galera3:\/mariabackup\/RESTORE# tar -zxf ..\/BINLOGS_20220217_102428.tar.gz \r\n\r\nroot@galera3:\/mariabackup\/RESTORE# ls -lrat \r\ntotal 117136\r\n-rw-rw---- 1 mysql adm 402493 Feb 16 16:25 mariadb-bin.000033\r\n-rw-rw---- 1 mysql adm 438 Feb 16 16:25 mariadb-bin.000034\r\n-rw-rw---- 1 mysql adm 412 Feb 16 16:27 mariadb-bin.000035\r\n-rw-rw---- 1 mysql adm 4591827 Feb 16 16:51 mariadb-bin.000036\r\n-rw-rw---- 1 mysql adm 367 Feb 16 16:51 mariadb-bin.000037\r\n-rw-rw---- 1 mysql adm 4592833 Feb 16 16:53 mariadb-bin.000038\r\n-rw-rw---- 1 mysql adm 367 Feb 17 07:39 mariadb-bin.000039\r\n-rw-rw---- 1 mysql adm 770 Feb 17 07:58 mariadb-bin.000040\r\n-rw-rw---- 1 mysql adm 438 Feb 17 08:16 mariadb-bin.000041\r\n-rw-rw---- 1 mysql adm 438 Feb 17 08:20 mariadb-bin.000042\r\n-rw-rw---- 1 mysql adm 438 Feb 17 08:22 mariadb-bin.000043\r\n-rw-rw---- 1 mysql adm 438 Feb 17 08:24 mariadb-bin.000044\r\n-rw-rw---- 1 mysql adm 438 Feb 17 08:25 mariadb-bin.000045\r\n-rw-rw---- 1 mysql adm 412 Feb 17 09:33 mariadb-bin.000046\r\n-rw-rw---- 1 mysql adm 367 Feb 17 09:33 mariadb-bin.000047\r\n-rw-rw---- 1 mysql adm 2413649 Feb 17 10:05 mariadb-bin.000048\r\n-rw-rw---- 1 mysql adm 30817312 Feb 17 10:16 mariadb-bin.000049\r\n-rw-rw---- 1 mysql adm 31345403 Feb 17 10:19 mariadb-bin.000050\r\n-rw-rw---- 1 mysql adm 11424743 Feb 17 10:19 mariadb-bin.000051\r\n-rw-rw---- 1 mysql adm 11424743 Feb 17 10:19 mariadb-bin.000052\r\n-rw-rw---- 1 mysql adm 11424743 Feb 17 10:19 mariadb-bin.000053\r\n-rw-rw---- 1 mysql adm 11424743 Feb 17 10:19 mariadb-bin.000054\r\ndrwxr-xr-x 3 mysql mysql 4096 Feb 17 10:40 ..\r\ndrwxr-xr-x 2 mysql mysql 4096 Feb 17 10:57 .\r\n\r\nroot@galera3:\/mariabackup\/RESTORE# for file in mariadb-bin.000049 mariadb-bin.000050 mariadb-bin.000051 mariadb-bin.000052 mariadb-bin.000053 mariadb-bin.000054\r\n> do \r\n> echo "${file}" \r\n> mysqlbinlog ${file} --base64-output=decode-rows | grep -in "delete from rental"\r\n> done\r\nmariadb-bin.000049\r\n212555:#Q> delete from rental_1466 where return_date > '2005-07-01 00:00:00'\r\n487940:#Q> delete from rental_1471 where return_date > '2005-07-01 00:00:00'\r\nmariadb-bin.000050\r\n496895:#Q> delete from rental_1475 where return_date > '2005-07-01 00:00:00'\r\nmariadb-bin.000051\r\n141460:#Q> delete from rental_1477 where return_date > '2005-07-01 00:00:00'\r\nmariadb-bin.000052\r\n141460:#Q> delete from rental_1476 where return_date > '2005-07-01 00:00:00'\r\nmariadb-bin.000053\r\n141460:#Q> delete from rental_1479 where return_date > '2005-07-01 00:00:00'\r\nmariadb-bin.000054\r\n141458:#Q> delete from rental_1478 where return_date > '2005-07-01 00:00:00'\r\n<\/pre>\n\r\nroot@galera3:\/mariabackup\/RESTORE# tar -zxf ..\/BINLOGS_20220217_110741.tar.gz\r\nroot@galera3:\/mariabackup\/RESTORE# for file in mariadb-bin.000055 mariadb-bin.000056 mariadb-bin.000057 mariadb-bin.000058 mariadb-bin.000059 mariadb-bin.000060 \r\n> do \r\n> echo "${file}" \r\n> mysqlbinlog ${file} --base64-output=decode-rows | grep -in "delete from rental"\r\n> done\r\nmariadb-bin.000055\r\n31:#Q> delete from rental\r\nmariadb-bin.000056\r\nmariadb-bin.000057\r\nmariadb-bin.000058\r\nmariadb-bin.000059\r\nmariadb-bin.000060\r\n<\/pre>\n\r\nroot@galera3:\/mariabackup\/RESTORE# mysqlbinlog mariadb-bin.000055 | more\r\n(...)\r\n# at 299\r\n#220217 10:19:09 server id 1 end_log_pos 344 CRC32 0x3eb16ee1 \tBinlog checkpoint mariadb-bin.000054\r\n# at 344\r\n#220217 10:19:09 server id 1 end_log_pos 389 CRC32 0xefa5a7e6 \tBinlog checkpoint mariadb-bin.000055\r\n# at 389\r\n#220217 10:26:22 server id 1 end_log_pos 431 CRC32 0x628184fc \tGTID 0-1-344 trans\r\n\/*!100101 SET @@session.skip_parallel_replication=0*\/\/*!*\/;\r\n\/*!100001 SET @@session.gtid_domain_id=0*\/\/*!*\/;\r\n\/*!100001 SET @@session.server_id=1*\/\/*!*\/;\r\n\/*!100001 SET @@session.gtid_seq_no=344*\/\/*!*\/;\r\nSTART TRANSACTION\r\n\/*!*\/;\r\n# at 431\r\n# at 472\r\n#220217 10:26:22 server id 1 end_log_pos 472 CRC32 0xd222415b \tAnnotate_rows:\r\n#Q> delete from rental\r\n#220217 10:26:22 server id 1 end_log_pos 532 CRC32 0x34accc81 \tTable_map: `sakila`.`rental` mapped to number 64 (has triggers)\r\n# at 532\r\n#220217 10:26:22 server id 1 end_log_pos 594 CRC32 0xd312376b \tTable_map: `sakila`.`payment` mapped to number 63 (has triggers)\r\n(...)\r\n<\/pre>\n
\na. Restauration du backup complet
\nb. Restauration du journal mariadb-bin.000049 \u00e0 partir de la position 389
\nc. Restauration des journaux mariadb-bin.000050 \u00e0 mariadb-bin.000054 complets
\nd. Restauration du journal mariadb-bin.000055 jusqu’\u00e0 la position 389 non comprise.<\/p>\nRestauration de la s\u00e9quence de backup sur le noeud 3 et r\u00e9export de la table rental<\/h2>\n
\r\nroot@galera3:\/mariabackup\/RESTORE# systemctl stop mariadb.service\r\nroot@galera3:\/mariabackup\/RESTORE# cd \/var\/lib\/mysql\r\nroot@galera3:\/var\/lib\/mysql# rm -rf *\r\n<\/pre>\n
\r\nroot@galera3:\/var\/lib\/mysql# mariabackup --prepare \\ \r\n--target-dir=\/mariabackup\/RESTORE\/ \r\nmariabackup based on MariaDB server 10.3.34-MariaDB debian-linux-gnu (x86_64)\r\n[00] 2022-02-17 10:53:28 cd to \/mariabackup\/RESTORE\/\r\n(...)\r\n00] 2022-02-17 10:53:29 Last binlog file \/var\/log\/mysql\/mariadb-bin.000048, position 402837\r\n[00] 2022-02-17 10:53:29 completed OK!\r\n\r\nroot@galera3:\/var\/lib\/mysql# mariabackup --copy-back \\\r\n--target-dir=\/mariabackup\/RESTORE\/ \\\r\n--user=mariabackup --password=********\r\nmariabackup based on MariaDB server 10.3.34-MariaDB debian-linux-gnu (x86_64)\r\n[01] 2022-02-17 10:52:21 Copying ib_logfile0 to \/var\/lib\/mysql\/ib_logfile0\r\n[01] 2022-02-17 10:52:21 ...done\r\n[01] 2022-02-17 10:52:21 Copying ibdata1 to \/var\/lib\/mysql\/ibdata1\r\n(...)\r\n[01] 2022-02-17 10:52:22 Copying .\/xtrabackup_info to \/var\/lib\/mysql\/xtrabackup_info\r\n[01] 2022-02-17 10:52:22 ...done\r\n[00] 2022-02-17 10:52:22 completed OK!\r\n\r\n<\/pre>\n
\r\nroot@galera3:\/var\/lib\/mysql# chown -R mysql:mysql *\r\nroot@galera3:\/var\/lib\/mysql# systemctl start mariadb.service\r\n<\/pre>\n
\r\nroot@galera3:\/mariabackup\/RESTORE# mysqlbinlog \\\r\n\/mariabackup\/RESTORE\/mariadb-bin.000049 \\\r\n--start-position=389 | mysql\r\n\r\nroot@galera3:\/mariabackup\/RESTORE# for file in \/mariabackup\/RESTORE\/mariadb-bin.000050 \/mariabackup\/RESTORE\/mariadb-bin.000051 \/mariabackup\/RESTORE\/mariadb-bin.000052 \/mariabackup\/RESTORE\/mariadb-bin.000053 \/mariabackup\/RESTORE\/mariadb-bin.000054\r\n> do\r\n>\techo "Restoring ${file}..."\r\n>\tmysqlbinlog ${file} | mysql\r\n> done\r\n\r\nroot@galera3:\/mariabackup\/RESTORE# mysqlbinlog \\\r\n\/mariabackup\/RESTORE\/mariadb-bin.000055 \\\r\n--stop-position=389 | mysql\r\n<\/pre>\n\r\nroot@galera3:\/mariabackup\/RESTORE# mysql \\\r\n--execute="select count(1) from sakila.rental;"\r\n+----------+\r\n| count(1) |\r\n+----------+\r\n| 16044 |\r\n+----------+\r\n\r\nroot@galera3:\/mariabackup\/RESTORE# mysqldump \\\r\n--user=root --socket=\/var\/run\/mysqld\/mysqld.sock \u2013password=***** \\\r\nsakila rental > \/mariabackup\/rental.sql\r\n<\/pre>\n
R\u00e9import de la table dans un autre noeud du cluster<\/h2>\n
\r\nroot@galera1:\/mariabackup# mysql sakila < rental.sql\r\n<\/pre>\n
R\u00e9int\u00e9gration de galera3 dans le cluster et arr\u00eat de l’arbitre<\/h2>\n
\r\nroot@galera3:~# vi \/etc\/mysql\/mariadb.conf.d\/60-galera.cnf \r\n(...)\r\n Cluster Configuration\r\nwsrep_provider = \/usr\/lib\/galera\/libgalera_smm.so\r\nwsrep_cluster_address = gcomm:\/\/10.186.157.38,10.186.157.242,10.186.157.196\r\nwsrep_cluster_name = TestCluster\r\nwsrep_on = ON\r\nwsrep_sst_method = mariabackup\r\nwsrep_sst_donor = galera1, galera2\r\nwsrep_sst_auth = mariabackup:capdata\r\n(...)\r\n\r\nroot@galera3:\/var\/lib\/mysql# systemctl restart mariadb.service\r\n<\/pre>\n
\r\n2022-02-17 13:21:03 0 [Note] WSREP: Member 0.0 (galera3) synced with group.\r\n<\/pre>\n
\r\nroot@galerarb:~# killall garbd\r\n<\/pre>\n
\n~David<\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"