J'exécute actuellement MySqldump sur un esclave MySQL pour sauvegarder notre base de données. Cela a fonctionné bien pour sauvegarder nos données elles-mêmes, mais ce que je voudrais compléter avec la position de journalisation binaire du maître correspondant aux données générées par le mysqldump.
Faire cela permettrait de restaurer notre esclave (ou d'installer de nouveaux esclaves) sans avoir à faire une mysqldump distincte sur la base de données principale où nous saisissons la position du journal binaire du maître. Nous allions prendre les données générées par le mysqldump, combinez-la avec les informations de journal binaires que nous avons générées, et que vous soyez resynisés.
Jusqu'à présent, mes recherches me sont très proches de pouvoir accomplir cet objectif, mais je ne peux pas sembler comprendre une manière automatisée de le retirer. Voici les "presque" que j'ai découverts:
Cela semble être assez commun que quelqu'un ait dû comprendre auparavant, espérons que quelqu'un utilise un débordement de pile?
5 Réponses :
Le script de shell suivant s'exécutera en cron ou périodique, remplacez les variables si nécessaire (les paramètres 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
Yup, c'est semblable à mon deuxième scénario ci-dessus. Si les documents MySQL doivent être croyants, vous pouvez obtenir la position binaire du maître de l'esclave en arrêtant le fil esclave et montrant le statut de l'esclave. Cela ne nécessite pas de verrouillage du maître. Mais j'espère trouver une solution automatisée qui stockera automatiquement la position du journal des bacs au cours de la gestion de notre sauvegarde quotidienne.
Hé, avait totalement oublié que le statut de maître peut être récupéré de l'esclave! Acclamations pour le rappel. J'ai ajouté les informations au shellscript qui effectue des sauvegardes quotidiennes, nous devrions donc disposer d'informations de journal binaire écrites maintenant aux côtés des sauvegardes. J'ajouterai les informations à ma réponse, ne sera applicable directement si vous utilisez un système * NIX, mais je suis sûr que si vous travaillez sur un système Windows, vous avez votre propre façon de le faire :)
Le OP ne veut vraiment pas faire des tables de verrouillage avec une serrure de lecture sur le maître. Personne, personne, vraiment.
Ce n'est pas un verrou de lecture sur le maître, c'est une serrure de lecture sur l'esclave.
Salut Ross, bon travail, que presque travaille pour moi. Si vous pouviez faire les modifications suivantes, je l'accepterai comme la réponse: * Tous les bits «-U
De plus, il serait probablement préférable de supprimer simplement le sommet du maître de verrouillage. Votre deuxième solution esclave est exactement ce que la question appelle.
Hey, merci pour les conseils de nettoyage, devrait être bon maintenant! Heureux cela aidé.
Une chose à noter, exécution MySQL $ userpassword -e 'Flush Tables avec Lire Lock' ne conservera pas la serrure! La serrure sera libérée dès que cette commande est terminée. Ne pas maintenir la serrure entraînera des données qui ne sont pas synchronisées avec d'autres tables. Étant donné que le verrouillage est sorti immédiatement après la fin de la commande exécutée, la commande de suivi des tables de déverrouillage est inutile. De plus, plusieurs des options mysqldump ne sont pas nécessaires non plus, car elles sont actives par défaut à l'aide de la commande --OPT. Vérifiez la page MySqldump Man.
mysqldump --user = *** - mot de passe = *** -lock-all-tables --Dump-esclave = 2 Base de données> /backup.sql Il ajoutera la position principale et le fichier journal dans Dump
Votre deuxième option ressemble à la bonne voie.
Je devais comprendre un moyen de faire des sauvegardes différentielles à l'aide de MySqldump. J'ai fini par écrire un script qui a choisi les bases de données à sauvegarder puis exécuté mysqldump. Impossible de créer un script qui a suivi les étapes mentionnées dans http://dev.mysql.com/doc/refman/5.1/fr/mysqldump.htm#option_mysqldump_master-data et appelez-le d'un travail cron?
Juste une pensée, mais je suppose que vous pouvez ajouter le "changement de maître à" à la dumpfile et il serait exécuté lorsque vous avez restauré / configurer le nouvel esclave.
Bien que le script de Ross soit sur la bonne voie, @JoAtis a raison quand il dit d'arrêter l'esclave avant de vérifier la position du journal principal. La raison étant est la verrouillage de lecture ne préservera pas le notez le Attendez quelques secondes et encore une fois exécuté: < Pré> xxx Vous devez remarquer que le Étant donné que la sauvegarde est initiée rapidement après avoir vérifié l'état, la position du journal enregistré par Le script peut être précis. Cependant, c'est préférable de suivre la procédure ici:
http://dev.mysql.com/doc /refman/5.0/fr/Replication-Solutions-Backups-mysqldump.html et exécuté Lorsque vous avez terminé, lancez la réplication à nouveau avec aussi, si vous souhaitez sauvegarder le bac -Logs pour des sauvegardes incrémentielles ou comme une mesure de sécurité supplémentaire, il est utile d'ajouter des journaux -Flush à la variable $ DumpOptions ci-dessus read_master_log_pos esclave et exécution: read_master_log_pos lis_master_log_pos a changé. stop esclave sql_thread; au lieu de tables de rinçage avec verrouillage de lecture pendant la durée de la sauvegarde. Démarrer esclave
Utilisation de read_master_log_pos comme position pour continuer à partir du Master signifie que vous pouvez vous retrouver avec des données manquantes.
La variable Lecture_MAST_LOG_POS est la position dans le fichier journal binaire principal que le fil Slave IO est à la hauteur.
Le problème ici est que même dans la petite quantité de temps entre arrêter le fil SQL esclave et récupérer le thread IO peut avoir reçu plus de données de la maîtrise qui n'a pas été appliquée par le fil SQL ayant été arrêté.
Il en résulte dans la lecture_master_log_pos étant plus en avant que les données renvoyées dans la MySqldump, laissant une lacune dans les données lorsqu'elles sont importées et poursuivies sur un autre esclave.
la valeur correcte à utiliser sur L'esclave est EXEC_MASTER_LOG_POS, qui est la position dans le fichier journal principal binaire que le fil SQL SLAVE est exécuté, ce qui signifie qu'il n'y a pas de déficit de données entre le mysqldump et l'exécutant_mogog_pos.
Utilisation du script de Ross au-dessus de l'utilisation correcte. serait:
mysqldump (sur 5.6) semble avoir une option -dump-esclave que lorsqu'il est exécuté sur un esclave enregistre les co-commandes binaires du maître que le nœud était un esclave de. L'intention d'un tel député est exactement ce que vous décrivez.
(Je suis en retard, je sais)