Mysql 5.6: Replication with Global Transaction Identifiers / Репликация с помощью глобальных идентификаторов транзакций: 16.1.3.3. Применение GTID для аварийного переключения и масштабирования

Существуют несколько техник запуска репликаций на основе Глобальных идентификаторов транзакций (GTID), используемых в MySQL 5.6.9 и выше для инициализации новых slave-серверов, для использования при масштабирования и повышении до master-серверов при аварийном переключении. В этом разделе рассматриваются 4 из них:

nipman 30.10.13 в 05:02

- Простая репликация

nipman 30.10.13 в 05:02

- Копирование данных и транзакций на slave-сервер

nipman 30.10.13 в 05:02

- Внедрение пустых транзакций

nipman 30.10.13 в 05:03

- Пропуск транзакций с помощью gtid_purged

nipman 30.10.13 в 05:03

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

nipman 30.10.13 в 05:04

Соотвествие между идентификаторам транзакции и последовательностью событий, входящих в нее фиксируется в бинарном логе. Это может вызвать некоторые трудности при попытке пользователя подключить новый сервер с данными другого. Для воспроизведения набора идентификаторов на одном сервере необходимо не просто скопировать идентификаторы старого сервера на новый, но и обеспечить связь между ними и актуальными событиями, которые в свою очередь необходимы для восстановления по средством повышения slave-сервера в master-сервера в случае аварийного или планового переключения.

nipman 30.10.13 в 05:09

Простая репликация.

nipman 30.10.13 в 05:15

Это простейший способ воспроизведения всех идентификаторов и транзакций на новом сервере; Вы просто превращаете сервер в slave следующий за master-сервером, который в свою очередь содержит полную историю изменений, включаете GTID на обоих серверах. (необходимо что бы оба сервера были запущены с опциями --gtid-mode=ON --log-bin --log-slave-updates --enforce-gtid-consistency, см 16.1.3.2 "Настройка репликации с помощью GTID")

nipman 30.10.13 в 05:19

Однажды запущенная репликация обеспечит копирование полного бинарного лога master-севрера и получение информации обо всех GTID.

nipman 30.10.13 в 05:20

Этот метод прост и эффективен, но требует возможности slave-сервера читать данные бинарного лога master-сервера; Что может занять очень длительное время при подключении нового slave-сервера, так что он не очень подходит для быстрого переключения или восстановления. Существует возможность избежать необходимости воспроизведения полного списка изменений, посредством прямого копирования бинарного лога на новый сервер. Этот метод мы рассмотрим далее.

nipman 30.10.13 в 05:21

Копирование данных и транзакций на slave-сервер.

nipman 30.10.13 в 05:25

Полное воспроизведение всей истории изменений может занять очень длительное время, и существенно заотормозит процес запуска нового slave-севрера. Однако этот недостаток может быть устраненной посредством создания резервной копии master-сервера, которая помимо дампа содержащего снимок данных будет включать бинарные логи, содержащие в свою очередь GTID. Запуск репликации посредством иморта дампа данных и вопроизведения бинарного лога позволяет запустить актуальный slave-сервер, независимо от количества оставшихся транзакций.

nipman 30.10.13 в 05:28

Способы реализации этого метода, отличаются средствами передачи данных (дампов) и транзакций (бинарных логов). Рассмотрим их подробнее.

nipman 30.10.13 в 05:34

DATA-сеты

nipman 30.10.13 в 05:34

- Использование клиента mysql для импорта дампа, созданного с помощью mysqldump. Использование опций --master-data для включения данных бинарного лога и --set-gtid-purged (доступна в 5.6.9 и выше) со значение AUTO (по-умолчанию) или ON для включения данных о запущенных транзакциях. Опция --gtid-mode=ON обязательна при импорте дампа на slave-сервере. (BUG #14832472)

nipman 30.10.13 в 05:38

- Остановите slave-сервер, скопируйте содержимое папки data master-сервера на slave-сервер, перезапустите slave-сервер.

nipman 30.10.13 в 05:40

История транзакций

nipman 30.10.13 в 05:40

Если значение gtid_mode отлино от значения ON, перезапустите сервере включив GTID-режим.

nipman 30.10.13 в 05:41

- Импортируйте бинарный лог, с помощью mysqlbinlog опций --read-from-remote-server and --read-from-remote-master.

nipman 30.10.13 в 05:41

- Скопируйте бинарные логи master-сервера и slave-сервера. Можно сделать копии, c помощью команды mysqlbinlog --read-from-remote-server --raw. Созданные копиии могут быть воспроизведены на slave-сервере следующим образом:

nipman 30.10.13 в 05:43

+ Обновление binlog.index на slave-сервере, таким образом что бы он указывал на скопированные логи. Запуск выражения CHANGE MASTER TO в mysql-клиенте, что бы указать местоположение первого лог-файла и выражения START SLAVE для его чтения.

nipman 30.10.13 в 05:46

+ Использование mysqlbinlog > file (без --raw опции) для экспорта бинарного лога в ввиде SQL-файла, который может быть обработан mysql-клиентом.

nipman 30.10.13 в 05:47

См 4.6.8.3, “Использование mysqlbinlog для резервного копирования файлов биранрного лога”.

nipman 30.10.13 в 05:48

Достоинство этого метода состоит в том, что новый сервер будет доступен сразу; Будут воспроизведены только те транзакции, которые не успели попасть в dump-файл и были получены с master-сервера. Это значит, что новый сервер будет доступен не мгновенно, а по прошествии некоторого времени необходимо для устранения такого отставания.

nipman 30.10.13 в 05:52

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

nipman 30.10.13 в 05:55

Внедрение пустых транзакций

nipman 30.10.13 в 05:57

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

nipman 30.10.13 в 06:01

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

nipman 30.10.13 в 06:04

Это делается для того, что бы эта пустая транзакция не попала в поток реплицируемых данных, в случае повышения этого slave-сервера до master. (Выражение FLUSH LOGS приводит к созданию нового файла лога, PURGE BINARY LOGS удаляет пустые транзакции, оставив их идентификаторы).

nipman 30.10.13 в 06:08

Этот метод позволяет создавать slave-сервера, являющиеся слепком текущего состояния master-севера. Slave-севрер, который может стать master-сервером так как его бинарный лог сходится с потоком данных репликации (в том виде в котором его генерирует один или несколько master-серевров). Этот метод дает тот же результат что и последний оставшийся метод, рассмотрим его далее.

nipman 30.10.13 в 07:04

Пропуск транзакций с помощью gtid_purged

nipman 30.10.13 в 07:06

Глобальная переменная gtid_purged на master-сервере содержит список всех транзакций, которые были исключены из бинарного лога. Как и в предыдущем методе (см Добавление пустых транзакций), вы можете записать значение gtid_executed источника данных (вместо копирования бинарного лога). В отличии от предыдущего метода, нет необходимости сохранять пустые транзакции (или запускать PURGE BINARY LOGS); вместо этого можно просто установить на целевом сервере gtid_purged равной gtid_executed сервера с которого данные были получены.

nipman 30.10.13 в 07:15

Примечание
В версиях MySQL ниже 5.6.9 значение gtid_purged неизменяемо. (Bug #14797808)

nipman 30.10.13 в 07:16

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

nipman 30.10.13 в 07:19