19.1.2.5 Choosing a Method for Data Snapshots — MySQL 9.2

19.1.2.5 Выбор метода для создания снимков данных

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

Для выбора подходящего метода выгрузки базы данных выберите один из этих вариантов:

Используйте инструмент mysqldump для создания выгрузки всех баз данных, которые вы хотите реплицировать. Это рекомендуемый метод, особенно при использовании InnoDB.
Если ваша база данных хранится в бинарных портативных файлах, вы можете скопировать файлы исходных данных на репликатор. Это может быть более эффективно, чем использование mysqldump и импорта файла на каждый репликатор, потому что это пропускает накладные расходы на обновление индексов, поскольку INSERT-запросы переигрываются. С такими движками хранения, как InnoDB это не рекомендуется.
Используйте плагин MySQL Server для клонирования, чтобы перенести все данные с существующего репликатора на клон. Инструкции по использованию этого метода см. в разделе 7.6.7.7, «Клонирование для репликации».

Подсказка

Для развертывания нескольких экземпляров MySQL можно использовать , что позволяет легко администрировать группу экземпляров MySQL-серверов в . InnoDB Cluster оборачивает MySQL Group Replication в программной среде, что позволяет легко развернуть кластер экземпляров MySQL для достижения высокой доступности. Кроме того, InnoDB Cluster беспрепятственно взаимодействует с , что позволяет вашим приложениям подключаться к кластеру без написания собственного процесса переключения. Однако для аналогичных задач, которые не требуют высокой доступности, можно использовать . Инструкции по установке MySQL Shell можно найти .

19.1.2.5.1 Создание снимка данных с помощью mysqldump

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

Следующий пример выгружает все базы данных в файл с именем dbdump.db и включает опцию --source-data, которая автоматически добавляет инструкцию CHANGE REPLICATION SOURCE TO, необходимую на репликаторе для запуска процесса репликации:

$> mysqldump --all-databases --source-data > dbdump.db

Примечание

Если вы не используете --source-data, то необходимо заблокировать все таблицы в отдельной сессии вручную. См. раздел 19.1.2.4, «Получение координат двоичного журнала репликации источника».

Можно исключить определенные базы данных из выгрузки с помощью инструмента mysqldump. Если вы хотите выбрать базы данных, которые следует включить в выгрузку, не используйте --all-databases. Выберите один из этих вариантов:

Исключите все таблицы в базе данных, используя опцию --ignore-table.
Укажите только те базы данных, которые необходимо выгрузить, используя опцию --databases.

Примечание

По умолчанию, если на источнике используются GTID (gtid_mode=ON), mysqldump включает GTID из набора gtid_executed на источнике в выходные данные выгрузки, чтобы добавить их в набор gtid_purged на репликаторе. Если вы выгружаете только определенные базы данных или таблицы, важно отметить, что значение, включаемое mysqldump, включает GTID всех транзакций в наборе gtid_executed на источнике, даже тех, которые изменили подавленные части базы данных или другие базы данных на сервере, которые не были включены в частичную выгрузку. Обратитесь к описанию опции --set-gtid-purged mysqldump, чтобы узнать о последствиях по умолчанию для используемых версий MySQL Server и как изменить поведение, если это поведение не подходит для вашей ситуации.

Дополнительную информацию см. в разделе 6.5.4, «mysqldump — Программа резервного копирования базы данных».

Для импорта данных скопируйте файл выгрузки на репликатор или получите доступ к файлу из источника при удаленном подключении к репликатору.

19.1.2.5.2 Создание моментальной копии данных с использованием файлов исходных данных

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

Если вы используете таблицы InnoDB, вы можете использовать команду mysqlbackup из компонента MySQL Enterprise Backup для создания согласованной моментальной копии. Эта команда записывает имя и смещение журнала, соответствующие моментальной копии, для использования на реплике. MySQL Enterprise Backup — это коммерческий продукт, который входит в состав подписки MySQL Enterprise. Подробную информацию см. в Разделе 32.1, «Обзор MySQL Enterprise Backup».

Этот метод также не работает надежно, если у источника и реплики разные значения для ft_stopword_file, ft_min_word_len или ft_max_word_len, и вы копируете таблицы с полными текстовыми индексами.

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

Для создания моментальной копии исходных данных таблиц MyISAM, когда файлы данных MySQL находятся на одном файловой системе, вы можете использовать стандартные инструменты копирования файлов, такие как cp или copy, инструмент для удалённого копирования, такой как scp или rsync, инструмент архивирования, такой как zip или tar, или инструмент для создания моментальных снимков файловой системы, такой как dump. Если вы реплицируете только определённые базы данных, скопируйте только те файлы, которые относятся к этим таблицам. В случае InnoDB, все таблицы всех баз данных хранятся в

$> mysqladmin shutdown

файлах, если не включена опция innodb_file_per_table.

Следующие файлы не требуются для репликации:

Файлы, относящиеся к базе данных mysql.
Файл репозитория метаданных подключения реплики master.info, если используется; использование этого файла теперь устарело (см. Раздел 19.2.4, «Журнал ретрансляции и репозитории метаданных репликации»).
Файлы двоичного журнала источника, за исключением файла индекса двоичного журнала, если вы собираетесь использовать его для определения координат двоичного журнала источника для реплики.
Любые файлы журнала ретрансляции.

В зависимости от того, используете ли вы InnoDB таблицы или нет, выберите один из следующих вариантов:

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

Получите блокировку на чтение и получите состояние источника. См. Раздел 19.1.2.4, «Получение координат двоичного журнала источника репликации».
В отдельной сессии выключите сервер источника:
```
$> mysqladmin shutdown
```
Создайте копию файлов данных MySQL. Ниже приведены распространённые способы сделать это. Вам нужно выбрать только один из них:
```
$> tar cf /tmp/db.tar ./data
$> zip -r /tmp/db.zip ./data
$> rsync --recursive ./data /tmp/dbdata
```
Перезапустите сервер источника.

Если вы не используете InnoDB таблицы, вы можете получить моментальный снимок системы с источника, не останавливая сервер, как описано в следующих шагах:

Получите блокировку на чтение и получите состояние источника. См. Раздел 19.1.2.4, «Получение координат двоичного журнала источника репликации».
Создайте копию файлов данных MySQL. Ниже приведены распространённые способы сделать это. Вам нужно выбрать только один из них:
```
$> tar cf /tmp/db.tar ./data
$> zip -r /tmp/db.zip ./data
$> rsync --recursive ./data /tmp/dbdata
```
В клиенте, где вы получили блокировку на чтение, освободите блокировку:
```
mysql> UNLOCK TABLES;
```

После создания архива или копии базы данных скопируйте файлы на каждую реплику перед запуском процесса репликации.