397 liens privés
hum mais pourquoi on utilise pas ça au boulot... quand un serveur (sous percona 5.6) reboot tout seul pendant la nuit (d'ailleurs merci aws ec2 pour cette super nuit #sysadminlife)).
Actuellement il se produit exactement ceci quand le slave crash entre le commit de transaction et la mise à jour du relay-log.info:
"""
The relay-log.info file contains the position of the slave relay log, which the slave is applying. Somehow, if a crash occurs on the slave between transaction commit and update of relay-log.info, the replication can be inconsistent – indicating that the relay-log.info file may not be in sync on the disk and contains old information. As a result, when the slave starts again it will read old events from the relay log. And because of this the transaction can be applied multiple times.
"""
Issu du dernier GNU Linux Mag: http://boutique.ed-diamond.com/home/874-gnulinux-magazine-184.html#/format_du_magazine-magazine_papier
Bon, le tuto utilise la version 9.1 de pgsql mais ça reste d'actualité car les changements majeurs pour la répli sont intervenus avec cette version.
Via collègue, merci!
"""
pt-table-checksum and pt-table-sync are the finest tools from Percona Toolkit to validate data between master/slave(s). With the help of these tools you can easily identify data drifts and fix them
"""
Encore des supers outils de l'excellente suite "Percona Toolkit".
Voir aussi pt-archiver https://jeekajoo.eu/links/?KaxoGw + xtrabackup https://jeekajoo.eu/links/?zi8wkw
Mysql 5.6 apporte la réplication multi-threadée. Je vois 2 avantages parmi d'autres:
- meilleures performances parce que forcément on a un nombre de worker threads supérieur à 1
- mise en place de la réplication plus facile, moins sujette à des erreurs coté ops grâce aux GTID. En effet il n'y a plus besoin d'indiquer de MASTER_LOG_FILE / MASTER_LOG_POS. Mysql s'autopositionne en scannant les transactions dans les binlogs. Il se place sur la transaction qui n'a pas encore été exécutée sur le réplica.
Références:
"""
STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
"""
encore un article pertinent du blog de percona (qui est pour moi une référence dès qu'on veut gérer un mysql en prod)
celui-ci traite des problèmes de réplication. la cause, la résolution.
complémentaire avec https://jeekajoo.eu/links/?OXR4gQ
un ptit pdf qui apprend à résoudre des problèmes de réplication mysql classiques.