У меня есть база данных MySQL 5.5 с тысячами таблиц и большой нагрузкой на запись.
Мне нужно использовать xtrabackup для онлайн-резервного копирования (создать ведомое устройство с рабочего сервера с минимальным временем простоя), но проблема в том, что последний этап резервного копирования (когда он выдает FLUSH TABLES WITH READ LOCK) занимает очень много времени. Я подозреваю, что это потому, что он копирует тысячи файлов определений таблиц frm. Могу ли я каким-либо образом ускорить этот процесс? Например, если я точно знаю, что структура таблицы не меняется?
Также я видел, что в innobackupex есть опция под названием --rsync, которая предположительно должна помочь, но innobackupex сейчас устарела, а в xtrabackup по какой-то причине эта опция отсутствует.
Любая помощь по сокращению периода, в течение которого действует ПРОМЫВКА ТАБЛИЦ С БЛОКИРОВКОЙ ЧТЕНИЯ, будет оценена по достоинству.
Используйте параметр --rsync.
Удивительно, но это Доступен на xtrabackup, несмотря на то, что он нигде не появляется в документации Percona XtraBackup 2.4 на момент написания этой статьи. Документация неверна. знак равно
Если вы передадите параметр команде xtrabackup, она будет работать так же, как и с innobackupex. И это имеет смысл, поскольку innobackupex теперь является просто символической ссылкой «вызывающего абонента».
Я видел в вашем собственном ответе, что вы «отступили» от использования innobackupex. Я бы не рекомендовал этого, поскольку, согласно документации:
Начиная с Percona XtraBackup версии 2.3 innobackupex был переписан на C и настроен как символическая ссылка на xtrabackup. innobackupex поддерживает все функции и синтаксис, как и версия 2.2, но теперь она устарела и будет удалена в следующем основном выпуске. Синтаксис для новых функций не будет добавлен в innobackupex, только в xtrabackup.
Это является уже устаревший и отсутствуют новые функции, доступные в xtrabackup.
Например. "--databases-exclude"
В моем сценарии резервные копии тратили 6 минут в LOCK TABLES:
180824 14:52:53 Выполнение FLUSH NO_WRITE_TO_BINLOG TABLES ...
180824 14:52:53 Выполнение FLUSH TABLES С БЛОКИРОВКОЙ ЧТЕНИЯ ...
(...)
180824 14:58:55 Запуск UNLOCK TABLES
180824 14:58:55 Все столы разблокированы
А с --rsync стало меньше секунды.
180824 13:07:28 Выполнение FLUSH NO_WRITE_TO_BINLOG TABLES ...
180824 13:07:28 Выполнение FLUSH TABLES С БЛОКИРОВКОЙ ЧТЕНИЯ ...
180824 13:07:28 Начало резервного копирования таблиц и файлов, отличных от InnoDB
180824 13:07:28 Запуск rsync как: rsync -t. --файлы-
(...)
180824 13:07:28 Выполнение РАЗБЛОКИРОВКИ ТАБЛИЦ
180824 13:07:28 Все столы разблокированы
У меня была та же проблема, что и у вас, и я нашел ваш вопрос и ответ, которые вместе с отсутствием согласованной документации заставили меня поверить, что она недоступна, и в итоге я потратил день на поиск альтернативных решений, поскольку innobackupex устарел и не имеет некоторых необходимых мне функций, таких как вышеупомянутый --databases-exclude.
Публикация этого ответа, чтобы, если кто-то еще столкнется с такой же проблемой, они будут знать, что могут использовать параметр, даже если его нет в документации.
Отвечаем для потомков. Innobackupex с --rsync сделали свое дело. Это сократило время блокировки до секунд.
Eсть --no-lock вариант, однако вы можете использовать его только в том случае, если у вас нет доступных для записи таблиц, отличных от InnoDB и если вас не волнует позиция binlog.
Если вы не можете использовать --no-lock Я бы посоветовал настроить реплику и делать с нее резервные копии.
Кстати, --rsync все равно здесь не поможет.