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

Оглавление

Сбросить всё

Английский оригинал	Перевод на русский
Сожалеем, но текст оригинала доступен только зарегистрированным пользователям.	Глобальный идентификатор транзакции (GTID) - это уникальный идентификатор, создаваемый для каждой транзакции в тот момент, когда происходит ее фиксация на оригинальном, master-севрере. Этот идентификатор уникален не только для отдельного сервера, на котором была инициализирована эта транзакция, но и для всех серверов входящих в заданную конфигурацию. Иными словами транзакции и GTID связаны один-к-одному. nipman 29.10.13 в 12:20 0
	GTID представляет собой пару координат, разделенных двоеточием (:), как показано ниже: nipman 29.10.13 в 12:21 0

	где, source_id укавает на оригинальный сервер. Обычно для этих целей используется server_uuid. (Допускаются исключения, если создателем транзакции является не MySQL Server, однако на данный момент такая возможность отсутствует). transaction_id - это последовательность цифр, определяющая порядок в котором данная транзакция была применена на сервере. Например, transaction_id первой транзакции равен 1, для 10-й transaction_id=10. (не допускается применения транзакций с номером 0). Таким образом 23-я транзакция примененная на севрере с UUID 3E11FA47-71CA-11E1-9E33-C80AA9429562 получит следующий GTID: nipman 29.10.13 в 12:35 0

	Этот формат встречается как выводе команды SHOW SLAVE STATUS, так и в бинарном логе. Так же его можно встретить при просмотре лог-файла с помощью команды mysqlbinlog --base64-output=DECODE-ROWS или команды SHOW BINLOG EVENTS. nipman 29.10.13 в 12:35 0
	В выводе таких команд как SHOW MASTER STATUS или SHOW SLAVE STATUS, последовательность GTID может быть скомпонована в одно выражение. Например так: nipman 29.10.13 в 12:33 0

	Это выражение эквивалентно выводу первых пяти транзакций зафиксированных на MySQL Server с server_uuid 3E11FA47-71CA-11E1-9E33-C80AA9429562. nipman 29.10.13 в 12:35 0
	В MySQL 5.6.6 и выше данный формат так же используется для передачи параметров функциям START SLAVE, SQL_BEFORE_GTIDS и SQL_AFTER_GTIDS. nipman 29.10.13 в 12:37 0
	GTID сеты. GTID сет - это набор глобальных идентификаторов транзакций, например таких: nipman 29.10.13 в 13:46 0

	Существует несколько способов применения GTID сетов в MySQL Server. Например, значения системных переменных gtid_executed и gtid_purged могут быть представлены в виде GTID сетов. Кроме того функции GTID_SUBSET() и GTID_SUBTRACT() принимают сеты в качестве обязательных параметров. nipman 29.10.13 в 13:54 0
	GTID-идентификаторы безопасны как для master так и для slave серверов. Это означает, источник любой транзакции, может быть определен по записи в бинарном логе. Более того однажды применная на сервере транзакция будет проигнорирована при повторной попытке применения на этом же сервере. Иными словами, транзакция, применная на master-сервере, может быть применена на slave сервере только один раз, что в свою очередь гарантирует его целостность. nipman 29.10.13 в 13:59 0
	При использовании GTID отпадает потребность в информации об имени лог файла и позиции в нем на master-сервере. Вся необходимая для синхронизации информация извлекается прямо из потока данных репликации. С точки зрения администратора базы данных и программиста GTID полностью заменяют имена файлов и смещений, прежде требовавшихся для синхронизации master и slave серверов. Это значит, что опции MASTER_LOG_FILE и MASTER_LOG_POS более являются обязательными в выражении CHANGE MASTER TO. Теперь нужен только один параметр MASTER_AUTO_POSITION, впервые ставший доступен в MySQL 5.6.5. Полный список шагов, необходимых для запуска GTID репликации на master и slave серверах смотрите 16.1.3.2, “Настройка репликации с помощью GTID”. nipman 29.10.13 в 14:14 0
	Генерация и жизненный цикл GTID включает следующие шаги. nipman 29.10.13 в 14:15 0
	1. Запуск и фиксация транзакции на master-сервере. nipman 29.10.13 в 14:16 0
	2. Присвоение транзакции уникального GTID, состоящего из UUID мастера и наименьшего ненулевого порядкового номера, который еще не был использован на этом сервере. GTID записывается в бинарный лог master-сервера (непосредственно перед записью самой транзакции). nipman 29.10.13 в 14:20 0
	3. После передачи данных бинарного лога на slave-сервер и их записи в его relay-логе (более подробное описание этого механизма см в 16.2 “Replication Implementation”), slave-сервер считывает GTID и присваивает его системной переменной gtid_next. Что сообщает slave-серверу что следующая транзакция должна быть записана с этим GTID. nipman 29.10.13 в 14:24 0
	4. Необходимо отметить, что Slave-сервер присваивает значение gtid_next только в контексте сессии. nipman 29.10.13 в 14:25 0
	5. Slave-сервер проверяет наличие GTID в своем собственном бинарном логе. Если таковой не встречается, происходит применение связанной с этим GTID транзакции (и ее запись в бинарный лог). Благодаря предварительной проверке GTID slave-сервер не только гарантирует что связанная с ним транзакция не была ранее применена, но и то, что этот этот GTID не был обработан в другом потоке исполнения. Другими словами несколько клиентов не смогут одновременно применить одну и туже транзакцию. nipman 29.10.13 в 14:31 0
	6. Так как gtid_next уже имеет значение, slave-сервер не будет генерировать новый GTID для этой транзакции, вместо этого произойдет запись имеющегося GTID, который был получен от master-сервера и применение этой транзакции. nipman 29.10.13 в 14:37 0