Spec-Zone .ru
спецификации, руководства, описания, API

16.3.1.3. Поддержка Ведущего устройства или Ведомого устройства, Делая Это Только для чтения

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

  1. Сделайте сервер только для чтения, так, чтобы он обработал только извлечения и блокировал обновления.

  2. Выполните резервное копирование.

  3. Возвратите сервер к его нормальному состоянию чтения-записи.

Отметить

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

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

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

Сценарий 1: Резервное копирование с Ведущим устройством Только для чтения

Поместите ведущее устройство М1 в состояние только для чтения, выполняя эти операторы на этом:

mysql> FLUSH TABLES WITH READ LOCK;mysql> SET GLOBAL read_only = ON;

В то время как M1 находится в состоянии только для чтения, следующие свойства являются истиной:

В то время как M1 только для чтения, выполните резервное копирование. Например, можно использовать mysqldump.

После того, как операция резервного копирования на M1 завершается, восстановление M1 к его нормальному рабочему состоянию, выполняя эти операторы:

mysql> SET GLOBAL read_only = OFF;mysql> UNLOCK TABLES;

Хотя выполнение резервного копирования на M1 безопасно (насколько резервное копирование затрагивается), это не оптимально для производительности, потому что клиенты M1 блокируются от выполнения обновлений.

Эта стратегия применяется к поддержке главного сервера в установке репликации, но может также использоваться для единственного сервера в установке нерепликации.

Сценарий 2: Резервное копирование с Ведомым устройством Только для чтения

Поместите ведомый S1 в состояние только для чтения, выполняя эти операторы на этом:

mysql> FLUSH TABLES WITH READ LOCK;mysql> SET GLOBAL read_only = ON;

В то время как S1 находится в состоянии только для чтения, следующие свойства являются истиной:

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

В то время как S1 только для чтения, выполните резервное копирование. Например, можно использовать mysqldump.

После того, как операция резервного копирования на S1 завершается, восстановление S1 к его нормальному рабочему состоянию, выполняя эти операторы:

mysql> SET GLOBAL read_only = OFF;mysql> UNLOCK TABLES;

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