Comment écrire le Mysql log binaire position de maître lorsque l'on fait un dump de l'esclave?

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

De voir que c'est le cas, connectez-vous à MySQL sur votre esclave et de l'exécution:

FLUSH TABLES WITH READ LOCK

SHOW SLAVE STATUS \G

Note le Read_Master_Log_Pos

Attendez quelques secondes et une fois de plus de lancer:

SHOW SLAVE STATUS \G

Vous devriez noter que les Read_Master_Log_Pos a changé.

Depuis la sauvegarde est lancée rapidement après que nous avons vérifier le statut, la position du journal enregistrées par le script peut être exacte. 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 exécuter STOP SLAVE SQL_THREAD; au lieu de FLUSH TABLES WITH READ LOCK pour la durée de la sauvegarde.

Une fois terminé, redémarrez à nouveau la réplication avec START SLAVE

Aussi, si vous souhaitez sauvegarder l'emplacement des journaux pour des sauvegardes incrémentielles ou comme une mesure de sécurité supplémentaire, il est utile d'ajouter --flush-logs à l' $dumpoptions variable au-dessus de

OriginalL'auteur Evan Muehlhausen

À l'aide de Read_Master_Log_Pos que la position pour continuer à partir de le maître, vous pouvez vous retrouver avec des données manquantes.

La Read_Master_Log_Pos variable est la position du maître binaire du fichier journal de l'esclave " IO fil.

Le problème ici est que, même dans la petite quantité de temps entre l'arrêt de l'esclave thread SQL et de récupération de la Read_Master_Log_Pos le IO thread peut avoir reçu plus de données à partir de le maître, qui n'a pas été appliquée par le thread SQL après avoir été arrêté.

Cette résultats dans la Read_Master_Log_Pos être en avance sur les données retournées dans le mysqldump, laissant un écart dans les données lors de l'importation et a continué sur un autre esclave.

La valeur correcte à utiliser sur l'esclave est Exec_Master_Log_Pos, ce qui est le maître binaire du fichier journal de l'esclave " thread SQL exécutée dernière, il n'y a pas de lacune dans les données entre la commande mysqldump et la Exec_Master_Log_Pos.

À l'aide de Ross script ci-dessus 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

OriginalL'auteur Andy Burton