Quelle est la vitesse de la réplication MySQL?

J'envisage de configurer la réplication de notre base de données mysql pour pouvoir avoir des esclaves locaux dans chacune de nos succursales, tout en ayant le maître au bureau principal pour améliorer les performances des applications (de manière significative) dans nos succursales.

La base de données elle-même n'est pas si grande (<1 Go) mais je me demande; compte tenu des mises à jour d'enregistrement 200-300 / min: quelle est la rapidité de la réplication? (en supposant, tout d'abord, une connexion DSL générique de 5 Mo, plus rapide si nécessaire - en essayant de maintenir les coûts aussi bas que possible mais l'argent est là pour plus)

Les tables entières sont-elles répliquées par lots? La réplication est-elle effectuée, à la demande, lorsque chaque enregistrement d'une table est mis à jour (à partir des documents, je pense que je vois qu'il est configurable)?

Remarques:

• Je pense à 1 maître, 2 esclaves (2 succursales pour l'instant) configurés comme dans les documents ici, sauf que c'est une application, pas un client Web
• Toute mise à jour effectuée sur le maître doit être répliquée sur les autres esclaves en <10 minutes.
• Tout cela suppose que je puisse satisfaire notre ORM (DevExpress XPO) avec le concept de lecture depuis l'esclave et d'écriture vers le maître.

La réplication MySQL se produit le plus près possible du temps réel, limité par les E / S disque et réseau. Les esclaves ouvrent une prise au maître, qui reste ouverte. Lorsqu'une transaction se produit sur le maître, elle est enregistrée dans le binlog et est simplement rejouée sur le ou les esclaves. Si le socket entre maître et esclave est interrompu, le binlog est relu pour l'esclave lors de la prochaine connexion réussie.

La réplication multimaître fait la même chose, mais dans les deux sens.

Certains calculs de base vous aideront à mieux déterminer vos besoins en bande passante.

Average transaction size * number of slaves * updates/minute = bandwidth needed

J'espère que cela t'aides.

La réplication côté esclaves est gérée par deux threads indépendants.

• Le processus de lecture du journal, qui se connecte au maître, reçoit chaque instruction de modification de données, l'écrit dans le journal du relais.
• Le processus d'écriture sql, qui prend de nouveaux éléments du journal de relais, valide les instructions dans la base de données des esclaves, puis déplace le pointeur esclave au-delà de cette instruction pour indiquer la réception de la requête.

La latence de réplication est limitée par les E / S, d'une part les E / S sur la base de données esclave pour appliquer les transactions du journal de relais (ce qui peut impliquer des requêtes SQL complexes) et d'autre part par les E / S sur le maître pour lire son binlog et le transmettre à chaque esclave.

La réplication MySQL augmente la capacité de lecture des requêtes mais n'augmente pas les performances d'écriture des requêtes, qui sont déclenchées à la vitesse des E / S peuvent être vidées dans le binlog sur le maître et l'esclave

La réplication dans MySQL est assez rapide pour obtenir les données vers l'esclave (plus rapide que vous pourrez exécuter le UPDATEsur le maître et basculer vers une autre fenêtre pour exécuter un SELECTsur l'esclave, si(et seulement si) les connexions réseau sont toutes en place et tout fonctionne correctement. Toute connexion de classe DSL devrait convenir au cas général de vos petites requêtes régulières, mais les grandes requêtes d'insertion / mise à jour peuvent prendre un peu de temps à copier et à resynchroniser en cas de bourrage de réplication (et MySQL est vicieusement enclin à ceux-ci, malheureusement) prendront un certain temps (en recopiant l'intégralité de votre base de données depuis le maître). Il existe des astuces pour limiter l'impact de la resynchronisation sur votre maître, comme mettre votre MySQL sur LVM afin que vous puissiez faire un verrouillage / instantané très rapide et rsync le contenu de l'instantané à l'esclave, mais finalement une resynchronisation va sucer.