Это нормально бежать? mysqldump --single-transaction на Slave БД без остановки репликации (stop slave;)? Это для регулярного ежедневного резервного копирования, чтобы мы могли восстановить основную базу данных в случае сбоя хранилища. Большинство таблиц - это InnoDB, только пара из них - MyISAM.
Официальная документация говорит, что:
«Вы должны остановить репликацию на ведомом устройстве перед запуском процесса дампа, чтобы убедиться, что он содержит согласованный набор данных».
Что это означает consistent data? Означает ли это, как последние данные?
Я знаю --single-transaction означает, что он берет данные с момента их выпуска, поэтому новые дальнейшие изменения во время выполнения дампа будут не записываться в дамп. Я прав?
Не хочу запускать резервное копирование на главном сервере из-за задержки, которую он создает в нашем приложении.
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 изменение потеряно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) во время резервного копирования, это не транзакционные операторы и обычно приводит к сбою выполнения резервного копирования. Обычно это крайний случай, который можно решить с помощью мониторинга резервного копирования.