mysqldump --single-transaction on slave (без остановки репликации)
Можно ли запускать mysqldump --single-transaction в подчиненной базе данных без остановки репликации (stop slave;)? Это для регулярного ежедневного резервного копирования, чтобы мы могли восстановить Master DB в случае аварии хранилища. Большинство таблиц являются InnoDB, только пара из них - MyISAM.
В официальной документации говорится, что:
"Вы должны остановить репликацию на ведомом ведомом цикле перед запуском дампа обеспечить, чтобы дамп содержал согласованный набор данных».
Что это значит согласованные данные? Означает ли это, что последние данные?
Я знаю,что - одна транзакция означает, что она берет данные с момента ее выпуска,таким образом, новые дальнейшие изменения во время дампа будут записаны not в дамп. Я прав?
Не хочу запускать резервное копирование на master из-за задержки, которую она создает в нашем приложении.
TL; DR - Вам действительно не нужно выдавать остановить ведомое устройство при работе с резервной копией на реплике. Если вы запустите mysqldump по умолчанию и не укажете - одиночная транзакция , по умолчанию будет использоваться блокирующая резервная копия, которая автоматически блокирует любые изменения в базе данных во время резервного копирования; согласованность ваших данных. Обычно это означает задержку репликации, но она возобновится сама по себе по завершении резервного копирования.
MySQL - это реляционная база данных, это означает, что данные в одной таблице могут иметь связь с данными, содержащимися в другой таблице. Например, если вы принимаете онлайн-заказы, у вас может быть таблица line_items , в которой одна или несколько строк принадлежат записи таблицы orders , которая, в свою очередь, может иметь одну или несколько строки, принадлежащие записи таблицы пользователей .
MyISAM - это нетранзакционный механизм хранения, что означает, что его данные могут изменяться во время резервного копирования независимо от - single- опцион транзакции . Взяв предыдущий пример, давайте представим, что line_items - это MyISAM. Вы запускаете резервное копирование, и один из ваших пользователей отправляет заказ, пока выполняется резервное копирование.
update users set last_ordered_at = now (), где id = 306;
вставлять в заказы (user_id, created_at, ...) значения (306, now (), ...);
вставить в значения line_items (order_id, product_id, ...) (1021992, 10509, ...);
Если резервная копия не считала таблицу line_items перед запуском, и вы выполняете восстановление результат:
- Максимальный идентификатор таблицы заказов сбрасывается до значения ниже, чем
1021992, поэтому запись line_items на данный момент осиротела. - Изменение
last_ordered_atтеряется - Когда добавляются дополнительные заказы, и order_id становится равным
1021992, этот заказ волшебным образом получит эту запись line_item, добавленную к нему (если на этом уровне нет дополнительных фильтров). Эта проблема может быть замечена с любымиline_items, добавленными до того, как резервная копия достигнет этой таблицы. - Кошки и собаки, живущие вместе ... массовая истерия.
Если ваши данные MyISAM статичны / неизменны, тогда использование - разовая транзакция не будет проблемой, и ваши данные останутся согласованными. Однако имейте в виду, что тот факт, что сейчас он статичен, не означает, что так будет всегда.
Если ваши данные 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, где engine = 'MyISAM' и table_schema не в ('mysql', 'information_schema', 'performance_schema');
InnoDB использует примерно в 2-3 раза больше физического пространства, чем MyISAM, и эти таблицы будут заблокированы от записи при их изменении; вы захотите соответствующим образом спланировать конверсию. По завершении вы, вероятно, захотите просмотреть конфигурацию своего сервера и настроить его больше для InnoDB.
Единственное предостережение для использования 100% транзакционных таблиц с - одиночная транзакция заключается в том, что если вы запустите DDL (CREATE, DROP, ALTER) во время резервного копирования это не транзакционные операторы и обычно приводят к сбою выполнения резервного копирования.Обычно это крайний случай, который можно решить с помощью мониторинга резервного копирования.