mysqldump - одиночная транзакция на ведомом (без остановки репликации)
Можно ли бежать? mysqldump --single-transaction на подчиненной БД без остановки репликации (stop slave;)? Это для регулярного ежедневного резервного копирования, поэтому мы можем восстановить основную базу данных в случае сбоя хранилища. Большинство таблиц - InnoDB, только несколько из них - MyISAM.
Официальная документация гласит, что:
"Перед началом процесса дампа следует остановить репликацию на ведомом устройстве, чтобы в нем содержался согласованный набор данных".
Что это значит consistent data? Значит ли это как последние данные?
я знаю --single-transaction означает, что данные берутся с момента его публикации, поэтому новые дальнейшие изменения во время выполнения дампа не будут записываться в дамп. Я прав?
Не хотите запускать резервное копирование на главном компьютере из-за задержки, которую он создает в нашем приложении.
1 ответ
TL;DR - Вам на самом деле не нужно выдавать stop slave при работе с резервной копией на реплике. Если вы бежите mysqldump используя значения по умолчанию и пропустить --single-transactionпо умолчанию будет использоваться блокирующая резервная копия, которая автоматически блокирует любые изменения в базе данных во время резервного копирования; сохраняя ваши данные согласованными. Обычно это означает задержку репликации, но она возобновится сама по себе после завершения резервного копирования.
MySQL - это реляционная база данных, это означает, что данные в одной таблице могут иметь связь с данными, содержащимися в другой таблице. Например, если вы принимаете онлайн-заказы, у вас может быть line_items таблица, в которой одна или несколько строк принадлежат записи orders таблица, которая в свою очередь может иметь одну или несколько строк, принадлежащих записи users Таблица.
MyISAM - это механизм хранения без транзакций, что означает, что его данные будут изменены во время резервного копирования независимо от --single-transaction вариант. Взяв пример из предыдущего, давайте представим, что line_items это MyISAM. Вы запускаете резервное копирование, и один из ваших пользователей отправляет заказ во время резервного копирования.
update users set last_ordered_at=now() where id=306;
insert into orders (user_id, created_at, ...) values (306, now(), ...);
insert into line_items (order_id, product_id, ...) values (1021992, 10509, ...);
Если резервная копия не прочитала line_items Таблица до этого запускается, и вы выполняете восстановление в результате:
- Максимальный идентификатор таблицы заказов сбрасывается до значения ниже
1021992Таким образом, запись line_items на данный момент осиротела. last_ordered_atизменение потеряно- Когда добавляются дополнительные заказы, и order_id получает
1021992этот порядок волшебным образом добавит эту запись line_item (если на этом уровне нет дополнительных фильтров). Эта проблема будет рассматриваться с любымline_itemsдобавлено до того, как резервная копия достигнет этой таблицы. - Кошки и собаки живут вместе... массовая истерия.
Если ваши данные MyISAM статичны / неизменны, используйте --single-transaction не будет проблемой, и ваши данные останутся непротиворечивыми. Имейте в виду, хотя, то, что это сейчас статично, не означает, что так будет всегда.
Если ваши данные MyISAM относятся исключительно к другим данным MyISAM, но не к транзакционным данным, вы можете переместить данные MyISAM в отдельную схему, чтобы при резервном копировании вы могли обрабатывать их иначе, чем транзакционные данные.
Начиная с MySQL 5.6, InnoDB поддерживает полнотекстовые индексы, поэтому для таблиц MyISAM практически не осталось использования. Вы можете подумать о преобразовании их в InnoDB с помощью выражения вроде alter table [tablename] engine=innodb;, Как и с любым изменением, вы должны оценить это в разработке / UAT, прежде чем переходить к производству. Чтобы создать все операторы alter одновременно, вы можете использовать:
select concat('alter table ', table_schema, '.', table_name, ' engine=innodb;') from information_schema.tables where engine='MyISAM' and table_schema not in ('mysql','information_schema','performance_schema');
InnoDB использует в 2-3 раза больше физического пространства, чем MyISAM, и эти таблицы будут заблокированы от записи при их изменении; Вы хотите запланировать свое преобразование соответственно. По завершении вы, вероятно, захотите просмотреть конфигурацию вашего сервера и настроить ее в большей степени на InnoDB.
Одно предостережение об использовании 100% транзакционных таблиц с --single-transaction в том, что если вы выполняете DDL (CREATE, DROP, ALTER) во время резервного копирования, это не операторы транзакций и обычно приводит к сбою резервного копирования. Обычно это крайний случай, который можно устранить с помощью мониторинга резервных копий.