В настоящее время я изучаю решение для резервного копирования mysql для реализации на некоторых производственных серверах.
Прочитав некоторое время, я пришел к выводу, что лучшим решением является реализация репликации mysql с использованием методологии master / slave.
Честно говоря, учитывая мои реальные потребности, это может быть немного излишним, раз уж простого дампа базы данных будет достаточно.
Итак, я попробую реализовать решение для резервного копирования через rsync и mysqldump.
Если размер базы данных не слишком велик (ibdata1 большего размера имеет 42 МБ, что является довольно быстрым выполнением команды mysqldump, создавая файл дампа размером 6,7 МБ), а доступ к базе данных значительно сокращается, было бы достаточно безопасно использовать mysqldump в рабочий период, с возможностью -один-транзакция?
При таком подходе можно было бы настроить задачу cron на выполнение 2-3 дампов в течение дня? Если я прав, то -один-транзакция использование опции обеспечивает некоторую целостность данных.
Заранее благодарю за помощь, С уважением
Мне трудно сказать, не зная: шаблон доступа вашего сайта с БД, трафик БД или насколько большой вы ожидаете получить БД. Если у вас все в порядке с какой-либо блокировкой, я говорю, сделайте это.
Я нахожусь в среде, где любая блокировка сверх обычного использования неприемлема, а наши БД составляют около 750 ГБ. Мы делаем снимок LVM, а затем запускаем mysqldump из этого снимка. Конечно, мы получаем некоторое снижение производительности во время моментального снимка, но это лучше, чем полная блокировка таблиц.
Для таблиц InnoDB --single-transaction гарантирует, что дамп каждой таблицы согласован, но он не обязательно будет согласован с другими таблицами, поскольку он блокирует и выгружает их по одной, а не блокирует их все на время. свалки. И у вас, конечно же, будет отложенная запись в ожидании снятия блокировки, если вы попытаетесь записать в таблицу, пока она выгружается.
Лучше использовать LVM или файловую систему, которая позволяет вам делать снимки, а затем блокировать всю базу данных ровно на время, достаточное для создания снимка, который затем можно создать резервную копию на досуге.
Mysqldump блокирует резервную копию БД, поэтому вам следует подумать об использовании инструмента резервного копирования в реальном времени, например xtrabackup. Вам нужно будет использовать сборку MySQL от Percona и преобразовать все ваши таблицы в InnoDB. Последний плагин InnoDB от Oracle также поддерживает резервное копирование в реальном времени, не может вспомнить название своего инструмента резервного копирования в реальном времени.
Я думаю, что репликация mysql - хороший вариант. Mysql создает новые журналы после фиксации транзакции. Таким образом, у вас будут стабильные резервные копии, если вы правильно используете транзакции.
Одна полная резервная копия в начале, а затем вы можете получить сгенерированные двоичные журналы системой репликации. Всегда применяемый двоичный файл журнала должен согласованно обновлять базу данных.
Этим всегда можно воспользоваться. Однако использование снимков системы может оказаться невозможным, поскольку это связано с используемой файловой системой.