Was können wir in der Replikation von MySQL 5.0 tun, um Bandbreitenprobleme auszuräumen?

Question

Ich entwickle eine Anwendung, die auf dem Client-PC (Win) ausgeführt wird, der mit einer MySQL Server 5.1-Instanz konfiguriert ist, die als schreibgeschützte Sklave für den Remote-Master fungiert. Der Remote -Meister hat Dutzende von Schemas, aber ich brauche nur einen pro Kunden, also liefere ich die Replikation-do-db Einstellen in my.ini, um das Schema nur zu replizieren, das der Kunde benötigt. Die Replikation funktioniert, aber wenn unsere Kunden in Regionen der Welt einsteigen, in denen der Internetzugang nur über 3G Wireless verfügbar ist, die nach Datennutzung berechnen, überschreiten sie schnell ihre Datenplanbeschränkungen und begegnen teure Probleme.

Wie ich es verstehe, schreibt MySQL alle Transaktionen für alle Schemas in eine einzelne Binlog -Datei, was bedeutet, dass jeder Client alle Transaktionen herunterladen muss, die für jedes Schema auf dem Master durchgeführt werden, und dann nach dem Herunterladen des Datenbankfilter Replikation-do-db Einstellungen in der My.ini -Datei des Kunden.

Um diese Ineffizienz zu minimieren, habe ich die verwendet Slave_Compressed_Protocol = 1 Die Einstellung, die die übertragenen Daten um 50%zu verringern scheint, aber dennoch dazu führt, dass unsere Kunden ihre Datengrenze schnell überschreiten, erhöhen die 3G -Rechnung.

Ich kann mir nicht vorstellen, dass ich der einzige bin, der dadurch gegenübersteht. Ich bin mir sicher, dass ich eine Menge Antworten darauf bekomme, wie ich dies erreichen kann, indem ich x = y einstellen. Ich kann jedoch keine Dokumentation einer solchen Einstellung oder einen empfohlenen Ansatz finden.

Bisher ist hier mein Gedanke an eine mögliche Lösung. Bitte geben Sie Feedback oder alternative Routen an:

---

1. Richten Sie für jedes Schema einen "Proxy" -Slave ein (auf einer anderen Box oder gleiche Box mit einer anderen MySQL -Instanz/Port)
2. Konfigurieren Sie den Proxy-Slave so, dass sie nur die eine Datenbank replizieren, die die Clients replizieren möchten.
3. Konfigurieren Sie die MySQL -Instanz des Clients als Sklaven an den entsprechenden Proxy -Sklaven.

Dies sollte führen dazu, dass der Client nur die Binlog -Daten für sein Schema zieht. Der Nachteil (soweit ich das beurteilen kann) ist, dass es die Komplexität unseres Setups dramatisch erhöht und wahrscheinlich zerbrechlicher wird.

Gedanken? Wird dieser Ansatz überhaupt funktionieren?

Beachten Sie, dass wir den MySQL 5.0 -Server auf Redhat ausführen, aber wir könnten auf 5.5 aktualisieren, wenn er eine Lösung erzeugt.

Answer 1

Vorschlag Nr. 1: Verwenden Sie Verteilungsmeister

Ein Distribution Master ist ein MySQL-Slave mit aktivierter Protokoll-Bin, Protokoll-Slave-Updates aktiviert und enthält nur Tabellen mit dem Blackhale Storage Engine. Sie können Replikat-DO-DB auf den Verteilungsmaster anwenden und Binärprotokolle am Distribution Master erstellen, der nur das DB-Schema enthält, das Sie gewünscht sind. Auf diese Weise reduzieren Sie die Größe ausgehender Binlogs aus dem Verteilungsmaster.

Sie können einen Verteilungsmaster wie folgt einrichten:

1. MySQldumt tump Ihre Datenbank (en) mithilfe-no-data-Option, um einen Schema-Dump zu generieren.
2. Laden Sie den Schema-Dump nur in den Verteilungsmaster.
3. Konvertieren Sie jede Tabelle im Distribution Master in die Blackhoe Storage Engine.
4. Richten Sie die Replikation in den Distribution Master von einem Master mit realen Daten ein.
5. Fügen Sie die Replikat-DO-DB-Option (s) zu /etc/my.cnf des Distribution Master hinzu.

Für die Schritte 2 und 3 können Sie auch den Schema-Dump bearbeiten und ersetzen Motor = MyISAM und Motor = InnoDB mit Motor = Blackhole und dann das bearbeitete Schema-Dump in den Verteilungsmaster laden.

Wenn Sie nur in Schritt 3 die Konvertierung aller MyISAM- und InnoDB -Tabellen in Blackhole im Distribution Master umstellen möchten, führen Sie die folgende Abfrage aus und geben Sie sie in eine Textdatei aus:

mysql -h... -u... -p... -A --skip-column-names -e"SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name', ENGINE=BLACKHOLE;') BlackholeConversion FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','mysql') AND engine <> 'BLACKHOLE'" > BlackholeMaker.sql

Ein zusätzlicher Bonus für das Scripting der Umwandlung der Tabelle in die Blackhoe Storage Engine ist das Speicherspeicher -Engine Tabellen werden ebenfalls konvertiert. Während Speicherspeicher -Engine -Tabelle keinen Speicherplatz für die Datenspeicherung einnehmen, wird der Speicher aufgenommen. Durch das Konvertieren von Speichertabellen in Blackhole wird der Speicher im Verteilungsmeister übersichtlich gehalten.

Solange Sie keine DDL in den Distribution Master senden, können Sie alle DML (Einfügen, Aktualisieren, Löschen) übertragen, bevor Sie Kunden nur die gewünschten DB -Informationen replizieren lassen.

Ich habe bereits einen Beitrag in einer anderen Stackexchange -Site geschrieben, in der die Verwendung eines Verteilungsmeisters besprochen wird.

Vorschlag Nr. 2: Verwenden Sie kleinere Binärprotokolle und Relaisprotokolle

Wenn Sie einstellen MAX_BINLOG_SIZE Zu etwas Lächerlich kleinem, können Binlogs in kleineren Stücken gesammelt und verschickt werden. Es gibt auch eine separate Option, um die Größe der Relaisprotokolle festzulegen. max_relay_log_size. Wenn max_relay_log_size = 0 ist, wird es standardmäßig auf max_binlog_size standardmäßig eingestellt.

Vorschlag Nr. 3: Verwenden Sie semisynchrone Replikation (Nur MySQL 5.5)

Richten Sie Ihre Hauptdatenbank und mehrere Verteilungsmeister als MySQL 5.5 ein. Aktivieren Sie die semisynchrone Replikation, damit die Hauptdatenbank Binlogs schnell an den Distribution Master versenden kann. Wenn alle Ihre Sklaven Verteilungsmeister sind, benötigen Sie möglicherweise keine halbsynchrone Replikation oder MySQL 5.5. Wenn eine der Sklaven außer Distribution Masters reale Daten für die Berichterstattung, hohe Verfügbarkeit, passive Standby- oder Sicherungszwecke verfügt, gehen Sie in Verbindung mit semisynchroner Replikation mit MySQL 5.5.

Vorschlag Nr. 4: Verwenden Sie Anweisungsbasis Binary-Protokollierung NICHT Zeilenbasiertes basierend

Wenn eine SQL-Anweisung mehrere Zeilen in einer Tabelle aktualisiert, speichert die Anweisung Binary Logging (SBBL) nur die SQL-Anweisung. Die gleiche SQL-Anweisung unter Verwendung einer zeilenbasierten Binärprotokollierung (RBBL) zeichnet die Zeilenänderung für jede Zeile tatsächlich auf. Dies macht deutlich, dass die Übertragung von SQL -Anweisungen Platz für binäre Protokolle spart, die SBBL über RBBL durchführen.

Ein weiteres Problem besteht. Dies kann für einen Sklaven nicht gut sein, insbesondere für einen Vertriebsmeister. Stellen Sie daher sicher, dass alle DML keine AA -Datenbank und einen Zeitraum vor Tabellennamen haben.

Answer 2

Die max_binlog_size sollte irrelevant sein - Binlog -Daten werden kontinuierlich gestreamt.

Vorsicht vor einem "Verteilungsmeister" - es ist ein "einziger Fehler des Versagens". Das heißt, wenn es stirbt, erhalten alle Sklaven darüber hinaus keine Daten, und der Wiederaufbau des Relais wird die Arbeit erfordern.

SBR gegen RBR - Es hängt von der Abfrage ab. Entweder kann besser oder schlechter sein als der andere.

Setzen Sie die Verteilungsmeister auf die gleiche Maschine wie der eigentliche Meister oder auf eine Maschine "in der Nähe" des Meisters. Verwenden Sie separate Ports, um die Instanzen getrennt zu halten.