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