19.4.1.2 Backing Up Raw Data from a Replica — MySQL 9.2

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 9.2\bin\mysqld"
```

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

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

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