Was können wir in MySQL 5.0 Replication tun, um Probleme mit der Bandbreite zu beheben?

Ich entwickle eine Anwendung zur Ausführung auf dem Client-PC (Win), der mit einer MySQL Server 5.1-Instanz konfiguriert ist, die als Nur-Lese-Slave für den Remote-Master fungiert. Der Remote-Master verfügt über Dutzende von Schemas. Ich benötige jedoch nur eines pro Client, sodass ich die Replication-Do- Db - Einstellung in my.ini angeben kann, um nur das Schema zu replizieren, das der Client benötigt. Die Replikation funktioniert, aber wenn unsere Kunden in Regionen der Welt gelangen, in denen der Internetzugang nur über 3G-WLAN verfügbar ist und die durch die Datennutzung abgerechnet werden, überschreiten sie schnell ihre Grenzen für Datentarife und stoßen auf teure Probleme.

So wie ich es verstehe, schreibt MySQL alle Transaktionen für alle Schemata in eine einzige Binlog-Datei, was bedeutet, dass jeder Client alle Transaktionen herunterladen muss, die für jedes Schema auf dem Master ausgeführt werden, und dann nach dem Herunterladen den Datenbankfilter pro Replikation anwendet. do-db- Einstellungen in der Datei my.ini des Clients.

Um diese Ineffizienz zu minimieren, habe ich die Einstellung slave_compressed_protocol = 1 verwendet , die die übertragenen Daten um 50% zu reduzieren scheint, aber dennoch dazu führt, dass unsere Kunden ihr Datenlimit schnell überschreiten und die 3G-Rechnung in die Höhe treiben.

Ich kann mir nicht vorstellen, dass ich der einzige bin, der sich dem stellen muss. Ich bin mir also sicher, dass ich durch Setzen von x = y eine Menge Antworten bekommen werde, wie dies erreicht werden kann. Ich kann jedoch keine Dokumentation für eine solche Einstellung oder einen empfohlenen Ansatz finden.

Soweit ich über eine mögliche Lösung nachgedacht habe, geben Sie bitte Feedback oder alternative Routen:

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

Dies sollte dazu führen, dass der Client nur die Binlog-Daten für sein Schema abruft. Der Nachteil (soweit ich das beurteilen kann) ist, dass dadurch die Komplexität unseres Setups dramatisch zunimmt und es wahrscheinlich anfälliger wird.

Gedanken? Funktioniert dieser Ansatz überhaupt?

Beachten Sie, dass wir den MySQL 5.0-Server unter RedHat ausführen, jedoch ein Upgrade auf 5.5 durchführen können, wenn sich eine Lösung ergibt.

VORSCHLAG 1: Verwenden Sie Distribution Masters

Ein Distribution Master ist ein MySQL-Slave mit aktiviertem Log-Bin und aktivierten Log-Slave-Updates und enthält nur Tabellen mit der BLACKHOLE Storage Engine . Sie können replicate-do-db auf den Verteilungsmaster anwenden und Binärprotokolle auf dem Verteilungsmaster erstellen, die nur die DB-Schemas enthalten, für die Sie Binärprotokolle erstellen möchten. Auf diese Weise reduzieren Sie die Größe der ausgehenden Binlogs vom Distribution Master.

Sie können einen Verteilungsmaster wie folgt einrichten:

1. mysqldump Ihre Datenbank (en) mit der Option --no-data, um einen Nur-Schema-Dump zu generieren.
2. Laden Sie den Nur-Schema-Speicherauszug in den Verteilungsmaster.
3. Konvertieren Sie jede Tabelle im Distribution Master in die BLACKHOLE-Speicher-Engine.
4. Richten Sie die Replikation auf den Distributionsmaster von einem Master mit realen Daten ein.
5. Fügen Sie /etc/my.cnf des Distributionsmasters die Option (en) replicate-do-db hinzu.

In den Schritten 2 und 3 können Sie auch den Nur-Schema-Dump bearbeiten und ENGINE = MyISAM und ENGINE = InnoDB durch ENGINE = BLACKHOLE ersetzen und diesen bearbeiteten Nur-Schema-Dump dann in den Distribution Master laden.

Führen Sie nur in Schritt 3 die folgende Abfrage aus und geben Sie sie in eine Textdatei aus, wenn Sie die Konvertierung aller MyISAM- und InnoDB-Tabellen nach BLACKHOLE im Distribution Master skripten möchten:

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 die Skripterstellung bei der Konvertierung von Tabellen in die BLACKHOLE-Speicher-Engine ist, dass auch MEMORY-Speicher-Engine- Tabellen konvertiert werden. Während die MEMORY-Speicher-Engine-Tabelle keinen Speicherplatz für die Datenspeicherung belegt, belegt sie Speicherplatz. Durch das Konvertieren von MEMORY-Tabellen in BLACKHOLE bleibt der Speicher im Distribution Master übersichtlich.

Solange Sie keine DDL an den Distribution Master senden, können Sie jede beliebige DML (INSERT, UPDATE, DELETE) senden, bevor Sie Clients die gewünschten DB-Informationen replizieren lassen.

Ich habe bereits einen Beitrag in einer anderen StackExchange-Site verfasst, in dem die Verwendung eines Distributionsmasters erläutert wird .

VORSCHLAG 2: Verwenden Sie kleinere Binärprotokolle und Relaisprotokolle

Wenn Sie max_binlog_size auf etwas Lächerlich Kleines setzen, können Binlogs in kleineren Blöcken gesammelt und versendet werden. Es gibt auch eine separate Option zum Festlegen der Größe von Relaisprotokollen , max_relay_log_size . Wenn max_relay_log_size = 0 ist, wird standardmäßig die Einstellung max_binlog_size verwendet.

VORSCHLAG 3: Semisynchrone Replikation verwenden (nur MySQL 5.5)

Richten Sie Ihre Hauptdatenbank und mehrere Distributionsmaster als MySQL 5.5 ein. Aktivieren Sie die semisynchrone Replikation, damit die Hauptdatenbank Binlogs schnell an den Distribution Master senden kann. Wenn ALLE Ihre Slaves Distributionsmaster sind, benötigen Sie möglicherweise keine semisynchrone Replikation oder MySQL 5.5. Wenn einer der Slaves außer Distribution Master über echte Daten für Berichtszwecke, Hochverfügbarkeit, passive Standby- oder Sicherungszwecke verfügt, verwenden Sie MySQL 5.5 in Verbindung mit der semisynchronen Replikation.

VORSCHLAG 4: Verwenden Sie die anweisungsbasierte binäre Protokollierung NICHT zeilenbasiert

Wenn eine SQL-Anweisung mehrere Zeilen in einer Tabelle aktualisiert, speichert die anweisungsbasierte binäre Protokollierung (SBBL) nur die SQL-Anweisung. Dieselbe SQL-Anweisung, die die zeilenbasierte binäre Protokollierung (RBBL) verwendet, zeichnet die Zeilenänderung für jede Zeile auf. Dies macht es offensichtlich, dass das Übertragen von SQL-Anweisungen Platz in Binärprotokollen spart, die SBBL über RBBL ausführen.

Ein weiteres Problem ist die Verwendung von RBBL in Verbindung mit replicate-do-db, wobei dem Tabellennamen die Datenbank vorangestellt wird . Dies kann nicht gut für einen Slave sein, besonders nicht für einen Distribution Master. Stellen Sie daher sicher, dass alle DML-Dateien keine Datenbank und keinen Punkt vor Tabellennamen haben.

Die max_binlog_size sollte irrelevant sein - Binlog-Daten werden kontinuierlich übertragen.

Vorsicht vor einem "Distribution Master" - es ist ein "Single Point of Failure". Das heißt, wenn es stirbt, empfangen alle Slave (s) jenseits davon keine Daten, und der Wiederaufbau des Relais nimmt Arbeit in Anspruch.

SBR vs RBR - es kommt auf die Abfrage an. Entweder kann besser oder schlechter sein als der andere.

Platzieren Sie die Distributionsmaster auf demselben Computer wie der echte Master oder auf einem Computer "in der Nähe" des Masters. Verwenden Sie separate Ports, um die Instanzen getrennt zu halten.