16.3.1.3 Архивирование источника или реплики, сделав их только для чтения
Возможна архивация серверов источника или реплики в настройке репликации путём получения глобальной блокировки чтения и манипулирования системной переменной read_only для изменения состояния сервера, подлежащего архивации, на режим только для чтения:
Сделайте сервер только для чтения, чтобы он обрабатывал только запросы на получение данных и блокировал обновления.
Выполните архивацию.
Верните сервер в нормальное состояние чтения/записи.
Инструкции в этом разделе помещают сервер, подлежащий архивации, в состояние, безопасное для методов архивации, получающих данные с сервера, таких как mysqldump (см. Раздел 4.5.4, «mysqldump — Программа резервного копирования базы данных»). Не следует использовать эти инструкции для создания двоичной копии путём прямого копирования файлов, так как на сервере могут храниться изменённые данные в кэше памяти, которые ещё не записаны на диск.
Следующие инструкции описывают, как это сделать для сервера источника и для сервера реплики. Для обеих обсуждаемых ситуаций предположим, что у вас есть следующая настройка репликации:
Сервер источника S1
Сервер реплики R1, у которого S1 является источником
Клиент C1, подключённый к S1
Клиент C2, подключённый к R1
В любом из этих сценариев утверждения для получения глобальной блокировки чтения и манипулирования переменной read_only выполняются на сервере, подлежащем архивации, и не распространяются на какие-либо реплики этого сервера.
Сценарий 1: Архивация с источником только для чтения
Переведите источник S1 в состояние только для чтения, выполнив эти утверждения на нём:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
Пока S1 находится в состоянии только для чтения, справедливы следующие свойства:
Запросы на обновления, отправленные клиентом C1 на S1, блокируются, поскольку сервер находится в режиме только для чтения.
Запросы на результаты запросов, отправленные клиентом C1 на S1, выполняются успешно.
Архивация на S1 безопасна.
Архивация на R1 небезопасна. Этот сервер всё ещё работает и может обрабатывать двоичный журнал или запросы на обновление, поступающие от клиента C2.
При S1 в режиме только для чтения выполните архивацию. Например, вы можете использовать mysqldump.
После завершения операции архивации на S1 верните S1 в нормальное рабочее состояние, выполнив эти утверждения:
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
Хотя архивация на S1 безопасна (с точки зрения архивации), она не является оптимальной с точки зрения производительности, потому что клиенты S1 блокируются от выполнения обновлений.
Эта стратегия применима к архивации сервера источника в настройке репликации, но также может использоваться для одиночного сервера в настройке без репликации.
Сценарий 2: Архивация с репликой только для чтения
Переведите реплику R1 в состояние только для чтения, выполнив эти утверждения на ней:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
Пока R1 находится в состоянии только для чтения, справедливы следующие свойства:
Источник S1 продолжает работать, поэтому архивация на источнике небезопасна.
Реплика R1 останавливается, поэтому архивация на реплике R1 безопасна.
Эти свойства составляют основу популярного сценария архивации: загрузка одной реплики на некоторое время для выполнения архивации не проблема, потому что это не влияет на всю сеть, и система продолжает работать во время архивации. В частности, клиенты по-прежнему могут выполнять обновления на сервере источника, который не подвергается влиянию деятельности архивации на реплике.
При R1 в режиме только для чтения выполните архивацию. Например, вы можете использовать mysqldump.
После завершения операции архивации на R1 верните R1 в нормальное рабочее состояние, выполнив эти утверждения:
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
После возвращения реплики в нормальную работу она снова синхронизируется с источником, догоняя любые необработанные обновления из двоичного журнала источника.
© 2025 Oracle
Licensed under the GPLv2 License.
