Действительно ли безопасно уничтожить процесс MySQL тиражирования, который 'копирует в tmp таблицу'?
У меня есть проблема на основном MySQL (5.0, Linux) сервер: Я пытался добавить комментарий к строке таблицы, которая переводит в команду ALTER TABLE. Теперь процесс застревает на 'копии к tmp таблице', копируя 100'000'000 + строки. Дисковое IO использование неприятно высоко.
Так как ведущее устройство использует репликацию, я не уверен, если я могу уничтожить этот процесс. Ведомые устройства еще не видели команду ALTER TABLE.
(Чтобы ясно дать понять это: я говорю об уничтожении процесса от MySQL-PROCESSLIST, не самого Процесса демона MySQL.)
3 ответа
Да, вы можете убить его - ALTER не попадет в бинлоги, пока транзакция не будет зафиксирована, то есть пока ALTER не завершится. Таким образом, ведомые устройства не увидят и не выполнят его, а ведущее устройство вернется к старой структуре таблицы.
Вы можете легко убедиться, что ALTER еще нет в двоичных журналах, используя show binlog events или утилиту mysqlbinlog .
Нет, это не безопасно. Только если у вас есть полное резервное копирование (недавно) базы данных, чтобы восстановить в случае проблемы. Там могут быть некоторые замки, и вы заканчиваете после этого с заблокированными таблицами, возможным повреждением на клавишах.
Как совет, если вы добавляете новые столбцы для такой большой базы данных. Проще
- создать копирование таблицы схемы
- . Запустите изменение в этой таблице, когда она пуста,
- заполнится от оригинала с помощью вставки в ... () Выбор поля из ...
Это намного быстрее. Тогда явно переименуйте таблицу на оригинал.
Можно убить операцию, но могут произойти две вещи:
- схема ведомого не совместима с хозяином (и поэтому:)
- репликация на ведомых может прекратиться.
Когда репликация прекращается, вы можете попытаться вручную исправить ведомое устройство, пропустив инструкцию 'alter table', введя на ведомом сервере:
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;