Я делаю ежедневные резервные копии моих баз данных mysql с помощью mysqldump + запланированных задач
но, как я могу читать дальше этот ответ, mysqldump не гарантирует согласованного набора данных ... в чем смысл? Это означает, что если кто-то получит доступ к веб-сайту во время резервного копирования и его действия отредактируют две таблицы, а одна таблица уже проанализирована mysqldump, что приведет к «неполной» резервной копии, которая может привести к проблемам? Если mysqldump не подходит, как лучше всего сделать резервную копию?
Представьте себе две таблицы. Пока вы создаете резервную копию первой, вторая изменяется. В резервную копию будут внесены эти изменения. У вас нет снимка. Это проблема, если, скажем, вы удалили внешний ключ.
Решение состоит в том, чтобы реплицировать подчиненную базу данных, в которую при выполнении резервного копирования вы останавливаете репликацию, выполняете резервное копирование и затем снова запускаете репликацию. Таким образом, у вас есть моментальный снимок вашей базы данных.
Ваш сценарий того, что может сделать несогласованную резервную копию, совершенно верен.
Вы можете использовать mysqldump для создания согласованной резервной копии, добавив флаг --lock-all-tables. Предостережение, как следует из названия, заключается в том, что все таблицы будут заблокированы от записи до завершения резервного копирования. Что в зависимости от размера вашей базы данных может занять много времени и вызвать серьезные сбои.
Есть несколько альтернатив. Некоторые из них коммерческие. Я предполагаю, что вы используете MyISAM, который, как правило, сложнее для последовательного резервного копирования, чем InnoDB.
Одно из решений - поместить данные MySQL в хранилище, что облегчит более быстрое резервное копирование другим методом. Например, блочное устройство SAN или LVM2, поддерживающее моментальные снимки. Вам все равно придется переводить MySQL в заблокированное состояние, но поскольку моментальные снимки занимают очень мало времени, разрушительный эффект незначителен. Затем вы можете запустить другой демон MySQL для моментального снимка данных, если он захочет взять согласованный mysqldump и экспортировать его в другое место на досуге.
Я сам использую аналогичный метод для хранения с поддержкой iSCSI.
mysqldump обычно создает согласованные моментальные снимки (если вы этого не сделаете). Это достигается путем блокировки всего сервера с помощью глобальной блокировки чтения, что в большинстве случаев нежелательно.
Если вы используете исключительно таблицы InnoDB, вы можете использовать дамп транзакции, который также согласован, но ничего не блокирует (надолго).
Если вы используете таблицы InnoDB, есть коммерческий инструмент под названием «горячее резервное копирование», которое создает согласованную резервную копию, пока сервер работает. Я не буду ссылаться на него, так как это коммерческий сайт, но поиск в Google должен открыть его, если вам интересно.
С другими форматами таблиц вы можете получить блокировку чтения для таблиц, а затем скопировать базовые файлы данных, но это заблокирует операции записи в таблицы, поэтому вам придется делать это, когда приложения не полагаются на записи или с приложениями, которые имеют был написан для корректной обработки неудачной записи.
Дополнительная информация в документации MySQL:
http://dev.mysql.com/doc/refman/5.7/en/replication-solutions-backups-rawdata.html