Limitations du journal binaire MySQL

Question

J'ai une instance MySQL exécutée sur AWS, avec environ 5 000 insertions par seconde.Avez-vous une idée de l'impact sur les performances si j'utilise binlog (ligne) et un queue de binlog ?

Vérifiez ce lien

D'après ma compréhension, un outil de queue de journal bin interroge périodiquement le binlog MySQL afin de rendre possible une connexion de données « en temps réel ».Le tailer binlog s'exécute dans NodeJS.

Le fait est que je dois utiliser MySQL et je souhaite utiliser Meteor pour transmettre les données en temps réel à mes clients.D'où mon idée d'utiliser ce tailer binlog.

Étant donné que la base de données MySQL va être remplie de manière assez intensive (5 000 insertions par seconde), je veux savoir à quel moment le queue binlog/binlog rencontre de graves problèmes de performances.

Merci, Tom

Answer 1

J'ai développé un logiciel avec des fonctionnalités similaires, la possibilité d'utiliser le flux de réplication MySQL (journal binaire, binlog) pour capturer des événements en temps quasi réel en réponse aux insertions/mises à jour/suppressions dans la base de données.

Voici quelques observations que j'ai faites concernant les performances.Heureusement, les points chauds potentiels sont largement indépendants les uns des autres.

Je suppose, puisque je n'étais pas familier avec le package Node que vous avez cité et que je viens juste de donner un examen rapide de leur code, qu'ils ne "suivent" pas réellement le binlog via un sondage, mais qu'ils émulent en fait un serveur esclave/réplique et se connectent. au maître et demandant le flux de réplication.

Le premier goulot d'étranglement potentiel est la capacité du maître à écrire la quantité de données Binlog requise (le débit d'E/S est la principale contrainte).Si votre maître est déjà connecté ROW format, alors ce problème est déjà résolu.Sinon, changez de format Binlog et voyez.je préférer ROW format, de toute façon, car il est très utile pour la récupération de données lorsque les requêtes échouent ou que l'application modifie les données qu'elle ne devrait pas avoir.Il est possible (à l'aide d'outils tiers) de capturer ce qui s'est passé et de l'inverser : dans la configuration par défaut, lorsqu'une suppression se produit (par exemple), les données supprimées sont en fait écrites dans le journal binaire.

Le prochain point de consommation de ressources est la connexion esclave établie par un tel outil avec le maître, où le maître transmet les données.Une idée fausse très répandue est qu'un esclave « interroge » le maître.En fait, l'esclave initie la connexion, mais le maître pousse les données.Il s'agit en fait d'une charge sur le maître qui a très peu d'impact sur les performances lorsque le nombre d'esclaves connectés est faible (disons 5 ou moins).Cette charge peut être entièrement éliminée du maître en connectant le "binlog tailer" non pas au maître, mais à un esclave existant du maître, avec log_slave_updates configuré.

Le transport des données du maître vers le pseudo-esclave peut consommer une bande passante réseau importante, votre utilitaire externe doit donc prendre en charge le protocole de compression client/serveur MySQL pour réduire cette bande passante.L'activation de cette fonctionnalité peut atteindre des taux de compression de 10:1 en fonction de la charge utile.

Le dernier problème est l’utilité externe elle-même.Le format MySQL Binlog est un format binaire très compact (d'où « journal binaire ») qui doit être analysé et décodé.L'efficacité avec laquelle l'utilitaire externe peut décompresser et manipuler ce flux de données déterminera à quel point les événements détectés peuvent être émis en temps réel, car un code inefficace entraînera un retard de plus en plus important du flux d'événements que vous avez décidé par rapport au maître, bien que ce facteur n'aura aucun impact sur les performances du serveur maître lui-même.

En bref, si votre maître peut gérer la charge de travail de génération de journaux binaires au format ligne pour le volume de trafic que vous attendez, le reste des problèmes potentiels restent des problèmes potentiels, mais ils ne devraient avoir aucune implication significative sur les performances du serveur maître lui-même.