Percona\MySQL бэкапы или как правильно приготовить кошку

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

Это означает количество резервных копий, которые необходимо защитить, будь то локальные или удаленные (внешний файловый сервер, облако). Политика хранения может быть ежедневной, еженедельной или ежемесячной, в зависимости от доступного свободного места.

Какова цель по времени восстановления?

Целевое время восстановления (RTO) относится к количеству времени, которое может пройти во время сбоя, прежде чем оно превысит максимально допустимый порог, указанный в Плане обеспечения непрерывности бизнеса.

Ключевой вопрос, связанный с RTO, заключается в следующем: “Как быстро должны быть восстановлены данные в этой системе?”

Какова цель точки восстановления?

Цель точки восстановления (RPO) - это продолжительность времени и уровень обслуживания, в течение которых бизнес-процесс должен сохраняться после сбоя, чтобы избежать неприемлемых последствий, связанных с нарушением непрерывности.

Ключевой вопрос, связанный с RPO, заключается в следующем: “Сколько данных мы можем потерять?”

Различные типы резервных копий

Существует два типа резервного копирования: физическое и логическое.

    Физические (Percona XtraBackup, моментальные снимки RDS /LVM, резервное копирование MySQL Enterprise), а также вы можете использовать командные строки cp или rsync для копирования datadir, пока mysql отключен / остановлен.

    Логический (mysqldump, mydumper, mysqlpump, mysql shell только для mysql 8)

Также рекомендуется сделать копию файлов binlog, почему? Что ж, это поможет нам восстановиться до последней транзакции.

Зачем нужны резервные копии?

Резервные копии необходимы в случае возникновения множества проблем:

    Сбой хоста: Мы можем получить множество проблем из-за зависших или сломанных дисков. Кроме того, из облачных сервисов наш экземпляр базы данных может быть поврежден, и он недоступен.

    Поврежденные данные: Это может произойти при отключении питания, MySQL не смог правильно записать и закрыть файл, иногда, когда MySQL запускается снова, он не может запуститься из-за поврежденных данных, и процесс аварийного восстановления не может это исправить.

    Несогласованные данные: При ошибке пользователя удалите/обновите ошибочные данные через основной узел или реплику.

    Сбой центра обработки данных: отключение питания или проблемы с интернет-провайдером.

    Законодательство / нормативные акты: обеспечивают неизменную ценность бизнеса и удовлетворенность клиентов.

Теперь позвольте мне объяснить различные типы резервных копий, упомянутые выше, но прежде чем я продолжу, важно настроить новый выделенный узел-реплику для целей резервного копирования из-за высокой загрузки процессора, чтобы избежать каких-либо проблем на любом другом узле-реплике (он же сервер резервного копирования).

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

Это дамп из логической структуры базы данных (инструкции CREATE DATABASE, CREATE TABLE) и содержимого (инструкции INSERT). Это рекомендуется использовать для работы с меньшими объемами данных. Недостатком этого метода является более медленная работа (резервное копирование и восстановление), если сравнивать его с физическими резервными копиями. Используя mydumper, вы можете создавать резервные копии и восстанавливать одну базу данных или одну таблицу, если это необходимо, и это полезно для копирования некоторых данных в другую среду для запуска тестов. Кроме того, mydumper может выполнять последовательное резервное копирование (при условии, что все таблицы находятся на движке InnoDB) и обеспечивает точные позиции главного и ведомого журналов.

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

Логические резервные копии используются для устранения повреждения данных или необходимости восстановления подмножества таблиц.

Физическая (необработанная) резервная копия

Короче говоря, это состоит из точных копий каталогов и файлов базы данных. Это может быть копия для всего или части из каталога MySQL datadir. Этот вид резервного копирования чаще всего используется для легкого и быстрого восстановления или создания новой реплики узла и используется для устранения сбоя узла. Рекомендуется восстановить, используя ту же версию MySQL. Я рекомендую использовать Percona XtraBackup, потому что он может включать любые связанные файлы, такие как файлы конфигурации, такие как cnf config files.

Резервные копии моментальных снимков

Некоторые реализации файловой системы позволяют создавать ”моментальные снимки". Они предоставляют логические копии файловой системы в данный момент времени, не требуя физической копии всей файловой системы. Сам MySQL не предоставляет возможности создания моментальных снимков файловой системы, но это доступно с помощью сторонних решений, таких как LVM или ZFS.

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

Резервные копии двоичных журналов

Резервные копии Binlog специально предназначены для RPO. Двоичные файлы журнала содержат записи о каждом выполненном SQL-запросе, который внес изменения.

Начиная с MySQL 5.6, вы можете использовать mysqlbinlog для потоковой передачи двоичных журналов с удаленного сервера. Вы можете объединить резервные копии binlog с Percona XtraBackup или mydumper backup, чтобы обеспечить восстановление до конца последнего резервного двоичного журнала.

Инкрементное/ дифференциальное резервное копирование

Инкрементная резервная копия - это резервная копия всего, что изменилось с момента последней резервной копии (резервная копия двоичного журнала - это особый случай инкрементной резервной копии). Это очень хороший вариант, если размер набора данных огромен, так как вы можете сделать полную резервную копию в начале недели и выполнять инкрементные резервные копии каждый день. Кроме того, размер резервной копии меньше, чем у полной резервной копии.

Основными рисками, связанными с инкрементным резервным копированием, являются:

– Одна поврежденная инкрементная резервная копия может сделать недействительными все остальные

– Инкрементные резервные копии обычно негативно влияют на RTO

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

Percona XtraBackup поддерживает как инкрементное, так и дифференциальное резервное копирование.

Удаленное хранилище

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

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

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

Шифрование

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

GPG - хороший вариант для шифрования резервных копий, и если вы используете этот вариант или какую-либо другую альтернативу, не забудьте получить копию ключей / парольной фразы. Если вы потеряете его, ваши резервные копии будут бесполезны.

Тестирование восстановления

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

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

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

Требования к хранению

И последнее, но не менее важное: очень важно хранить несколько копий разных типов резервных копий.

Наша лучшая рекомендация - это:

    Одна или две физические резервные копии локально на сервере резервного копирования (если позволяет пространство).

    Семь ежедневных и четыре еженедельных логических резервных копии локально на сервере резервного копирования.

    30 дней резервного копирования binlog локально на сервере резервного копирования.

    Для внешних резервных копий (например, S3, Google Cloud и т.д.) сохраняйте ежемесячные резервные копии в течение одного года или более.

Что касается локальных резервных копий, имейте в виду, что вам потребуется как минимум в 2,5 раза больше текущего размера набора данных в качестве свободного места на диске для сохранения / соблюдения этих политик хранения. Не забудьте зашифровать все типы резервных копий!