Quelle serait ma meilleure méthode de synchronisation MySQL?

Question

Nous déplaçons un service de médias sociaux vers des centres de données distincts, car l'ensemble du centre de données de notre autre fournisseur d'hébergement s'est effondré. Deux fois. Cela signifie que les deux sites Web doivent être synchronisés dans un certain sens - je suis moins préoccupé par le code des pages, c'est assez facile à synchroniser, mais ils doivent avoir les mêmes données de base de données.

D'après mes recherches sur le SO, il semble réplication MySQL est une bonne option, mais le manuel MySQL, pour la montée en puissance, dit que son meilleur quand il y a beaucoup plus lit alors il y a des ecritures/mises à jour: http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-scaleout.html

Dans notre cas, c'est à peu près égal. Nous recevons environ 200 à 300 000 demandes par jour et nous pouvons nous développer rapidement. Chaque requête est à la fois une demande de lecture et d'écriture.

Quelle serait la meilleure méthode ou outil pour gérer cela?

Answer 1

La réplication n'est pas instantanée et toutes les écritures doivent être envoyées par câble aux serveurs distants, ce qui nécessite également de la bande passante. Tant que cela fonctionne pour vous et que vous comprenez les conséquences, ne vous inquiétez pas du rapport lecture/écriture.

Toutefois, êtes-vous sûr que vous avez besoin d'une réplication globale? Nous traitons des millions de requêtes et disposons d'un emplacement, avec plusieurs serveurs Web connectés à deux bases de données. Une base de données est la base de données en direct, et l'autre est une base de données en lecture seule répliquée.

Nous avons des pannes globales, et certaines personnes s'y connectent n'importe quand, même si notre nœud principal est en panne parce qu'il a des problèmes avec Internet. Les données ne font que s'égoutter.

Si le nœud principal était en panne, alors tout le monde utiliserait les emplacements de basculement globaux, dans l'ordre. Donc, si notre noeud principal venait à disparaître, tous les clients se connecteraient à Denver. Si Denver tombait, ils se connecteraient tous à Columbus.

En outre, notre noeud principal est sur deux fournisseurs Internet différents, donc un FAI qui descend ne nous enlève pas.

Answer 2

La vitesse de connexion entre deux datacenters est-elle suffisante? Vous pouvez copier des fichiers sur un nouveau serveur et y déplacer une base de données. Et puis installer l'ancien serveur afin qu'il se connecte à la base de données MySQL du nouveau serveur dans un autre DC? Ce sera plus lent bien sûr, mais en fonction de la nature de vos requêtes, il peut être acceptable. Dès que DNS ou tout ce qui bouge/se termine, vous éteignez l'ancien serveur quand il n'y a plus de demandes.

Answer 3

Pour vous aider à évaluer vos options, vous devez prendre en compte vos besoins dans un scénario de reprise après sinistre (c'est-à-dire la perte totale du système dans un centre de données). En particulier pour ce scénario, combien de données pouvez-vous vous permettre de perdre (objectif de point de récupération - RPO), et avec quelle rapidité avez-vous besoin de la version de centre de données de secours du site opérationnel (objectif de temps de récupération - RTO). Par exemple, si votre RPO n'est pas une transaction perdue et récupération dans 5 minutes, alors la solution serait différente que si vous pouvez vous permettre de perdre 5 minutes de transactions et une heure pour récupérer.

Une autre question que je voudrais poser est si vous utilisez du stockage SAN à tous? Cela vous donne des options de réplication au niveau du stockage (baie SAN vers baie SAN), plutôt qu'au niveau de la base de données (par exemple, réplication MySQL).

également à considérer est la distance entre les centres de données (par exemple TimeWise peut vous permettre d'effectuer une écriture synchrone aux deux bases de données, ou si une approche de réplication asynchrone plus approprié)