La réplication de Binlog MySQL est un «sac de malheur». Y a-t-il de bonnes alternatives?

Question

J'ai honnêtement essayé . this left et droit et trouve toujours que mon serveur miroir, configuré comme esclave de réplication est toujours à la traîne. Le nombre d'utilisateurs de mon application ne cesse de croître et, à présent, j'ai atteint le point où je ne peux pas continuer à "arrêter". pour " resynchroniser " bases de données (pas même le week-end).

Quoi qu'il en soit, ma question: existe-t-il des alternatives plausibles, abordables , à la réplication binlog? J'ai deux serveurs, je n'envisage donc pas l'achat d'un troisième pour l'équilibrage de la charge, à moins que ce ne soit la seule option.

A bientôt,

/ mp

Answer 1

Votre maître s'exécute en parallèle et votre esclave en série. Si votre maître peut traiter une heure et demie d'insertions / mises à jour / exécutions en une heure réelle, votre esclave prendra du retard.

Si vous ne trouvez pas le moyen d'améliorer les performances d'écriture sur votre esclave (plus de mémoire, des disques plus rapides, supprimer les index inutiles), vous rencontrez un problème dans l'architecture de vos applications. Vous finirez par atteindre un point où vous ne pouvez pas exécuter les modifications en temps réel aussi rapidement que votre maître peut les exécuter en parallèle.

Beaucoup de grands sites partagent leurs bases de données: envisagez de fractionner votre maître + esclave en plusieurs clusters maître + esclave. Puis divisez votre clientèle à travers ces clusters. Lorsqu'un esclave commence à prendre du retard, il est temps d'ajouter un autre cluster.

Ce n'est pas bon marché, mais à moins que vous ne trouviez le moyen de créer des instructions d'exécution de la réplication de binlog en parallèle, vous ne trouverez probablement pas de meilleure façon de le faire.

Mise à jour (2017) : MySQL prend désormais en charge threads de travail esclave parallèle . Il existe encore de nombreuses variables qui entraîneront un esclave, mais ces derniers n'ont plus besoin d'écrire en série. Choisir de conserver l'ordre de validation des threads esclaves parallèles est une option importante à examiner si l'état exact de l'esclave à un moment donné est critique.

Answer 2

Avez-vous essayé: 1) SET innodb_flush_log_at_trx_commit = 0 2) SET sync_binlog = 0

Les deux contribueront à accélérer votre esclave avec un petit niveau de risque supplémentaire en cas de défaillance du serveur.

Answer 3

Ajouter de la mémoire à l’esclave serait probablement utile. Nous sommes passés de 32 à 128 Mo et le retard a plus ou moins disparu. Mais ce n’est ni bon marché ni suffisant dans toutes les situations.

L’achat d’un troisième serveur n’aidera probablement pas beaucoup, mais vous obtiendrez probablement un autre esclave à la traîne.