Comment fonctionne la réplication master–replica de MySQL, et en quoi aide-t-elle à la montée en charge des lectures ?

Question

IT Interview Practice · Accepted Answer

La réplication diffuse les modifications d'une **source (master)** vers une ou plusieurs **replicas**. La source enregistre chaque modification validée dans son **binary log (binlog)** ; le thread d'I/O de chaque replica copie ce log et un thread SQL/applier le rejoue, si bien que les replicas convergent vers les mêmes données. ## Le flux ``` écritures app ---------> [ SOURCE ] --- binlog ---> [ replica 1 ] <-- lectures | [ replica 2 ] <-- lectures +---------- binlog ---> [ replica 3 ] <-- lectures ``` - **Formats** — `ROW` (journalise les images réelles des lignes, défaut sûr), `STATEMENT` ou `MIXED`. - **Async (par défaut)** — la source valide sans attendre les replicas : rapide, mais un replica peut prendre du retard. - **Semi-sync** — la source attend qu'au moins un replica accuse réception, échangeant un peu de latence contre de la durabilité. ## Montée en charge des lectures Dirigez les écritures vers la source et répartissez les `SELECT` sur les replicas. Les applications à forte lecture (la plupart des applications web) font monter leurs lectures en charge de façon quasi linéaire en ajoutant des replicas, tandis que la source unique traite toujours toutes les écritures. ```sql -- Sur un replica, surveillez son retard : SHOW REPLICA STATUS\G -- Seconds_Behind_Source: 2 <- retard de réplication -- Replica_IO_Running: Yes -- Replica_SQL_Running: Yes ``` ## Le hic : le retard de réplication Comme les replicas asynchrones sont en retard sur la source, un utilisateur qui écrit puis lit immédiatement depuis un replica peut ne pas voir sa propre modification (violation du "read-your-writes"). Dirigez vers la source les lectures sensibles à la latence ou tout juste écrites, ou utilisez le semi-sync. ## Pourquoi c'est important La réplication est la première étape standard pour faire monter les lectures en charge et disposer d'un standby chaud pour le failover/les sauvegardes. Sa limitation caractéristique — le retard, et le goulot d'étranglement unique en écriture — façonne les architectures réelles : elle explique pourquoi vous lisez parfois des données périmées et pourquoi la montée en charge des écritures finit par nécessiter du sharding, et pas seulement davantage de replicas.

Le flux

Montée en charge des lectures

Le hic : le retard de réplication

Pourquoi c'est important

Questions connexes