ことさら−古都プログラマーの更級日記

京都でお寺を回りながら御朱印集めをしていたり、LoLをしたり試合を見に行ったりしているエンジニアのブログです。技術的なはなしとか日常的なはなし、カメラやLoLや競馬の話も書きます。右メニューに検索やらカテゴリーやらがあるので、見たい記事だけ見てね!

MySQL 5.6 で実装されたGTIDレプリケーションについて誤解を恐れずに、とにかく簡単にわかりやすく解説する

はじめに

この記事は MySQL 5.6.4 で実装されたGTIDレプリケーションを、とにかく簡単に、とにかくわかりやすく解説したものです。それゆえ正確な説明ではなくなっているところがあります。ご了承ください。正確な知識を得るための導入としてお読みください。

GTID レプリケーションとは

MySQL 5.6.5 から実装されたレプリケーション方式で、Global Transaction ID レプリケーションの略です。

Global Transaction ID レプリケーションとはなんぞや?についてこれから説明していきます。

GITDでないレプリケーションとは

GTIDでないレプリケーションは、多分固有の名前はついてないと思うのですが、仮に「バイナリログ名ポジションによるレプリケーション」と呼ぶことにします。

バイナリログとポジションとは

  • バイナリログとは、簡単に言うと、MySQLサーバーのクエリの実行ログです
  • 各バイナリログには名前がついています。これがバイナリログ名です
  • ポジションとは、要するに各バイナリログの行数です

f:id:yoshiki_utakata:20171216174742p:plain

バイナリログ名とポジションによるレプリケーションとは

Slaveは、Masterに流された更新クエリと同じクエリを自分にも流します。Slaveは「Masterの更新クエリをどこまで実行したか」を「バイナリログ名」と「ポジション」で判別して、それ以降のクエリを実行していきます。これがバイナリログ名とポジションによるレプリケーションです。

f:id:yoshiki_utakata:20171216175644p:plain

バイナリログ名とポジションによるレプリケーションの複雑なポイント

当然SlaveもMasterと同じようにバイナリログを持っています。しかし、Masterと同じクエリでも、MasterとSlaveではバイナリログ名とポジションが違ったりするのです。

f:id:yoshiki_utakata:20171216180324p:plain

バイナリログ名とポジションによるレプリケーションのデメリット

ではこれは何がダメなのでしょう。主に「SlaveがMaster昇格する時」に困ります。Master1台に対して複数台のSlaveがある場合に、Masterが故障して、ある一つのSlaveがMasterに昇格すとします。この時「壊れたMaster」と「昇格してMasterになったSlave」のバイナリログが異なるため、レプリケーションを貼り直す際に不具合が生じます。

f:id:yoshiki_utakata:20171216181640p:plain

ではGTIDレプリケーションとは

GTIDレプリケーションの場合は、クエリログの行ごとに「Global Transaction ID (GTID)」が付きます。GTIDが同じであればクエリも同じです。バイナリログ名やポジションのように、サーバーごとに値が異なることはありません。

f:id:yoshiki_utakata:20171216182404p:plain

レプリケーションがどこまで行われたか」はGTIDを使って管理されるようになります。

これによって、先ほどのようにSlaveがMasterに昇格する場合も、ログのポジションで迷うことがなくなるわけです。

もっと詳しく理解したい

以前のブログでも上げましたが、以下の記事が非常に参考になります。

bizstation.hatenablog.com

さいごに

この記事は、 MySQL 5.7のマルチソースレプリケーションを活用する - 無停止でシャーディングを解消 - ことさら−古都プログラマーの更級日記 の続編(補足)的な感じで書きました。ぜひこちらの記事も読んでみてください。