16.3.1.1. Поддержка Ведомого устройства Используя mysqldump

Используя mysqldump, чтобы создать копию базы данных позволяет Вам получить все данные в базе данных в формате, который позволяет информации быть импортированной в другой экземпляр MySQL Server (см. Раздел 4.5.4, "mysqldump — Программа Резервного копирования базы данных" ). Поскольку формат информации является SQL-операторами, файл может легко быть распределен и применен к рабочие серверы, когда Вы нуждаетесь в доступе к данным в чрезвычайной ситуации. Однако, если размер Вашего набора данных является очень большим, mysqldump может быть непрактичным.

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

Мешайте ведомому устройству обработать запросы. Можно остановить репликацию полностью на ведомом устройстве, используя mysqladmin:
```
shell> mysqladmin
                    stop-slave
```
Альтернативно, можно остановить только ведомый поток SQL, чтобы приостановить выполнение события:
```
shell> mysql -e 'STOP SLAVE
                    SQL_THREAD;'
```
Это позволяет ведомому устройству продолжать получать события изменения данных от двоичного файла ведущего устройства, регистрируют и хранят их в релейных журналах, используя поток ввода-вывода, но препятствует тому, чтобы ведомое устройство выполнило эти события и изменило его данные. В пределах занятых сред репликации, разрешая поток ввода-вывода работать во время резервного копирования может ускорить процесс кетчупа, когда Вы перезапускаете ведомый поток SQL.
Выполненный mysqldump, чтобы вывести Ваши базы данных. Можно или вывести все базы данных или выбрать базы данных, которые будут выведены. Например, чтобы вывести все базы данных:
```
shell> mysqldump --all-databases >
                    fulldb.dump
```
Как только дамп завершился, запустите ведомые операции снова:
```
shell> mysqladmin
                    start-slave
```

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

Если Вы используете этот подход, удостоверьтесь, что Вы контролируете ведомый процесс репликации, чтобы гарантировать, что время, потраченное, чтобы выполнить резервное копирование, не влияет на возможность ведомого устройства не отставать от событий от ведущего устройства. См. Раздел 16.1.5.1, "Проверяя Состояние Репликации". Если ведомое устройство неспособно поддержать на высоком уровне, можно хотеть добавить другое ведомое устройство и распределить процесс резервного копирования. Для примера того, как сконфигурировать этот сценарий, см. Раздел 16.3.4, "Тиражируя Различные Базы данных в Различные Ведомые устройства".