Réplication MySQL sur des serveurs géographiquement séparés

Mon organisation a cherché à répartir géographiquement nos serveurs tout en gardant les sauvegardes très à jour et, idéalement, à répartir la charge.

La première chose à laquelle je pense est Rails sur MySQL. Le taux d'écriture n'est pas trop élevé (les articles / commentaires étant laissés à moins de 1 par minute, bien que certains aient de grandes pièces jointes).

Donc,

• la réplication MySQL fonctionne-t-elle bien sur les réseaux étendus?
• La connexion (ou un serveur esclave) en panne signifie-t-elle qu'une intervention manuelle est requise (une fois que les deux serveurs peuvent se parler à nouveau) ou la récupération est-elle automatique?
• Si le maître disparaît, que faut-il pour transformer un esclave en maître? Existe-t-il des scripts / outils standard pour aider à gérer cela?
• Tout autre problème, etc.?

Nous utilisons la réplication à travers les centres de données dans plusieurs pays européens (donc ils ne sont pas à travers le monde les uns des autres, mais ils ne sont certainement pas locaux) et cela fonctionne sans aucun problème.

La réplication redémarrera automatiquement si possible. S'il y a un problème avec une requête (par exemple, une base de données est présente sur le maître et non sur l'esclave, et qu'une requête l'utilise), alors elle nécessitera une correction manuelle par défaut (mais vous pouvez la configurer pour ignorer ces erreurs). Si les bases de données sont des miroirs exacts, vous ne devez jamais avoir à redémarrer manuellement la réplication.

Si vous avez deux serveurs et que le maître disparaît, pour transformer l'esclave en «maître», arrêtez simplement la réplication et modifiez votre code (pour écrire sur le nouveau «maître»). Si vous disposez de trois serveurs ou plus et que le maître disparaît, arrêtez la réplication sur les esclaves, modifiez-les pour utiliser le nouveau maître et redémarrez. S'ils ne sont pas exactement synchronisés (cela dépend de la quantité de données transférées, de l'occupation des serveurs, de la qualité de la connexion réseau, etc.), vous devrez peut-être faire plus de travail que cela. La section de réplication de la documentation MySQL couvre cela plus en détail .

Je suggérerais que vous vous assuriez que vous répliquez via SSL (c'est-à-dire que l'utilisateur de la réplication requiert une connexion SSL).

La réplication a radicalement changé dans MySQL 5.1. Dans 5.0, seule la réplication basée sur les instructions était utilisée. Vous avez maintenant la possibilité de faire une réplication basée sur les lignes ou une réplication basée sur les mixtes. Cela affectera considérablement la façon dont vous répliquez sur un WAN.

Si vous avez la possibilité de: A) Prendre le relais IP (si vos serveurs sont géographiquement séparés, cela n'est pas probable) B) Apporter des modifications DNS agiles Vous pouvez éviter de modifier le code / la configuration de l'application pour changer les maîtres. Nous utilisons le DNS interne avec une mise en cache courte et de faux domaines .internal. Si nous devons changer masterdb.internal pour être un autre serveur, en 5 secondes le changement se propage.

Dans un centre de données unique, nous utilisons la prise en charge IP. Tous les serveurs de base de données ont des interfaces virtuelles (eth0: 1, eth0: 2, eth0: 3) qui ne sont pas activées au démarrage. Si l'un des esclaves a besoin de prendre le relais, il vous suffit d'ethup eth0: 2 et c'est le maître. Dans ce scénario, eth0 est le «si» que nous utilisons pour décortiquer et autres. Les applications se connectent sur eth0: 1 qui ne sera pas activé au démarrage si mon script détecte que l'IP est prise. (wikipedia STONITH) Les autres ifs sont pour reprendre les IPs des maîtres qui peuvent avoir besoin d'être basculés.

Je ne recommanderais pas de traverser les océans lors de l'utilisation d'une réplication MySQL. J'ai essayé une fois de reproduire à partir d'un maître en Europe alors que l'esclave était au Texas. La réplication s'est interrompue presque tous les jours jusqu'à ce que nous abandonnions ce projet. Bien sûr, cela peut fonctionner, mais il a tendance à devenir plus fragile plus la distance entre le maître et l'esclave est grande.