17.1.3.1 GTID の概念

グローバルトランザクション識別子 (GTID) は、発生元のサーバー (マスター) で作成され、そこでコミットされた各トランザクションに関連付けられる一意識別子です。この識別子は、サーバーはもちろん、特定のレプリケーションセットアップ内のすべてのサーバーに一意です。すべてのトランザクションとすべての GTID との間には 1 対 1 マッピングがあります。

GTID は座標のペアとして表現され、次に示すように、コロン文字 (:) で区切られます。

GTID = source_id:transaction_id

source_id は発生元サーバーを識別します。通常、サーバーの server_uuid はこの目的のために使用されます。transaction_id は、このサーバーでコミットされた順番によって決められるシーケンス番号です。たとえば、コミットされる最初のトランザクションには、その transaction_id として 1 が割り当てられ、同じ発生元サーバーでコミットされる 10 番目のトランザクションには transaction_id として 10 が割り当てられます。トランザクションに、GTID のシーケンス番号として 0 を割り当てることはできません。たとえば、UUID が 3E11FA47-71CA-11E1-9E33-C80AA9429562 の発生元サーバーでコミットされた 23 番目のトランザクションの GTID は次のとおりです。

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

この形式は、SHOW SLAVE STATUS などのステートメントの出力やバイナリログで GTID を表すために使用されます。それらは、mysqlbinlog --base64-output=DECODE-ROWS でログファイルを表示するとき、または SHOW BINLOG EVENTS からの出力でも見ることができます。

GTID は SHOW MASTER STATUS や SHOW SLAVE STATUS などのステートメントの出力に書き込まれると、同じサーバーから発生する GTID シーケンスは次のように単一表現にまとめられることがあります。

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

この例は、server_uuid が 3E11FA47-71CA-11E1-9E33-C80AA9429562 の MySQL Server で発生する 1 番目から 5 番目までのトランザクションを表します。

MySQL 5.6.6 以降では、この形式は 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 セットが必要です。

GTID はマスターとスレーブとの間で常に保持されます。これは、バイナリログを検査することで、スレーブに適用されたトランザクションのソースをいつでも特定できることを意味します。また、ある GTID のトランザクションがあるサーバーでコミットされると、同じ GTID のそれ以降のトランザクションはそのサーバーで無視されます。このように、マスターでコミットされるトランザクションはスレーブで一度だけ適用できるため、一貫性の保証に役立ちます。

GTID が使用されるときは、マスター上でのファイルの名前やそのファイル内での位置などの非ローカルデータがスレーブに必要なくなります。マスターとの同期に必要なすべてのデータは、レプリケーションデータストリームから直接取得されます。データベース管理者または開発者からは、GTID は、ファイルオフセットペアを完全に置き換えるものです (以前はマスターとスレーブ間のデータフローを開始、停止、または再開ポイントを決定するために必要でした)。これは、レプリケーションに GTID を使用しているときは、所定のマスターから複製するようにスレーブに指示するために使用する MASTER_LOG_FILE または MASTER_LOG_POS オプションを CHANGE MASTER TO ステートメントに含める必要がありません (含めたくありません)。これらのオプションの代わりに必要なのは、MySQL 5.6.5 で導入された MASTER_AUTO_POSITION オプションを有効にすることだけです。GTID ベースレプリケーションを使用してマスターとスレーブを構成して起動するために必要な正確な手順については、セクション17.1.3.2「GTID を使用したレプリケーションのセットアップ」を参照してください。

GTID の生成とライフサイクルは次の手順で構成されます。

1. トランザクションがマスター上で実行され、コミットされます。

   このトランザクションには、マスターの UUID と、このサーバーでまだ使用されていない最小のゼロでないトランザクションシーケンス番号を使用する GTID が割り当てられます。GTID はマスターのバイナリログに書き込まれます (ログ内のトランザクション自体の直前)。

2. バイナリログがスレーブに転送され、スレーブのリレーログに格納されたあと (このプロセスのために確立されたメカニズムを使用します。詳細については、セクション17.2「レプリケーションの実装」を参照してください)、スレーブは GTID を読み取り、その gtid_next システム変数値をこの GTID として設定します。これは、次のトランザクションのログはこの GTID を使用して記録される必要があることをスレーブに伝えます。

   スレーブはセッションコンテキストに gtid_next を設定することに注目することが重要です。

3. スレーブは、自身のバイナリログにトランザクションログを記録するためにこの GTID が確実にまだ使用されていないことをチェックします。この GTID が使用されていない場合にのみ、スレーブは GTID を書き込み、トランザクションを適用します (そして、トランザクションをバイナリログに書き込みます)。トランザクション自体を処理する前に、まずトランザクションの GTID を読み取ってチェックすることで、スレーブは、この GTID を持つ前のトランザクションがスレーブにまだ適用されていないこと、さらにほかのセッションがまだこの GTID を読み取っておらず、関連付けられたトランザクションをまだコミットしていないことを保証します。つまり、複数のクライアントが並列に同じトランザクションを適用することは許可されません。

4. gtid_next が空でないため、スレーブはこのトランザクションの GTID を生成しようとせず、代わりにこの変数に格納された GTID (すなわち、マスターから取得した GTID) をバイナリログ内のトランザクションの直前に書き込みます。