J'ai une configuration maître-esclave de MySQL avec GTID configuré. J'ai repris la sauvegarde des données du maître et je l'ai importée sur un serveur de test individuel. L'importation échoue car
ERROR 1839 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_MODE = ON
J'ai essayé avec --set-gtid-purged=OFF と AUTO mais sans succès.
Si vous exécutez un
SHOW MASTER STATUS\Gvous verrez quelque chose comme ceci :
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000299
Position: 780437462
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616637650,
e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642
1 row in set (0.00 sec)En effet, lorsque le GTID est activé, tous les serveurs ont leur propre uuid et il y a des transactions. Je suppose que vous avez créé le dump avec mysqldump, et si vous regardez au début de ce fichier, vous trouverez quelque chose de similaire à ceci :
--
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='075d81d6-8d7f-11e3-9d88-b4b52f517ce4:1-616648986,
e907792a-8417-11e3-a037-b4b52f51dbf8:1-25385296642';Il s'agit de la commande qui ne peut pas être exécutée.
Vous disposez des options suivantes :
Supprimer cette commande du fichier mysql dump. Il suffit de la supprimer. Toutes les insertions apparaîtront sur l'esclave comme des transactions locales.
Pour éviter cela, vous pouvez également réinitialiser le maître sur l'esclave.
mysql> RESET MASTER;
Cette commande nettoie la variable 'Executed_Gtid_Set' sur l'esclave, afin que vous puissiez importer le fichier dump directement, et que la variable set_global_gtid_purged mentionnée précédemment prenne effet.
Lorsque vous créez le mysqldump, vous pouvez ignorer la partie relative à la configuration du GTID, car l'ajout de l'élément --set-gtid-purged=OFF pour mysqldump.
NOTE :
Si le sous-ensemble GTID diffère entre le maître et l'esclave (si vous voulez l'utiliser dans une configuration de réplication), alors la réplication ne fonctionnera pas. Je recommanderais un dump binaire et une restauration, en réglant le GTID de l'esclave exactement sur celui du maître.
Avec le GTID, de nombreux nouveaux problèmes apparaissent, mais votre configuration de réplique sera plus cohérente. Cela vaut la peine d'y travailler.
Si vous êtes comme moi et que vous ne voulez pas réexécuter votre vidage parce que l'opération a été très longue, vous pouvez simplement supprimer ces lignes après coup.
find . -name '*.sql' -type f -exec perl -0 -i.bak -pe 's/SET \@\@GLOBAL\.GTID_PURGED=\x27.*?\x27;//gs' {} +Exécutez ce programme dans le dossier contenant vos fichiers .sql. Il sauvegardera l'ancienne version au format .bak.
Cela a fonctionné pour moi.
J'ai une énorme base de données, donc, comme @Goddard, j'ai une sauvegarde/décharge répartie sur plusieurs fichiers. J'ai peu d'espace disque, donc j'exporte mon dump en format compressé (i.e.., .sql.gz ). La solution de @Goddard m'intéresse, mais comme j'ai peu d'espace disque, je ne peux pas me permettre d'utiliser cette solution, je ne peux pas me permettre d'extraire ces fichiers en .sql puis d'appliquer les changements. Au lieu de cela, je vais exécuter l'adaptation suivante de la réponse de @Goddard pour importer .sql.gz en supprimant au fur et à mesure la requête GTID.
find "$DIR" -name "*.sql.gz" | while read table
do
echo "$table"
zcat "$table" | perl -pe 's/SET \@\@GLOBAL\.GTID_PURGED=\x27.*?\x27;//gs' | \
mysql -h "$HOST" -u "$USER" -p"$PASS" -P "$PORT" "$DB"
doneSystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
