Einschränkungen des MySQL-Binlogs

Question

Ich habe eine MySQL-Instanz, die auf AWS läuft, mit etwa 5000 Einfügungen pro Sekunde.Irgendeine Idee, welche Auswirkungen es auf die Leistung haben wird, wenn ich Binlog (Zeile) und einen Binlog-Tailer verwende?

Überprüfen Sie diesen Link

Soweit ich weiß, fragt ein Bin-Log-Tailer regelmäßig das MySQL-Binlog ab, um eine „Echtzeit“-Datenverbindung zu ermöglichen.Der Binlog-Tailer läuft in NodeJS.

Der Punkt ist, dass ich MySQL verwenden muss und Meteor verwenden möchte, um die Daten in Echtzeit an meine Kunden zu senden.Daher meine Idee, diesen Binlog-Tailer zu verwenden.

Da die MySQL-Datenbank ziemlich intensiv gefüllt wird (5000 Einfügungen pro Sekunde), möchte ich wissen, an welchem ​​Punkt der Binlog/Binlog-Tailer schwerwiegende Leistungsprobleme bekommt.

Grts, Tom

Answer 1

Ich habe Software mit ähnlicher Funktionalität entwickelt, der Fähigkeit, den MySQL-Replikationsstream (Binärprotokoll, Binlog) zu verwenden, um Ereignisse als Reaktion auf Einfügungen/Aktualisierungen/Löschungen in der Datenbank nahezu in Echtzeit zu erfassen.

Hier sind einige Beobachtungen, die ich bezüglich der Leistung gemacht habe.Glücklicherweise sind die potenziellen Hotspots weitgehend unabhängig voneinander.

Da ich mit dem von Ihnen zitierten Node-Paket nicht vertraut war und seinen Code gerade erst flüchtig überprüft habe, gehe ich davon aus, dass sie das Binlog nicht wirklich durch Abfragen „verfolgen“, sondern tatsächlich einen Slave-/Replika-Server emulieren und eine Verbindung herstellen an den Master senden und den Replikationsstream anfordern.

Der erste potenzielle Engpass ist die Fähigkeit des Masters, die erforderliche Menge an Binlog-Daten zu schreiben (der I/O-Durchsatz ist die primäre Einschränkung).Wenn Ihr Master sich bereits anmeldet ROW formatieren, dann ist dieses Problem bereits gelöst.Wenn nicht, ändern Sie Ihr Binlog-Format und sehen Sie nach.ICH bevorzugen ROW Formatieren, da es für die Datenwiederherstellung sehr nützlich ist, wenn Abfragen fehlschlagen oder die Anwendung etwas mit den Daten macht, die sie nicht haben sollte.Es ist möglich (mit Tools von Drittanbietern), den Vorfall zu erfassen und rückgängig zu machen – in der Standardkonfiguration werden beispielsweise bei einem Löschvorgang die gelöschten Daten tatsächlich in das Binärprotokoll geschrieben.

Der nächste Punkt des Ressourcenverbrauchs ist die Slave-Verbindung, die ein solches Tool zum Master herstellt, wo der Master die Daten weiterleitet.Ein weit verbreitetes Missverständnis ist, dass ein Slave den Master „abfragt“.Tatsächlich initiiert der Slave die Verbindung, aber der Master pusht die Daten.Dabei handelt es sich tatsächlich um eine Belastung des Masters, die sich kaum auf die Leistung auswirkt, wenn die Anzahl der angeschlossenen Slaves gering ist (z. B. 5 oder weniger).Diese Belastung kann vom Master vollständig eliminiert werden, indem der „Binlog-Tailer“ nicht mit dem Master, sondern mit einem vorhandenen Slave des Masters verbunden wird log_slave_updates konfiguriert.

Der Transport der Daten vom Master zum Pseudo-Slave kann erhebliche Netzwerkbandbreite beanspruchen. Daher sollte Ihr externes Dienstprogramm das MySQL-Client/Server-Komprimierungsprotokoll unterstützen, um diese Bandbreite zu reduzieren.Durch die Aktivierung dieser Funktion können je nach Nutzlast Komprimierungsverhältnisse von 10:1 erreicht werden.

Der letzte Schmerzpunkt ist der externe Nutzen selbst.Das MySQL-Binlog-Format ist ein sehr dicht gepacktes Binärformat (daher „Binärprotokoll“), das analysiert und dekodiert werden muss.Die Effizienz, mit der das externe Dienstprogramm diesen Datenstrom entpacken und manipulieren kann, bestimmt, wie nahezu in Echtzeit die erkannten Ereignisse ausgegeben werden können, da ineffizienter Code dazu führt, dass Ihr entschiedener Ereignisstrom durch diesen Faktor immer weiter hinter dem Master zurückbleibt hat keine Auswirkungen auf die Leistung des Master-Servers selbst.

Kurz gesagt: Wenn Ihr Master die Arbeitslast der Generierung von Binlogs im Zeilenformat für das erwartete Datenverkehrsvolumen bewältigen kann, sind die restlichen potenziellen Probleme immer noch potenzielle Probleme, sollten aber keine nennenswerten Auswirkungen auf die Leistung des Master-Servers selbst haben.