Cómo escribir la posición de registro binario de MySQL del maestro al hacer un mysqldump de esclavo?

Question

Actualmente estoy corriendo mysqldump en un esclavo de MySQL para copia de seguridad de base de datos. Esto ha funcionado bien para copias de seguridad de nuestros datos en sí, pero lo que me gustaría es complementarlo con la posición log binario del maestro que se corresponde con los datos generados por el mysqldump.

Hacer esto nos permitiría restaurar nuestro esclavo (o la configuración de nuevos esclavos) sin tener que hacer un mysqldump separado sobre la base de datos principal, donde cogemos la posición log binario del maestro. Nos gustaría simplemente tomar los datos generados por el mysqldump, combinarla con la información de registro binario que hemos generado, y listo ... se resynced.

Hasta ahora, mi investigación se ha hecho sentir muy cerca de ser capaz de lograr este objetivo, pero me parece que no puede averiguar una forma automatizada para llevarlo a cabo. Estos son los "almosts" He cubierto:

• Si estábamos corriendo mysqldump desde la base de datos principal, podríamos utilizar el parámetro "---master de datos" con mysqldump para registrar la posición binario del maestro junto con los datos de volcado (supongo que esto sería probablemente también funcionará si empezamos a generar logs binarios de nuestro esclavo, pero eso parece excesivo para lo que queremos lograr)
• Si quisiéramos hacer esto en una forma no automatizada, podríamos registrar en la base de datos del esclavo y ejecutar "STOP SLAVE SQL_THREAD;" seguido de "SHOW STATUS SLAVE;" ( http://dev.mysql.com/doc/refman/5.0/ es / mysqldump.html ). Pero esto no nos va a hacer ningún bien a menos que sepamos de antemano que queremos hacer una copia de algo del ungüento.
• Si tuviéramos 500 $ / año a soplar, podríamos utilizar el plugin de copia de seguridad en caliente InnoDB y simplemente hacer funcionar nuestros mysqldumps de la base de datos principal. Pero no tenemos ese dinero, y yo no queremos añadir cualquier E / S adicional en nuestra base de datos principal de todos modos.

Esto parece algo bastante común que alguien debe haber dado cuenta antes, es de esperar que alguien está usando desbordamiento de pila?

Answer 1

El siguiente script se ejecutará en cron o periódica, sustituir las variables según sea necesario (por defecto están escritas para FreeBSD):

# 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

A pesar de que el guión de Ross está en el camino correcto, @joatis tiene razón cuando dice para detener el esclavo antes de verificar la posición del registro maestro. La razón de ser es la READ LOCK no conservará el Read_Master_Log_Pos que se recupera con SHOW SLAVE STATUS.

Para ver que este es el caso, inicie sesión en MySQL en su esclavo y ejecute:

FLUSH TABLES WITH READ LOCK

SHOW SLAVE STATUS \G

Tenga en cuenta el Read_Master_Log_Pos

Espera unos segundos y una vez ejecute:

SHOW SLAVE STATUS \G

Se debe notar que el Read_Master_Log_Pos ha cambiado.

Desde la copia de seguridad se inicia rápidamente después comprobamos el estado, la posición de registro registrado por el guión puede ser exacta. Sin embargo, su prefereable en lugar de seguir el procedimiento aquí: http://dev.mysql.com/doc /refman/5.0/en/replication-solutions-backups-mysqldump.html

Y STOP SLAVE SQL_THREAD; en lugar de FLUSH TABLES WITH READ LOCK correr por la duración de la copia de seguridad.

Cuando haya terminado, iniciar la replicación de nuevo con START SLAVE

Además, si desea copiar los Bin-logs para las copias de seguridad incrementales o como una medida de seguridad adicional, es útil para añadir --flush-logs a la variable $ dumpoptions anterior

Answer 3

Esta segunda opción parece el camino correcto.

Tenía que encontrar una manera de hacer copias de seguridad diferenciales usando mysqldump. Terminé de escribir un guión que lo eligió bases de datos de copia de seguridad y luego ejecuta mysqldump. ¿No podría crear un script que siguió los pasos mencionados en http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_master-data y llamar a que a partir de una tarea programada?

1. conectarse a MySQL y "escala de esclavos"
2. ejecutar SHOW SLAVE STATUS
3. Tienda nombre_archivo, file_pos en las variables
4. volcado y reinicie el esclavo.

Es sólo una idea, pero supongo que podría añadir el "CHANGE MASTER TO" línea al fichero de volcado y que conseguiría ejecutada cuando se restauró / configura el nuevo esclavo.

Answer 4

El uso de Read_Master_Log_Pos como la posición para continuar desde el maestro significa que puede terminar con los datos que faltan.

La variable Read_Master_Log_Pos es la posición en el archivo de registro binario maestro que el esclavo IO hilo es de hasta.

El problema aquí es que incluso en la pequeña cantidad de tiempo entre la interrupción del flujo SQL esclavo y al recuperar los Read_Master_Log_Pos el proceso de IO pueda haber recibido más datos de la maestra que no ha sido aplicada por el flujo SQL de haber sido detenido.

Esto da lugar a los Read_Master_Log_Pos siendo más adelante que los datos devueltos en el mysqldump, dejando un hueco en el momento de su importación de datos y continúa en otro esclavo.

El valor correcto para utilizar en el esclavo es Exec_Master_Log_Pos, que es la posición en el archivo de registro binario maestro que el flujo SQL esclavo último ejecutado, significando que no hay vacío de datos entre el mysqldump y los Exec_Master_Log_Pos.

Uso de la escritura de Ross por encima del uso correcto sería:

# 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 (en 5.6) parece tener una opción --dump-esclavo que cuando se ejecuta en un esclavo registra el registro binario co-ords del maestro que el nodo era un esclavo de. La intención de un vertedero de este tipo es exactamente lo que usted está describiendo.

(llego tarde, lo sé)