Spec-Zone .ru
спецификации, руководства, описания, API
|
Глобальный идентификатор транзакции (GTID) является уникальным идентификатором, создаваемым и связанным с каждой транзакцией, когда это фиксируется на сервере источника (ведущее устройство). Этот идентификатор уникален не только для сервера, на котором он произошел, но и уникален через все серверы в данной установке репликации. Есть 1 к 1 отображение между всеми транзакциями и всем GTIDs.
GTID представляется как пара координат, разделенных символом двоеточия (:
), как
показано здесь:
GTID =source_id
:transaction_id
source_id
идентифицирует инициирующий сервер. Обычно, сервер server_uuid
используется с этой целью. (Для этого теоретически возможно быть определенным другим способом, если источник
транзакции не является экземпляром MySQL Server, но это в настоящий момент не поддерживается.) transaction_id
порядковый номер, определенный порядком, в котором
транзакция фиксировалась на этом сервере; например, первая транзакция, которая будет фиксироваться, имеет 1
как transaction_id
, и десятая
транзакция, которая будет фиксироваться на том же самом инициирующем сервере, присваивается a transaction_id
из 10
. (Для транзакции
не возможно иметь 0
как порядковый номер в GTID.) Таким образом, двадцать третья
транзакция, которая будет фиксироваться первоначально на сервере, имеющем UUID 3E11FA47-71CA-11E1-9E33-C80AA9429562
имеет этот GTID:
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
Этот формат используется, чтобы представить GTIDs в выводе операторов такой как SHOW SLAVE STATUS
так же как в двоичном журнале. Они могут также быть замечены,
просматривая файл журнала с mysqlbinlog --base64-output=DECODE-ROWS
или в выводе от SHOW BINLOG EVENTS
.
Столь же записанный в выводе операторов такой как SHOW MASTER STATUS
, SHOW SLAVE STATUS
,
последовательность GTIDs, происходящего из того же самого сервера, может быть свернута в единственное выражение,
как показано здесь.
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
Пример, только показанный, представляет первое через пятые транзакции, происходящие на MySQL Server чей server_uuid
3E11FA47-71CA-11E1-9E33-C80AA9429562
.
Этот формат также используется, чтобы предоставить параметр, требуемый START SLAVE
опции SQL_BEFORE_GTIDS
и SQL_AFTER_GTIDS
.
Наборы GTID. Набор GTID является рядом глобальных идентификаторов транзакции, который представляется как показано здесь:
gtid_set
:uuid_set
[,uuid_set
] ... | ''uuid_set
:uuid
:interval
[:interval
]...uuid
:hhhhhhhh
-hhhh
-hhhh
-hhhh
-hhhhhhhhhhhh
h
: [0-9,A-F]interval
:n
[-n
] (n
>= 1)
Наборы GTID используются в MySQL Server несколькими способами. Например, значения, сохраненные gtid_executed
и gtid_purged
системные переменные представляются как наборы GTID. Кроме того,
функции GTID_SUBSET()
и GTID_SUBTRACT()
потребуйте наборов GTID как входной.
GTIDs всегда сохраняются между ведущим устройством и ведомым устройством. Это означает, что можно всегда определять источник для любой транзакции, примененной на любое ведомое устройство, исследуя его двоичный журнал. Кроме того, как только транзакция с данным GTID фиксируется на данном сервере, любая последующая транзакция, имеющая тот же самый GTID, игнорируется тем сервером. Таким образом транзакция, фиксировавшая на ведущем устройстве, может быть применена не больше, чем однажды на ведомом устройстве, которое помогает гарантировать непротиворечивость.
Когда GTIDs используются, у ведомого устройства нет никакой потребности в любых нелокальных данных, таких как
имя файла на ведущем устройстве и позиции в пределах того файла. Вся необходимая информация для того, чтобы
синхронизироваться с ведущим устройством получается непосредственно из потока данных репликации. С точки зрения
администратора базы данных или разработчика, GTIDs полностью берут место пар файлового смещения, ранее требуемых
определить точки для того, чтобы начать, остановить, или возобновить поток данных между ведущим устройством и
ведомым устройством. Это означает, что, когда Вы используете GTIDs для репликации, Вы не нуждаетесь (или хотите)
включать MASTER_LOG_FILE
или MASTER_LOG_POS
опции в CHANGE MASTER TO
оператор, используемый, чтобы направить ведомое устройство,
чтобы тиражироваться от данного ведущего устройства; вместо этих опций, это необходимый только, чтобы включить
MASTER_AUTO_POSITION
опция. Поскольку точные шаги должны были сконфигурировать и
запустить ведущие устройства, и ведомые устройства, используя GTID-на-основе репликацию, см. Раздел
16.1.3.2, "Устанавливая Репликацию Используя GTIDs".
Генерация и жизненный цикл GTID состоят из следующих шагов:
Транзакция выполняется и фиксируется на ведущем устройстве.
Эта транзакция присваивается GTID использование UUID ведущего устройства и самого маленького ненулевого порядкового номера транзакции, еще используемого на этом сервере; GTID пишется двоичному журналу ведущего устройства (сразу предшествующий транзакции непосредственно в журнале).
После двоичного файла регистрируют данные, передается к ведомому устройству и
сохранен в релейном журнале ведомого устройства (использующий установленные механизмы для этого процесса
— видят Раздел 16.2, "Реализация Репликации",
для деталей), ведомое устройство читает GTID и устанавливает значение gtid_next
системная переменная как этот GTID. Это говорит ведомому
устройству, что следующая транзакция должна быть зарегистрирована, используя этот GTID.
Важно отметить, что ведомое устройство устанавливает gtid_next
в
контексте сеанса.
Ведомые проверки, чтобы удостовериться, что этот GTID уже не использовался, чтобы зарегистрировать транзакцию в ее собственном двоичном журнале. Если и только если этот GTID не использовался, ведомое устройство тогда пишет GTID и применяет транзакцию (и пишет транзакцию в ее двоичный журнал). Читая и проверяя GTID транзакции сначала, прежде, чем обработать транзакцию непосредственно, ведомое устройство гарантирует не только, что никакая предыдущая транзакция, имеющая этот GTID, не была применена на ведомое устройство, но также и что никакой другой сеанс уже не считал этот GTID, но еще не фиксировал связанную транзакцию. Другими словами многократным клиентам не разрешают применить ту же самую транзакцию одновременно.
Поскольку gtid_next
не пусто, ведомое устройство не пытается генерировать GTID для
этой транзакции, но вместо этого пишет GTID, сохраненный в этой переменной — то есть, GTID, полученный
от ведущего устройства — сразу предшествование транзакции в ее двоичном журнале.