19.4.1.2 Backing Up Raw Data from a Replica — MySQL 8.4

19.4.1.2 Архивирование исходных данных с реплики

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

Чтобы остановить сервер и выполнить резервное копирование файлов:

Остановите сервер реплики MySQL:
```
$> mysqladmin shutdown
```
Скопируйте файлы данных. Вы можете использовать любой подходящий инструмент копирования или архивирования, включая cp, tar или WinZip. Например, предполагая, что каталог данных находится в текущем каталоге, вы можете заархивировать весь каталог следующим образом:
```
$> tar cf /tmp/dbbackup.tar ./data
```
Запустите сервер MySQL снова. В Unix-подобных системах:
```
$> mysqld_safe &
```
В Windows:
```
C:\> "C:\Program Files\MySQL\MySQL Server 8.4\bin\mysqld"
```

Обычно вы должны выполнить резервное копирование всего каталога данных для сервера реплики MySQL. Если вы хотите восстановить данные и продолжить работу в качестве реплики (например, в случае сбоя реплики), помимо данных, вам необходимо иметь репозиторий метаданных подключения реплики и репозиторий метаданных исполнителя, а также файлы журналов ретрансляции. Эти элементы необходимы для возобновления репликации после восстановления данных реплики. Предполагая, что для репозитория метаданных подключения реплики и репозитория метаданных исполнителя используются таблицы (см. Раздел 19.2.4, «Журналы пересылки и репозитории метаданных репликации»), что является стандартным по умолчанию в MySQL 8.4, эти таблицы резервируются вместе с каталогом данных. Если для репозиториев использовались файлы, что устарело, вы должны резервировать их отдельно. Файлы журнала ретрансляции должны быть заархивированы отдельно, если они размещены в другом месте по отношению к каталогу данных.

Если вы потеряли журналы ретрансляции, но у вас всё ещё есть файл relay-log.info, вы можете проверить его, чтобы определить, насколько далеко продвинулась репликация SQL-потока в двоичных журналах источника. Затем вы можете использовать CHANGE REPLICATION SOURCE TO с параметрами SOURCE_LOG_FILE и SOURCE_LOG_POS, чтобы сообщить реплике повторно прочитать двоичные журналы с этого момента. Для этого требуется, чтобы двоичные журналы всё ещё существовали на сервере источника.

Если ваша реплика выполняет репликацию инструкций LOAD DATA, вы также должны заархивировать любые файлы SQL_LOAD-*, которые существуют в каталоге, используемом репликой для этой цели. Реплике нужны эти файлы для возобновления репликации любых прерванных операций LOAD DATA. Путь к этому каталогу — значение системной переменной replica_load_tmpdir. Если сервер не запускался с заданным значением этой переменной, путь к каталогу — значение системной переменной tmpdir.