Comment écrire la position de log binaire du maître lorsque vous faites un mysqldump d'esclave?

Question

Je suis mysqldump actuellement en cours d'exécution sur un esclave Mysql pour sauvegarder notre base de données. Cela a bien fonctionné pour la sauvegarde de nos données elles-mêmes, mais ce que je voudrais compléter par est la position de log binaire du maître qui correspond aux données générées par le mysqldump.

Faire cela nous permettrait de restaurer notre esclave (ou la configuration de nouveaux esclaves) sans avoir à faire une mysqldump distincte sur la base de données principale où nous saisissons la position de log binaire du maître. Nous voudrions simplement prendre les données générées par le mysqldump, combiner avec les informations du journal binaire nous avons généré, et le tour est joué ... resynchronisation des.

Jusqu'à présent, mes recherches me est devenu très proche d'être en mesure d'atteindre cet objectif, mais je ne peux pas sembler trouver un moyen automatisé de le retirer. Voici les « almosts » J'ai découverts:

• Si nous courions mysqldump de la base de données principale, nous pourrions utiliser le paramètre « --master-data » avec mysqldump pour vous connecter la position binaire ainsi que les données de vidage du maître (je suppose que cela fonctionnerait probablement aussi si nous avons commencé à générer journaux binaires de notre esclave, mais cela semble exagéré pour ce que nous voulons accomplir)
• Si nous voulions faire cela dans une base de données de manière non automatisée, on peut se connecter à l'esclave et exécuter « STOP SLAVE SQL_THREAD; » suivi de "SHOW SLAVE STATUS;" ( http://dev.mysql.com/doc/refman/5.0/ fr / mysqldump.html ). Mais cela ne va pas nous faire du bien à moins que nous savons à l'avance que nous voulons sauvegarder quelque chose du Salve.
• Si nous avions 500 $ / an pour souffler, nous pourrions utiliser le plug-in de sauvegarde à chaud InnoDB et il suffit d'exécuter nos mysqldumps de la principale DB. Mais nous n'avons pas cet argent, et je ne veux pas ajouter d'E / S supplémentaires sur notre principale DB de toute façon.

Cela semble être quelque chose d'assez commun que quelqu'un doit avoir compris avant, espérons que quelqu'un utilise le débordement de pile?

Answer 1

Le script shell suivant exécutera dans Cron ou périodique, remplacer les variables selon les besoins (par défaut sont écrits pour 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

Bien que le scénario de Ross est sur la bonne voie, @joatis a raison quand il dit d'arrêter l'esclave avant de vérifier la position du journal maître. La raison en est le READ LOCK ne conservera pas le Read_Master_Log_Pos qui est récupéré avec SHOW SLAVE STATUS.

Pour voir que c'est le cas, connectez-vous sur votre esclave MySQL et lancez:

FLUSH TABLES WITH READ LOCK

SHOW SLAVE STATUS \G

Notez le Read_Master_Log_Pos

Attendez quelques secondes et exécutez une nouvelle fois:

SHOW SLAVE STATUS \G

Vous devriez remarquer que le Read_Master_Log_Pos a changé.

Depuis la sauvegarde est lancée rapidement après que nous vérifions l'état, la position de journal enregistrée par le script peut être précis. Cependant, son prefereable au lieu de suivre la procédure ici: http://dev.mysql.com/doc /refman/5.0/en/replication-solutions-backups-mysqldump.html

Et au lieu de courir STOP SLAVE SQL_THREAD; FLUSH TABLES WITH READ LOCK pendant toute la durée de la sauvegarde.

Lorsque vous avez terminé, recommencez la réplication avec START SLAVE

En outre, si vous souhaitez sauvegarder les bin-journaux pour des sauvegardes incrémentielles ou en tant que mesure de sécurité supplémentaire, il est utile d'ajouter --flush-journaux à la variable $ ci-dessus

Answer 3

Vous êtes deuxième option ressemble à la bonne voie.

Je devais trouver un moyen de faire des sauvegardes différentielles à l'aide mysqldump. Je fini par écrire un script qui a choisi les bases de données à sauvegarder, puis mysqldump. Ne pourriez-vous créer un script qui a suivi les étapes mentionnées dans http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_master-data et appeler à partir d'un travail cron?

1. connecter à mysql et "stop esclave"
2. exécuter SLAVE STATUS SHOW
3. nom_fichier magasin, file_pos dans les variables
4. décharge et redémarrez l'esclave.

Juste une pensée mais je devine que vous pouvez ajouter la ligne « CHANGE MASTER TO » au dumpfile et il serait exécuté lors de la restauration / configuration du nouvel esclave.

Answer 4

Utilisation Read_Master_Log_Pos que la position de continuer du maître signifie que vous pouvez retrouver avec des données manquantes.

La variable Read_Master_Log_Pos est la position dans le fichier journal binaire maître que le fil IO esclave est à.

Le problème ici est que même dans le peu de temps entre l'arrêt du thread SQL esclave et retreiving les Read_Master_Log_Pos le fil IO a pu recevoir plus de données du maître qui n'a pas été appliquée par le thread SQL ayant été arrêté.

Il en résulte les Read_Master_Log_Pos étant plus loin que les données renvoyées au mysqldump, en laissant un espace dans les données lorsqu'elles sont importées et suite à un autre esclave.

La valeur correcte à utiliser sur l'esclave est Exec_Master_Log_Pos, qui est la position dans le fichier journal binaire maître que le fil de SQL esclave dernier exécuté, signifiant qu'il n'y a pas d'écart de données entre le mysqldump et les Exec_Master_Log_Pos.

En utilisant le script de Ross au-dessus de l'utilisation correcte serait:

# 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 (sur 5,6) semble avoir une option --dump-esclave qui, lorsqu'il est exécuté sur un esclave enregistre les co-ords log binaires du maître que le noeud est un esclave de. Le but d'une telle décharge est exactement ce que vous décrivez.

(je suis en retard, je sais)