MySQLレプリケーションの運用が劇的変化！！GTIDについて仕組みから理解する

メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！

というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。

前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID︵Global Transaction ID︶である。

GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOでバイナリログポジションをいちいち指定しなくても良いということだ。スレーブが要求するGTIDから、自動的にどのポジションからバイナリログを転送すれば良いのかを判断してくれる。マスターに障害が生じたなどの理由でスレーブを昇格させるとき、最も進んだスレーブを選択しさえすれば、後は勝手に差分を調整してくれるのである。何て便利な機能なんだ！と思わざるを得ない。

その一方、GTIDを使う上では運用者のマインドにも変化が求められる。運用方法がガラリ変わってしまうからだ。スレーブの構築方法や、日々のバックアップ等の運用にも変化が求められる。今日は、便利だけど注意が必要なGTIDについて、その仕組みから解説しようと思う。

まだMySQL 5.5で消耗してるの？MySQL 5.6でクラッシュセーフなレプリケーションを活用して枕を高くして眠れる日々を満喫する方法

MySQL 5.6が登場してからかなりの月日が過ぎたが、他のことで多忙だったせいか、MySQL 5.6についてはあまりブログで情報を発信していないことに気がついた。これはイカン！！と思い、MySQL Casual Advent Calendar 2014に合わせて、MySQL 5.6を使用する上で最もオススメしたい機能であるクラッシュセーフなレプリケーションについて解説しようと思う。この記事は16日目の記事である。

Validation nightで発表しました。

Validation nightというイベントに呼んで頂いたので発表してきた。