MySQL Replikation - Slave mit Sync-Lag

S

smooth

New Member
Hallo,

folgendes Szenario:

- MySQL replikation mit 2 Servern (Master-Master Replikation)

Aktuell wird nur DB1 im Produktionsystem verwendet (d.h. alle Queries der Applikation laufen darueber), DB2 dient lediglich zum dumpen der Backups und zum gelegentlichen ausfuehren groeßerer SELECT Queries (Statistiken).

Jetzt kam es ungluecklicherweise dazu dass der SLAVE Thread auf DB2 gestoppt wurde und dies 4 Tage nicht bemerkt wurde, ergo ist DB2 nun 4 Tage hinter DB1 zurueck.
Das Problem ist nun das dieses Lag (seconds_behind_master) durch den Slave nicht wieder aufgeholt wird (schwankt nun seit 5 Tagen zw. 3,5 und 4 Tagen delay).
Gibt es nun eine Moeglichkeit diesen Vorgang zu beschleunigen?

Vielen Dank!
 
Wenn der Slave wirklich nicht mehr aufholen kann, dann würde ich einen mysqldump des Masters ziehen, im Slave einspielen und die Replication neu starten. Dadurch sollte der Delay deutlich kleiner sein und der Slave relativ zügig wieder zum Master aufgeschlossen haben.
Alternativ beziehungsweise zur Vermeidung eines künftigen grossen Delays hilft nur deutlich mehr Bandbreite, bevorzugt über dedizierte NICs und zudem eine Reduzierung der Locks auf dem Master.
 
Bevor es vergessen wird: Notiere Dir bitte vorher die Binlog-Position des Master und setze beim Ziehen des mysqldump einen globalen write-lock, sonst riskierst Du einen Datenverlust.
Code: 
mysqldump [options] --lock-all-tables --all-databases -uroot -p > mysqldump.sql
 
Danke zunaechst fuer die Antwort.

Die komplette Replikation neu aufzusetzen waere die absolute letzte Moeglichkeit, es geht hier um eine DB mit >300Mio Eintraegen, d.h. ein Export (welcher ja auch mit lock-Tables gemacht werden muss) wuerde den produktiven Betrieb der Applikation eine lange Zeit ausser gefecht setzen.

Gibt es nicht andere Moeglichkeiten? Z.b. mit Maatkit?

Probleme bzw. Eigenheiten bzgl. Master-Master replikation sind bekannt.
 
Besteht die Möglichkeit ein Filesystemsnapshot (LVM?) zu nutzen?

Ansonsten mit der Brechstange (grob skizziert), aber nicht ohne Backup!:
Slave: MySQLd stoppen
Slave: Datadir komplett sichern
Slave: Datadir löschen und neu anlegen
Master: Globalen Write-Lock setzen
Master: Binlog-Position feststellen
Master: MySQLd stoppen
Master: Datadir auf den Slave kopieren
Master: MySQLd starten
Slave: Datadir aufräumen (Alles ausser DB-Files entsorgen)
Slave: MySQLd starten
Slave: Replikation mit Binlog-Position starten

Genauen Ablauf bitte auf einem Testsystem mehrfach verifizieren!


Ich übernehme keinerlei Haftung für etwaige Datenverluste!
 
Joe User said:
Bevor es vergessen wird: Notiere Dir bitte vorher die Binlog-Position des Master und setze beim Ziehen des mysqldump einen globalen write-lock, sonst riskierst Du einen Datenverlust.
Code: 
mysqldump [options] --lock-all-tables --all-databases -uroot -p > mysqldump.sql
Click to expand...

Ich empfehle hier die zusätzliche Verwendung von --master-data=2

Damit schreibt mysqldump automatisch die richtige Master-Position als Kommentar in den Dump

Code: 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000801', MASTER_LOG_POS=106;

Zum Problem des OP:

Wenn ihr nächtliche Backups der Datenbank macht kann man auch ein Backup nehmen und (vorrausgesetzt man kennt die Position des Masters zum Zeitpunkt des Backups, was man sollte) dann von da aus die Replikation neu starten, ggf. ist man dann zumindest 'näher dran'.

Tipp für die Zukunft: Mit Monitoring wäre das nicht passiert. Wieso man so ein System produktiv ohne Monitoring betreibt versteh' ich nicht.

Interessant wäre auch zu schauen wo eigentlich der Bottleneck sitzt warum der Slave nicht aufholt. Einfach mal mit top und dstat schauen ob es CPU oder IO-Bound ist oder ob es tatsächlich am Netzwerk liegt.

weiterhin viel Erfolg,
Nils
 
Wenn InnoDB zum Einsatz kommt empfiehlt sich ein Backup per xtrabackup. Hiermit kann "non-blocking" fix gesichert werden, auch inkrementell. Der Restore-Prozess ist auch ziemlich fix.

Du kannst auch Slaves damit synchronisieren glaube ich, habe es aber noch nicht ausprobiert.

MyISAM kann es auch sichern, hierbei werden aber Schreib-Locks auf die Tabellen gesetzt, was zu Ausfällen der Seite führen kann, falls bspw. Session-Daten in der Datenbank gespeichert werden.
 
remote_mind said:
Wenn ihr nächtliche Backups der Datenbank macht kann man auch ein Backup nehmen und (vorrausgesetzt man kennt die Position des Masters zum Zeitpunkt des Backups, was man sollte) dann von da aus die Replikation neu starten, ggf. ist man dann zumindest 'näher dran'.
Click to expand...

Das geht leider nicht da die Backups ja von DB2 (der mit lag) gezogen werden um eben die produktive Seite nicht ausser gefecht zu setzen.

Es kommen leider auch keine InnoDBs zum Einsatz sondern nur MyISAM.

Das Bottleneck scheint auf Plattenebene zu liegen, s. Auszug von dstat:

Code: 
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  1   0  94   5   0   0|1564k 1227k|   0     0 |  79B  166B| 276   634
  0   0  90  10   0   0|   0  1244k|  39k 2558B|   0     0 | 495   303
  0   0  89  11   0   0|   0  2036k|  17k 1930B|   0     0 | 516   387
  0   0  86  14   0   0|   0  1260k|2276B  742B|   0     0 | 313   274
  0   0  75  25   0   0|   0  1484k|5992B 1864B|   0     0 | 408   338
  0   0  91   9   0   0|   0  1432k|2145B  742B|   0     0 | 312   274
  0   0  89  11   0   0|   0  1000k|3322B  940B|   0     0 | 267   249
  0   0  80  20   0   0|   0  1580k|6954B 1600B|   0     0 | 400   288
  0   0  71  29   0   0|   0  2016k| 768B  478B|   0     0 | 462   429
  0   0  80  20   0   0|   0  1348k| 904B  544B|   0     0 | 343   489
  0   0  82  18   0   0|1160k 1668k|  28k 5692B|   0     0 | 550  1454
  0   0  96   4   0   0|4992k   48k|  43k   13k|   0     0 | 472   651
  1   1  94   4   0   0|  22M 4096B| 809B  494B|   0     0 | 164  1049
  3   1  92   4   0   0|  44M    0 |2943B  890B|   0     0 | 648  2030
  4   1  90   5   0   0|2248k    0 |6827B 1996B|   0     0 | 678   783
  5   2  88   5   0   0|2172k 1624k|  80k   23k|   0     0 |1681  1919

Die Netzwerklast ist mit max 5Mbit zu vernachlaessigen.
 
Die Platten-IO lässt sich bei MySQL ein wenig reduzieren, indem man InooDB (zwei Files / Tabelle) statt MyISAM (drei Files / Tabelle) verwendet. Desweiteren ist es wichtig, die Erzeugung temporärer on-disk-Tabellen zu reduzieren und die Queries noch etwas zu optimieren.

Die letzten beiden Aufgaben musst Du weitestgehend selbst erledigen, da wir weder das DB-Layout noch die Queries kennen. Aber beim Umstieg auf InnoDB und der nötigen Konfiguration können wir helfen, sofern wir ein paar Eckdaten zur DB bekommen.
Am Wichtigsten sind hier die Gesamtgrösse der DB, die Gesamtgrösse der Indexe, die Wachstumsrate der DB und die Menge an RAM die maximal für MySQL zur Verfügung steht. Deine aktuelle my.cnf und die Ausgaben von mysqltuner.pl und tuning-primer.sh sind ebenfalls wichtige Angaben.

Langfristig musst Du aber über einen dedizierten DB-Server mit schnellen kleinen Platten nachdenken, oder die DB gar auf mehrere Server aufteilen.
 
You must log in or register to reply here.
Back
Top