Основные стратегии резервного копирования MySQL: выбор правильного подхода для ваших данных

Ваша стратегия резервного копирования MySQL хороша только в том случае, если вы можете восстановиться из нее под давлением. Дамп-файл, снимок файловой системы и физическое резервное копирование решают разные проблемы восстановления, поэтому правильный выбор зависит от размера ваших данных, допустимого времени простоя и того, сколько данных вы можете позволить себе потерять.

Почему резервные копии MySQL требуют плана восстановления

Резервные копии защищают вас не только от отказа диска. Они также помогают восстановиться после ошибок приложений, неудачных развертываний, случайных удалений, программ-вымогателей и региональных сбоев.

Начните с двух целей:

• RTO: Как долго база данных может быть недоступна во время восстановления?
• RPO: Сколько недавних данных вы можете потерять?

Например, небольшая внутренняя вики может допускать ночной mysqldump и часовое восстановление. Производственная система заказов может нуждаться в физических резервных копиях плюс бинарные журналы, чтобы вы могли восстановиться до определенной секунды перед неудачным DELETE.

Логические резервные копии с mysqldump

Логические резервные копии экспортируют схему и данные в виде SQL. Они переносимы и легко проверяются, но могут быть медленными при создании и еще медленнее при восстановлении на больших базах данных.

Резервное копирование одной базы данных:

mysqldump -u your_username -p your_database_name > backup_file.sql

Резервное копирование всех баз данных:

mysqldump -u your_username -p --all-databases > all_databases_backup.sql

Резервное копирование конкретных таблиц:

mysqldump -u your_username -p your_database_name table1 table2 > specific_tables_backup.sql

Включайте процедуры, события и триггеры, если ваша схема от них зависит. Триггеры включаются по умолчанию в типичном использовании mysqldump, но явное указание намерения в вашем сценарии резервного копирования помогает рецензентам заметить это.

mysqldump -u your_username -p --routines --events --triggers your_database_name > database_with_programs.sql

Восстановление в существующую базу данных:

mysql -u your_username -p your_database_name < backup_file.sql

Для рабочих нагрузок с интенсивным использованием InnoDB добавьте --single-transaction, чтобы дамп читал согласованный снимок без длительных блокировок таблиц:

mysqldump -u your_username -p --single-transaction --routines --events your_database_name | gzip > backup_file.sql.gz

Избегайте использования --single-transaction в качестве единственной защиты согласованности, если вы полагаетесь на нетранзакционные таблицы, такие как MyISAM. Для этих таблиц требуется другой план блокировок или снимков.

Физические резервные копии для больших баз данных

Физические резервные копии копируют файлы данных MySQL вместо восстановления базы данных в виде SQL. Они обычно лучше подходят для больших наборов данных, так как время восстановления близко к копированию файлов обратно и применению журналов восстановления.

Общие варианты включают:

• Снимки файловой системы или облачных томов, скоординированные так, чтобы данные MySQL были согласованы на уровне сбоя или приложения.
• Percona XtraBackup, широко используемый инструмент с открытым исходным кодом для горячего физического резервного копирования данных InnoDB, совместимых с MySQL.
• MySQL Enterprise Backup, коммерческий инструмент резервного копирования Oracle для развертываний MySQL Enterprise.

Создание полной резервной копии с XtraBackup:

xtrabackup --backup --target-dir=/path/to/backup/full --user=your_username --password=your_password

Подготовка резервной копии перед восстановлением:

xtrabackup --prepare --target-dir=/path/to/backup/full

Восстановление после остановки MySQL и перемещения старого каталога данных:

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.before-restore
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/path/to/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

Этот пример предполагает имя службы и каталог данных в стиле Debian. Проверьте документацию вашего пакета, образа контейнера или управляемой базы данных перед выполнением команд восстановления.

Бинарные журналы и восстановление на момент времени

Резервные копии показывают, откуда вы можете восстановиться. Бинарные журналы помогают воспроизвести изменения после этой резервной копии, что необходимо для восстановления на момент времени.

Включите бинарное журналирование на самостоятельно управляемом MySQL с помощью соответствующей настройки log_bin для вашей версии и упаковки. Затем сохраняйте резервные копии бинарных журналов отдельно от сервера базы данных.

При восстановлении вы обычно:

1. Восстанавливаете последнюю хорошую полную или инкрементальную резервную копию.
2. Используете mysqlbinlog для воспроизведения бинарных журналов до целевого времени или позиции.
3. Останавливаетесь перед ошибочным оператором, если восстанавливаетесь после ошибки оператора.

Выбор правильной стратегии резервного копирования

Используйте простое правило принятия решений:

• Небольшие базы данных: начните с автоматизированного mysqldump, сжатия, внешнего хранения и регулярных тестов восстановления.
• Средние базы данных: добавьте резервные копии бинарных журналов, чтобы можно было восстановиться до определенного момента времени.
• Большие или критически важные базы данных: используйте физические резервные копии, инкрементальные резервные копии (где поддерживаются), бинарные журналы, мониторинг и документированную тренировку восстановления.

Не выбирайте только по скорости резервного копирования. Скорость восстановления важнее во время инцидента.

Практики резервного копирования, которые действительно имеют значение

Автоматизируйте задачу резервного копирования, но тестируйте восстановление вручную, пока процесс не станет рутинным. Храните резервные копии вне сайта, шифруйте конфиденциальные резервные копии, отслеживайте сбои заданий и сохраняйте срок хранения достаточно долгим, чтобы обнаружить скрытое повреждение или случайные удаления, обнаруженные через несколько дней.

Также задокументируйте точный порядок восстановления. Во время реального сбоя ваше будущее "я" не должно гадать, какая полная резервная копия, инкрементальная резервная копия и диапазон бинарных журналов относятся друг к другу.

Вывод

Выберите метод резервного копирования, который соответствует вашей цели восстановления. mysqldump подходит для небольших баз данных и переносимого восстановления. Физические резервные копии подходят для больших систем. Бинарные журналы закрывают пробел, когда требуется восстановление на момент времени. Что бы вы ни выбрали, резервная копия не считается действительной, пока вы не восстановите ее успешно в тестовой среде.