La réplication maintient un second serveur portant les mêmes données, appliquant les mêmes changements peu après le premier. Elle sert à trois choses, et on la déploie régulièrement pour une quatrième qu'elle n'assure pas.
À quoi elle sert
- La capacité de lecture - les rapports et la recherche vont sur le réplica, les écritures sur le primaire.
- Des sauvegardes sans charge - exportez depuis le réplica et le site en production ne s'aperçoit de rien.
- La bascule - une copie tiède prête à être promue, ce qui transforme une reconstruction en un simple changement.
Ce qu'elle n'est pas
Le retard que personne n'anticipe
La réplication est asynchrone par défaut : le primaire n'attend pas. Une écriture suivie aussitôt d'une lecture sur le réplica peut rendre l'ancienne valeur - un client enregistre son profil et celui-ci apparaît inchangé.
mysql -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind|Replica_(IO|SQL)_Running'
La règle qui l'évite : ne lire depuis le réplica que là où des données légèrement en retard sont acceptables. Tout ce que l'utilisateur vient d'écrire se lit sur le primaire.
La mise en place, dans les grandes lignes
- Activer le journal binaire sur le primaire —
log_bin, unserver_idunique, etgtid_mode = ON. - Créer un utilisateur de réplication — avec REPLICATION SLAVE et rien d'autre.
- Amorcer le réplica depuis un export cohérent —
mysqldump --single-transaction --source-data=2 - Le pointer vers le primaire et le démarrer — puis surveiller l'état jusqu'à ce qu'il rattrape son retard.
Le surveiller ensuite
Un réplica arrêté est silencieux. Il continue de répondre aux lectures avec des données vieilles de plusieurs jours, ce qui est pire que d'être tombé. Alertez à la fois sur les indicateurs de marche et sur le retard.
