Ошибка импорта данных MySQL с ошибкой 1839

У меня есть настройка главного ведомого MySQL с настроенным GTID. Я забрал резервную копию данных мастера и импортировал ее на отдельный тестовый сервер. Не удается импортировать как

ОШИБКА 1839 (HY000) в строке 24: @@GLOBAL.GTID_PURGED может быть установлена ​​только в том случае, если @@GLOBAL.GTID_MODE = ON. Я попытался с --set-gtid-purged=OFF и AUTO, но безуспешно.

Источник

1 ответ

Решение

Если вы запускаете

SHOW MASTER STATUS\G

вы увидите что-то вроде этого:

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)

Поскольку при включенном GTID все серверы получили свой UUID, и есть транзакции. Я полагаю, вы создали дамп с помощью mysqldump, и если вы посмотрите на начало этого файла, вы найдете нечто похожее на это:

--
-- 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';

Это команда, которая не может быть выполнена.

У вас есть следующие варианты:

  • Удалите эту команду из файла дампа mysql. Просто удалите это. Все вставки появятся на ведомом устройстве, так как это локальные транзакции

  • Если вы хотите предотвратить это, вы также можете сбросить мастер на подчиненном

    mysql> RESET MASTER;

    Эта команда очистит переменную "Executed_Gtid_Set" на ведомом устройстве, поэтому вы можете импортировать файл дампа напрямую, а ранее упомянутая переменная set_global_gtid_purged выполняет действие

  • Когда вы создаете mysqldump, вы можете пропустить часть настройки GTID, добавив

    --set-GTID-продувают = OFF

параметр для mysqldump.

НОТА:

если подмножество GTID отличается на master между master и slave (если вы хотите использовать это в настройке репликации), то репликация не будет работать, я бы рекомендовал двоичный дамп и восстановление, так как GTID подчиненного устройства точно соответствует master.

С GTID появляется много новых проблем, но ваша настройка реплики будет более последовательной. С этим стоит работать.

Источник

Если вы похожи на меня и не хотите перезапускать свой дамп, потому что это была очень долгая операция, вы можете просто удалить эти строки по факту.

find . -name '*.sql' -type f -exec perl -0 -i.bak -pe 's/SET \@\@GLOBAL\.GTID_PURGED=\x27.*?\x27;//gs' {} +

Запустите это в папке с вашими файлами.sql. Это сохранит старую версию как.bak.

Это сработало для меня.

Источник

У меня огромная база данных, поэтому, как и у @Goddard, у меня есть резервная копия / дамп, разбросанный по нескольким файлам. У меня мало места на диске, поэтому я экспортирую дамп в сжатом формате (т.е. .sql.gz). Решение @ Goddard мне нравится, но, поскольку у меня мало места на диске, я не могу позволить себе извлечь эти файлы в.sql, а затем применить изменения. Вместо этого я выполню следующую адаптацию ответа @Goddard для импорта .sql.gz файлы, удаляя запрос 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"
done
Источник
Другие вопросы по тегам