第8回はMySQLの代表的なスケールアウト構成であるレプリケーション機能について解説します。

レプリケーションとは

データベースでのレプリケーションは，多くの場合データを複数のサーバで保持することで，処理性能の拡張性や耐障害性の向上を狙いとしています。レプリケーションによってデータの複製が作成されることにより，1台のサーバに障害が発生した場合でもデータを失うリスクが削減できるほか，システムを継続利用できる可能性が高まります。さらに複数のサーバにデータが複製されている場合は，データ参照処理を分散できる利点があります。

MySQLサーバのレプリケーション機能は2000年5月にリリースされたMySQL 3.23.15から実装されており，MySQLサーバの中でも初期から含まれている機能の一つとなっています。

参考URL

C.3.46 Changes in Release 3.23.15 (08 May 2000)

MySQLサーバのレプリケーション機能は，データの変更を1台で行い，複数のサーバにその複製を展開するマスタースレーブ型と呼ばれる構成となっています。

同期型レプリケーションと非同期型レプリケーション

レプリケーションにはデータの複製のタイミングによって同期型と非同期型に分類することができます。同期型の場合は，データの変更から全ての複製先への展開が一連の処理で（同期的に）行われます。非同期型の場合は，データの変更と複製先への展開が同一のタイミングであるという保証がない点（非同期的）が違いとなります。

同期型では全ての複製先にデータが反映されたことを待つ必要がありますが，アプリケーションがデータベースからの応答を得た時点で全てのサーバが同じデータを持っていることがメリットです。一方で非同期型は応答を待たなければならないのは，基本的に1台のサーバで起きたデータの変更のため，同期型に比べて高い応答性能が期待できます。ただしアプリケーションが応答を得た時点では他のサーバに変更が反映されていない可能性があることに注意が必要となります。

MySQLのレプリケーションでは，デフォルトでは非同期型となっています。MySQL 5.5以降では，プラグインをインストールすることで同期型と非同期型の中間に当たる準同期型をサポートしています。それぞれの挙動の詳細はアーキテクチャの解説の中で説明していきます。

MySQLのレプリケーションのアーキテクチャ

MySQLのレプリケーション構成では，「コミットされたトランザクションログの内容をコピーする」というのがアーキテクチャを非常におおまかに説明した言葉となります。特にポイントになるのがデータではなく，コミットされたトランザクションを記録しているバイナリログ（Binlog）の内容をコピーしている点です。

また，データの変更を行ったマスターが変更点をスレーブに渡す「プッシュ型」ではなく，最初にスレーブ内のIOスレッドがマスターに接続し，そのIOスレッドがログの内容を受け取る「プル型」になっているのも特徴です。IOスレッドはリレーログにコピーすると再びマスターに接続して次のバイナリログの変更を待ちます。

MySQLのデフォルトの非同期レプリケーションでは，以下の流れとなっています。

• 0) スレーブのIOスレッドがマスターに接続
• 1) アプリケーションがトランザクションをコミット
• 2) データとバイナリログ(Binlog)が同時に変更
• 3) MySQLサーバがアプリケーションにコミット完了の応答
• 4) IOスレッドがバイナリログの内容を受け取りスレーブのリレーログにコピー
• 5) スレーブのSQLスレッドがリレーログにコピーされた内容をデータに反映

非同期レプリケーションの設定方法

MySQLのレプリケーションを利用するうえで，最低限必要となるのは以下の設定です。

• マスターと各スレーブがそれぞれ異なるserver-idを持っていること
• ［マスター］バイナリログが有効となっていること
• ［マスター］スレーブのIOスレッドが接続するためのREPLICATION SLAVE権限を持つユーザが存在すること
• ［スレーブ］IOスレッドがCHANGE MASTER TOコマンドで指定するマスターに接続可能であること

MySQL 5.6以降ではトランザクションを一意に識別するGTID（Global Transaction Identifiers）が利用可能となっているため，CHANGE MASTER TOコマンドでMASTER_AUTO_POSITION = 1に指定すると自動的にスレーブ側にコピーしていないトランザクションのみを抽出してレプリケーションを開始できます。GTIDを有効にしていない環境では，レプリケーションを開始するマスターのバイナリログのポジションを明示的に指定する必要があります。

GTIDを利用することで，マスターとスレーブ間やスレーブ同士でのレプリケーションの進み具合を簡単に比較できるようになったため，オープンソースのMySQL運用支援ツールMySQL Utilitiesにも自動フェールオーバーツールのmysqlfailoverコマンドが用意されています。

参考URL

5.12. mysqlfailover — Automatic replication health monitoring and failover