はじめに
この記事は MySQL 5.6.4 で実装されたGTIDレプリケーションを、とにかく簡単に、とにかくわかりやすく解説したものです。それゆえ正確な説明ではなくなっているところがあります。ご了承ください。正確な知識を得るための導入としてお読みください。
GTID レプリケーションとは
MySQL 5.6.5 から実装されたレプリケーション方式で、Global Transaction ID レプリケーションの略です。
Global Transaction ID レプリケーションとはなんぞや？についてこれから説明していきます。
GITDでないレプリケーションとは
GTIDでないレプリケーションは、多分固有の名前はついてないと思うのですが、仮に「バイナリログ名とポジションによるレプリケーション」と呼ぶことにします。
バイナリログとポジションとは
- バイナリログとは、簡単に言うと、MySQLサーバーのクエリの実行ログです
- 各バイナリログには名前がついています。これがバイナリログ名です
- ポジションとは、要するに各バイナリログの行数です
バイナリログ名とポジションによるレプリケーションとは
Slaveは、Masterに流された更新クエリと同じクエリを自分にも流します。Slaveは「Masterの更新クエリをどこまで実行したか」を「バイナリログ名」と「ポジション」で判別して、それ以降のクエリを実行していきます。これがバイナリログ名とポジションによるレプリケーションです。
バイナリログ名とポジションによるレプリケーションの複雑なポイント
当然SlaveもMasterと同じようにバイナリログを持っています。しかし、Masterと同じクエリでも、MasterとSlaveではバイナリログ名とポジションが違ったりするのです。
バイナリログ名とポジションによるレプリケーションのデメリット
ではこれは何がダメなのでしょう。主に「SlaveがMaster昇格する時」に困ります。Master1台に対して複数台のSlaveがある場合に、Masterが故障して、ある一つのSlaveがMasterに昇格すとします。この時「壊れたMaster」と「昇格してMasterになったSlave」のバイナリログが異なるため、レプリケーションを貼り直す際に不具合が生じます。
ではGTIDレプリケーションとは
GTIDレプリケーションの場合は、クエリログの行ごとに「Global Transaction ID (GTID)」が付きます。GTIDが同じであればクエリも同じです。バイナリログ名やポジションのように、サーバーごとに値が異なることはありません。
「レプリケーションがどこまで行われたか」はGTIDを使って管理されるようになります。
これによって、先ほどのようにSlaveがMasterに昇格する場合も、ログのポジションで迷うことがなくなるわけです。
もっと詳しく理解したい
以前のブログでも上げましたが、以下の記事が非常に参考になります。
さいごに
この記事は、 MySQL 5.7のマルチソースレプリケーションを活用する - 無停止でシャーディングを解消 - ことさら−古都プログラマーの更級日記 の続編（補足）的な感じで書きました。ぜひこちらの記事も読んでみてください。
