Réplication retardée

le 08/05/2008 à 22:52
Réplication retardée
Lorsque la réplication retarde de 3 secondes, cela a un impact sur la cohérence d'un serveur Web. Mais alors, quel est le fou qui veut pouvoir configurer 30 minutes de retard sur une réplication ?

En fait, la réplication permet de protéger un serveur contre les crash : si le serveur maître plante, l'esclave dispose déjà des commandes nécessaires pour proposer une sauvegarde de secours, jusqu'au moment du crash. Mais si c'est une erreur d'administration, où la commande DROP TABLE n'est pas munie d'une condition WHERE, alors votre bévue sera immédiatement répercutée sur l'esclave et donc, la sauvegarde. La réplication protège contre les crash, mais pas contre les bourdes.

La réplication retardée, de 30 minutes par défaut, peut vous aider dans ce genre de situations.

- Time delayed replication
- MySQL: Time Delayed Replication

A lire également

Un problème courant de la réplication MySQL est le lag, ou encore le retard entre le serveur maître et les serveurs esclave. La réplication est asynchrone, et les deux peuvent finalement être séparé d'une durée variable.

Dries Buytaert propose plusieurs approches pour gérer ce retard, à défaut de le corriger.

1. Exécuter les requêtes sur le maître, sauf en lecture seule
2. Passer en réplication synchrone (cluster MySQL, patch Google)
3. Utiliser un équilibreur de charge, ou un proxy
4. Utiliser le partitionnement et le sharding
5. Réécrire l'application pour qu'elle gère ce retard
6. Utiliser le modèle media wiki, où on teste le retard, et on attend qu'il se résorbe

- Database replication lag
- google-mysql-tools
- MySQL Proxy home
- Continuent Sequoia
Google avait attiré l'attention du monde MySQL en publiant un patch au code source pour une réplication synchrone : les transactions sont validées dans le maître quand elles ont été validées au moins sur un esclave. Voilà résolvait le problème de retard de réplication de nombreuses architectures.

Depuis, je n'ai pas relevé de nouvelles, mais le projet n'est pas mort, loin de là ! Il y a une longue liste de patch pour MySQL 4 et 5. Il y a des statistiques d'utilisation des ressources beaucoup plus fines que celles fournies de base, et notamment cette perle de MySQLPerformancesBlogue pour identifier les index inutilisés!

InnoDB est aussi le centre de beaucoup d'attention, ainsi que les mutex (pour les accès concurrents), et les informations de surveillances. Il y a même un serveur HTTP intégré à MySQL..

Notons que ce patch requiert une version recompilée de MySQL, ce qui va en freiner l'utilité. Ni Proven Scaling, ni Percona ne distribue de version patchée actuellement. Un candidat ?

- Unused indexes by single query
- google-mysql-tools

Commentaires

Ecrire

Ecrire un message

Votre message vient d'être créé avec succès.
LoadingChargement en cours