Wie die Mysql Binärlog Position des Master zu schreiben, wenn ein mysqldump von Slave zu tun?

Question

Ich bin derzeit mysqldump auf einem Mysql-Slave-Backup der Datenbank. Dies hat unsere Daten für die Sicherung selbst gut funktioniert, aber was ich möchte, dass es ergänzen, mit der Binär-Log-Position des Masters, dass entspricht die von den mysqldump erzeugten Daten.

Auf diese Weise würde es uns ermöglichen, unsere Slave wiederherzustellen (oder Setup neue Slaves), ohne dass eine separate mysqldump auf der Haupt-Datenbank zu tun, wo wir die Binär-Log-Position des Masters greifen. Wir würden nur die Daten nehmen von der mysqldump erzeugt, kombinieren sie mit den binären Protokoll Informationen, die wir erzeugen, und voila ... resynced werden.

Bisher haben mich meine Forschungen bekamen ganz in der Nähe der Lage, dieses Ziel zu erreichen, aber ich kann nicht herausfinden automatisiert scheint es auszuziehen. Hier sind die „almosts“ Ich habe entdeckt:

• Wenn wir mysqldump aus der Hauptdatenbank ausgeführt wurden, können wir die „--master-data“ Parameter mit mysqldump den Master Binärstelle anmelden zusammen mit den Sicherungsdaten (ich nehme an, dies würde wahrscheinlich auch funktionieren, wenn wir Erzeugen gestartet Binärlogs von unserem Sklaven, aber das scheint übertrieben für das, was wollen wir erreichen)
• Wenn wir in einem nicht automatisierten Weg, dies tun wollten, könnten wir in die Datenbank des Slave-Protokoll und Lauf „STOP SLAVE SQL_THREAD;“ gefolgt von "SHOW SLAVE STATUS"; ( http://dev.mysql.com/doc/refman/5.0/ de / mysqldump.html ). Aber dies ist nicht geht uns etwas Gutes tun, wenn wir nicht im Voraus wissen, wollen wir wieder etwas nach oben aus der Salbe.
• Wenn wir $ 500 / Jahr zu blasen haben, wir die InnoDB Hot Backup Plug-in verwenden könnten und nur unsere mysqldumps vom Haupt DB laufen. Aber wir haben nicht das Geld haben, und ich will nicht, sowieso keine zusätzlichen I / O auf unsere DB hinzuzufügen.

Dies scheint etwas häufig genug, dass jemand vor dem herausgefunden haben muss, hoffentlich, dass jemand mit Stack-Überlauf?

Answer 1

Der folgende Shell-Skript wird in cron oder periodisch ausgeführt werden, ersetzen Variablen wie nötig (Standardwerte sind für FreeBSD geschrieben):

# MySQL executable location
mysql=/usr/local/bin/mysql

# MySQLDump location
mysqldump=/usr/local/bin/mysqldump

# MySQL Username and password
userpassword=" --user=<username> --password=<password>"

# MySQL dump options
dumpoptions=" --quick --add-drop-table --add-locks --extended-insert"

# Databases
databases="db1 db2 db3"

# Backup Directory
backupdir=/usr/backups

# Flush and Lock
mysql $userpassword -e 'STOP SLAVE SQL_THREAD;'

set `date +'%Y %m %d'`

# Binary Log Positions
masterlogfile=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep '[^_]Master_Log_File'`
masterlogpos=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep 'Read_Master_Log_Pos'`

# Write Binlog Info
echo $masterlogfile >> ${backupdir}/info-$1-$2-$3.txt
echo $masterlogpos >> ${backupdir}/info-$1-$2-$3.txt

# Dump all of our databases
echo "Dumping MySQL Databases"
for database in $databases
do
$mysqldump $userpassword $dumpoptions $database | gzip - > ${backupdir}/${database}-$1-$2-$3.sql.gz
done

# Unlock
$mysql $userpassword -e 'START SLAVE'

echo "Dump Complete!"

exit 0

Answer 2

Obwohl Ross Drehbuch auf dem richtigen Weg ist, @joatis recht, wenn er sagt, die Sklaven zu stoppen, bevor die Master-Log-Position zu überprüfen. Der Grund dafür ist die READ LOCK wird nicht die Read_Master_Log_Pos erhalten, die mit SHOW SLAVE STATUS abgerufen werden.

Um zu sehen, dass dies der Fall ist, melden Sie sich MySQL auf dem Slave und Lauf:

FLUSH TABLES WITH READ LOCK

SHOW SLAVE STATUS \G

Beachten Sie die Read_Master_Log_Pos

Warten Sie

ein paar Sekunden, und noch einmal laufen:

SHOW SLAVE STATUS \G

Sie sollten feststellen, dass der Read_Master_Log_Pos geändert hat.

Da die Sicherung ausgelöst wird schnell, nachdem wir den Status überprüfen, die Log-Position durch das Skript aufgezeichnet ist, kann genau sein. Doch statt dessen prefereable das Verfahren hier folgen: http://dev.mysql.com/doc /refman/5.0/en/replication-solutions-backups-mysqldump.html

Und läuft STOP SLAVE SQL_THREAD; statt FLUSH TABLES WITH READ LOCK für die Dauer der Sicherung.

Wenn Sie fertig sind, starten Sie die Replikation wieder mit START SLAVE

Auch wenn Sie die bin-Protokolle für inkrementelle Backups oder als zusätzliche Sicherheitsmaßnahme sichern möchten, ist es sinnvoll, append --flush-Protokolle an den $ dumpoptions Variable oben

Answer 3

Sie sind zweite Option sieht aus wie die richtige Spur.

Ich hatte einen Weg, um differenzielle Backups zu tun mysqldump verwenden. Ich landete ein Skript zu schreiben, die gewählt haben, was Datenbanken zu sichern und dann ausgeführt mysqldump. Könnten Sie nicht ein Skript erstellen, das die Schritte folgen in http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_master-data und Anruf, dass von einem cron-Job?

1. connect MySQL und "Stop Slave"
2. execute STATUS SHOW SLAVE
3. Laden file_name, file_pos in Variablen
4. Dump und den Slave neu starten.

Nur ein Gedanke, aber ich vermute, Sie die „CHANGE MASTER TO“ Linie zum dumpfile hängen könnte und es würde ausgeführt werden, wenn Sie den neuen Slave restauriert / Setup.

Answer 4

Mit Read_Master_Log_Pos als vom Master-Mitteln, um fortzufahren Sie mit fehlenden Daten können am Ende.

Die Read_Master_Log_Pos Variable ist die Position, in dem Master-Binärlogdatei dass der Slave-IO Thread zu oben ist.

Das Problem hierbei ist, dass auch in der geringen Menge an Zeit zwischen dem Slave-SQL-Thread zu stoppen und retreiving die Read_Master_Log_Pos der IO-Thread mehr Daten vom Master erhalten hat, die von dem SQL-Thread nicht gestoppt wurde beantragt zu haben.

Dies führt zu dem Read_Master_Log_Pos weiter voraus zu sein als die in den mysqldump zurückgegebenen Daten, eine Lücke in den Daten zu hinterlassen, wenn importiert und auf einem anderen Slave fortgesetzt.

Der richtige Wert auf dem Einsatz auf dem Slave Exec_Master_Log_Pos ist, das ist die Position in dem Master-Binärlogdatei, dass der Slave-SQL-Thread zuletzt ausgeführt, dh es gibt keine Datenlücke zwischen dem mysqldump ist und die Exec_Master_Log_Pos.

Skript Ross Verwendung über die richtige Anwendung wäre:

# MySQL executable location
mysql=/usr/bin/mysql

# MySQLDump executable location
mysqldump=/usr/bin/mysqldump

# MySQL Username and password
userpassword=" --user=<username> --password=<password>"

# MySQL dump options
dumpoptions=" --quick --add-drop-table --add-locks --extended-insert"

# Databases to dump
databases="db1 db2 db3"

# Backup Directory
# You need to create this dir
backupdir=~/mysqldump


# Stop slave sql thread

echo -n "Stopping slave SQL_THREAD... "
mysql $userpassword -e 'STOP SLAVE SQL_THREAD;'
echo "Done."

set `date +'%Y %m %d'`

# Get Binary Log Positions

echo "Logging master status..."
masterlogfile=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep '[^_]Master_Log_File'`
masterlogpos=`$mysql $userpassword -e 'SHOW SLAVE STATUS \G' | grep 'Exec_Master_Log_Pos'`

# Write log Info

echo $masterlogfile
echo $masterlogpos
echo $masterlogfile >> ${backupdir}/$1-$2-$3_info.txt
echo $masterlogpos >> ${backupdir}/$1-$2-$3_info.txt

# Dump the databases

echo "Dumping MySQL Databases..."
for database in $databases
do
echo -n "$database... "
$mysqldump $userpassword $dumpoptions $database | gzip - > ${backupdir}/$1-$2-$3_${database}.sql.gz
echo "Done."
done

# Start slave again

echo -n "Starting slave... "
$mysql $userpassword -e 'START SLAVE'
echo "Done."

echo "All complete!"

exit 0

Answer 5

mysqldump (auf 5.6) scheint eine Option --dump-Slave zu haben, dass auf einem Slave ausgeführt wird, wenn zeichnet die Binär-Log-Co-ords des Masters, dass der Knoten ein Sklave war. Die Absicht eines solchen Dump ist genau das, was Sie beschreiben.

(Ich bin spät, ich weiß)