mysqldump sur esclave (sans arrêter la réplication)
Est-il correct d'exécuter mysqldump --single-transaction sur la base de données esclave sans arrêter la réplication (stop slave;)? Il s'agit d'une sauvegarde quotidienne régulière afin que nous puissions restaurer Master DB en cas de panne de stockage. La plupart des tableaux sont InnoDB, seuls quelques-uns sont MyISAM.
La documentation officielle indique que:
"Vous devez arrêter la réplication sur l'esclave avant de démarrer le processus de vidage pour vous assurer que le vidage contient un ensemble cohérent de données".
Qu'est-ce que ça veut dire consistent data? Est-ce que cela signifie comme les dernières données?
Je connais --single-transaction signifie qu'il prend des données à partir du moment où il a été émis, donc de nouvelles modifications supplémentaires pendant le vidage seront pas enregistrées dans le vidage. Ai-je raison?
Je ne veux pas exécuter la sauvegarde sur le maître en raison du décalage qu'il crée sur notre application.
L'exécution d'un mysqldump crée un vidage cohérent et logique des données qui peuvent être récupérées à un point dans le temps.
Il existe deux façons d'arrêter la réplication à mi-chemin
MÉTHODE # 1: option mysqldump --dump-slave
Lorsque vous effectuez un mysqldump avec - - dump-slave , cela arrêtera uniquement le thread SQL. Le thread d'E/S continue de collecter les événements du journal binaire du maître. Notez comment cela est expliqué dans la documentation MySQL :
Cette option est similaire à --master-data, sauf qu'elle est utilisée pour vider un serveur esclave de réplication afin de produire un fichier de vidage qui peut être utilisé pour configurer un autre serveur en tant qu'esclave ayant le même maître que le serveur vidée. Il entraîne la sortie de vidage à inclure une instruction CHANGE MASTER TO qui indique les coordonnées du journal binaire (nom de fichier et position) du maître de l'esclave vidé. Ce sont les coordonnées du serveur maître à partir desquelles l'esclave doit commencer à se répliquer.
--dump-slave fait en sorte que les coordonnées du maître soient utilisées plutôt que celles du serveur sauvegardé, comme le fait l'option --master-data. De plus, si vous spécifiez cette option, l'option --master-data est remplacée, si elle est utilisée, et effectivement ignorée.
La valeur de l'option est gérée de la même manière que pour --master-data (la valeur no ou 1 entraîne l'écriture d'une instruction CHANGE MASTER TO dans le vidage, la valeur 2 entraîne l'écriture de l'instruction mais la place dans les commentaires SQL) et a le même effet que --master-data en termes d'activation ou de désactivation d'autres options et de gestion du verrouillage.
Cette option oblige mysqldump à arrêter le thread SQL esclave avant le vidage et à le redémarrer après.
En conjonction avec --dump-slave, les options --apply-slave-déclarations et --include-master-Host-port peuvent également être utilisées.
Cette option a été ajoutée dans MySQL 5.5.3.
MÉTHODE 2: Arrêtez vous-même le thread SQL
Saviez-vous que vous pouvez arrêter manuellement le thread SQL? Selon la documentation MySQL sur STOP SLAVE; , vous pouvez exécuter ce qui suit:
mysql> STOP SLAVE SQL_THREAD;
Le thread d'E/S continue de recevoir des événements binlog du maître.
Après avoir exécuté STOP SLAVE SQL_THREAD;, vous pouvez ensuite exécuter votre mysqldump. Vous pourriez probablement faire un instantané LVM ou autre chose sur les fichiers de données sur l'esclave.
Une fois votre sauvegarde terminée, exécutez
mysql> START SLAVE SQL_THREAD;
ou
mysql> START SLAVE;
Cela réactivera le thread SQL.
ESSAIE !!!
Avertissement : l'arrêt du thread SQL, qui met fin à une connexion DB locale, pourrait créer des tables créées avec CREATE TEMPORARY TABLE disparaître. Si vous utilisez la réplication basée sur des instructions, veuillez effectuer des recherches supplémentaires sur votre application pour vous assurer que les transactions ne sont pas annulées lorsque le thread SQL s'arrête.
QU'EN EST-IL - transaction unique ???
Vous pouvez mysqldump en utilisant - - single-transaction ??? sans - dump-slave . Cependant, il existe de nombreuses commandes qui interrompent les transactions en cours. Voir la liste de ces commandes dans mon ancien post Workflow DDL transactionnel pour MySQL .
MISE À JOUR 2018-02-13 13:07 EST
Vous venez de me le demander : These backups are for restoring the master DB in case of a storage disaster. Not for slave. So is --dump-slave still valid?
Si vous utilisez le vidage tel quel (sans créer un autre esclave avec lui et sans tenter de récupération ponctuelle avec relecture des journaux binaires), alors oui - - dump-slave est OK.
Veuillez garder à l'esprit que si vous lancez un mysqldump à minuit, c'est le point dans le temps du vidage.
Voici un avantage supplémentaire à utiliser - - dump-slave : le mysqldump inclura le fichier journal du maître et se positionnera entre les lignes 23 et 25. De cette façon, si vous souhaitez créer un autre esclave, vous avez le Coordonnées de réplication du maître. Si vous souhaitez tenter une récupération ponctuelle et que vous pouvez toujours récupérer les journaux binaires de l'ancien maître, vous pouvez le faire.