Par souci de simplicité, je recommande uniquement la réplication circulaire MySQL. Voici pourquoi:
Il existe de nombreuses technologies et topologies bien supérieures à la réplication circulaire MySQL. Mon préféré, de loin, est DRBD (Distributed Replicated Block Device) . Cependant, DRBD fonctionne très bien lorsque la paire de serveurs se trouve dans le même bâtiment, centre de données et rack. C'est encore mieux lorsque vous utilisez un câble croisé dans le sous-réseau 192.168.xx entre le DRBD primaire et le DRBD secondaire. Malheureusement , DRBD a des performances horribles sur une distance entre deux emplacements, bien que DRBD puisse toujours fonctionner. Il n'y a aucune topologie de réseau pour vous offrir les performances DRBD satisfaisantes nécessaires entre deux centres de données.
Une fois que vous avez configuré la réplication circulaire MySQL entre les deux serveurs de base de données dans deux centres de données différents, le seul réglage nécessaire est pour le réseau. En substance, les performances de réplication sont fonction des paramètres réseau (vitesse / latence de la transmission du journal binaire dans MySQL Replication Setup) et des E / S disque (DRBD).
Une alternative que vous pouvez souhaiter pour une meilleure redondance est la suivante à titre d'exemple:
Configurer une paire DRBD dans les deux emplacements
Paire DRBD sur le site n ° 1 avec VIP 111.111.111.111
Paire DRBD sur le site n ° 2 avec VIP 222.222.222.222
Configurez la réplication circulaire MySQL entre les serveurs principaux DRBD dans les conditions suivantes:
Pour le site n ° 1, utilisez 222.222.222.222 comme Master_Host dans MySQL
Pour le site # 2, utilisez 111.111.111.111 comme Master_Host dans MySQL
Bien qu'introduisant un niveau de complexité, vous avez maintenant deux niveaux de redondance: DRBD dans chaque site et MySQL Circular Replication entre sites. Vous avez les avantages supplémentaires d'exécuter des sauvegardes via mysqldump sur le DRBD primaire du serveur de secours automatique.
En ce qui concerne le basculement, DRBD fournit un basculement automatique sur n'importe quel site.
Ce n'est que dans le cas où un centre de données est totalement indisponible que vous utiliserez le DB VIP sur le site de secours automatique.
MISE À JOUR
Je viens de faire une double prise et j'ai remarqué que vous utilisez Drupal6. Je suis heureux que vous convertissiez toutes les tables drupal en InnoDB. Cela supprimera toute possibilité de mises à jour de table MyISAM entraînant le blocage des verrous de table DB Connections qui lisent simplement les tables MyISAM. Toute mise à jour DML (INSERT, UPDATEs, DELETEs) contre une table MyISAM FERA TOUJOURS UN VERROUILLAGE COMPLET DE LA TABLE !!! L'utilisation d'InnoDB introduira un verrouillage au niveau des lignes, ce qui élimine les verrous de table complets.
De plus, DRBD devient votre ami lorsque tout est InnoDB car la récupération après incident sera cohérente entre la paire DRBD. Contrawise, DRBD avec MyISAM ne vous achète rien car une table MyISAM en panne sur le DRBD primaire est simplement dupliquée sur le DRBD secondaire comme, vous l'avez deviné , une table MyISAM en panne.
MISE À JOUR # 2
Vous devez utiliser deux niveaux de redondance
Niveau 1: dans chaque centre de base de données, utilisez DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html
Configurer une paire de serveurs DB
Démarrage DRBD
Démarrage MySQL sur le DRBD principal
Cela crée des données redondantes au niveau du disque.
Niveau 2: vous devez configurer la réplication circulaire MySQL entre
le principal DRBD de DataCenter # 1 et le principal DRBD de DataCenter # 2
Chaque DRBD primaire exécutera MySQL et agira
à la fois comme maître et esclave les uns des autres
J'ai configuré des topologies clients comme celle-ci et je la considère assez stable.