В чем смысл последовательного набора данных? (Баз данных)
Я делаю ежедневные резервные копии моих баз данных mysql с запланированными задачами mysqldump+
но, как я могу прочитать в этом ответе, mysqldump не гарантирует согласованный набор данных... в чем смысл? Это означает, что если кто-то получит доступ к веб-сайту, пока я выполняю резервное копирование, и его действия отредактируют две таблицы, и одна таблица уже проанализирована mysqldump, что приведет к "неполному" резервному копированию, которое может привести к проблемам? Если mysqldump не подходит, каков наилучший способ сделать резервную копию?
4 ответа
Ваш сценарий того, что может сделать противоречивую резервную копию, абсолютно верен.
Вы можете использовать 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