Есть много методов при использовании MySQL Replication with Global Transaction Identifiers (GTIDs) для того, чтобы настроить новое ведомое устройство, которое может тогда использоваться для scaleout, будучи продвинутым на ведущее устройство по мере необходимости для failover. В этом разделе мы обсуждаем эти четыре метода, перечисленные здесь:

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

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

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

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

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

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

Есть несколько разновидностей этого метода; их может отличить способ, которым данные (дампы) и транзакции (двоичные журналы) поставляются новому ведомому устройству, как обрисовано в общих чертах здесь:

См. также Раздел 4.6.8.3, "Используя mysqlbinlog, чтобы поддержать Двоичные Файлы журнала".

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

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

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

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';BEGIN;COMMIT;SET GTID_NEXT='AUTOMATIC';

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

FLUSH LOGS;PURGE BINARY LOGS TO 'master-bin.00000N';

Следует сделать это, чтобы препятствовать тому, чтобы этот сервер лавинно разослал поток репликации с ложными транзакциями, когда это позже продвигается на ведущее устройство. ( FLUSH LOGS оператор вызывает создание нового двоичного файла журнала; PURGE BINARY LOGS производит чистку пустых транзакций, но сохраняет их идентификаторы.)

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

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

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