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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DATA-сеты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание! Этот перевод, возможно, ещё не готов.
Его статус: идёт перевод

Переведено на Нотабеноиде
http://notabenoid.org/book/45231/179706

Переводчики: nipman