MySQL 5.6での機能強化点（その3）- 人気のレプリケーションが更に機能強化

レプリケーション：開発生産性＆運用性向上

遅延レプリケーション

MySQL 5.6では、以下の図のように意図的にレプリケーションを遅延させることができます。

図3：遅延レプリケーション（クリックで拡大）

「遅延を意図的に発生させて何が嬉しいの？」、と思われるかもしれませんが、以下のような利用ケースが考えられます。

マスター側でのオペレーションミス対策

オペレーションミスでデータを消失した場合に、遅延レプリケーション環境からデータを復旧する

現在のデータと過去のデータを同時に確認する

遅延していないスレーブと遅延させているスレーブからデータを取り出し、今日の売上データと昨日の売上データを比較する、など

遅延が発生している環境を想定したシステムテスト、デバッグ

本番運用時にレプリケーション遅延が発生する可能性を想定したシステムテストを容易に

遅延レプリケーションを使う時は、CHANGE MASTER TO コマンドのMASTER_DELAYオプションで、遅延させたい時間を秒単位で指定します。特定のスレーブのみ遅延させることができるため、複数台のスレーブが存在する場合に1台だけ1日前のデータを保持しておく、といった使い方も可能です。

サーバーUUIDによりサーバーを一意に識別可能

サーバーごとにユニークなIDが自動的に割り振られるようになりました。データディレクトリ配下にauto.cnfファイルが自動的に作成され、UUID（Universally Unique Identifier）が記録されます。このUUIDはGTIDを使ったレプリケーションで利用されている他にも、以下のような利用ケースがあります。

• SHOW SLAVE HOSTSのSlave_UUIDから、スレーブのサーバーを一意に識別できる
• SHOW SLAVE STATUSのMaster_UUIDから、マスターを一意に識別できる
• CHANGE MASTER TO コマンドを実行していないのにマスターサーバーのUUIDが変更された場合、警告を出す

但し、これはレプリケーション環境構築時に設定が必要なserver_idの代替となるものではありませんので、注意して下さい。また、auto.cnfファイルはデータディレクトリ配下に自動的に生成されるため、マスターのデータディレクトリ配下をコピーしてスレーブを構築した場合は、スレーブ起動前にauto.cnfファイルを削除する必要がある点にも注意して下さい（auto.cnfファイルを削除してから起動することで、auto.cnfファイルが自動生成されます）。

バイナリログへSQL文の情報を追加出力

RBR利用時、更新の元になったステートメント（SQL文）に関する情報をバイナリログに追加できます。レプリケーションの追跡や問題発生時のデバッグに役に立ちます。

SQL文の情報を追加する場合は、以下のパラメータを設定します。

-	binlog_rows_query_log_events=ON

※設定可能な値はON、OFF (デフォルト値はOFF)
詳細はこちらを参照下さい。

SQL文の情報はコメントとしてバイナリログに追加されるため、SQL文を確認する時は以下の例のようにmysqlbinlogコマンドに”-vv”オプションを指定します。

[実行例]

mysqlbinlog -vv binlog.000001

スレーブが使用するNICの指定(バイナリログ転送による帯域枯渇対策)

スレーブサーバーが複数のNICを持っている場合、マスターとの接続に使用するNICを明示的に指定できるようになりました。明示的に指定するには、CHANGE MASTER TOコマンド実行時に、MASTER_BINDオプションでNICの情報を指定します。バイナリログの転送により帯域が枯渇している場合など、レプリケーション用のNICを用意して明示的に通信を分けることにより、安定してレプリケーションを運用できます。

バイナリログのリモートバックアップ

mysqlbinlogコマンドを使って、リモートサーバーのバイナリログをコピーできるようになりました。バイナリログのコピーは、あるタイミングで存在するバイナリログをコピーする、という使い方だけでなく、最新のバイナリログをコピーし続ける、という使い方も可能です。また、接続先を自ノードに設定すれば、自ノード内でバイナリログをコピーすることもできるため、ディスク障害に備えたバイナリログのバックアップ目的でも使用できます。

[実行例]

- 指定したバイナリログ(binlog.000001～000003)をコピー

mysqlbinlog --read-from-remote-server --host=<ホスト名> --raw binlog.000001 binlog.000002 binlog.000003

- 指定したファイル以降に生成されたバイナリログを全てコピー

mysqlbinlog --read-from-remote-server --host=<ホスト名> --raw --to-last-log binlog.000001

- 指定したファイル以降に生成されたバイナリログを全てコピーし、その後生成されたファイルもコピーし続ける

mysqlbinlog --read-from-remote-server --host=<ホスト名> --raw --stop-never binlog.000001

その他の改善点と、更に進化を続けるMySQL

MySQL 5.6での主要な機能強化点として、InnoDB、オプティマイザ、NoSQL API、パフォーマンス・スキーマ、レプリケーションについて紹介してきましたが、MySQL 5.6での改善点は非常に多くあるため、本記事で紹介しきれなかったトピックも多数あります。また、細かな変更点になるかもしれませんが、TIME/TIMESTAMP/DATETIME型に秒以下の単位を格納できるようになったり、ユーザーのパスワードにポリシーを設定できるようになったり、従来要望が多かった点も色々と改善されています。改善内容を詳細に確認したい場合は、リリースノートやマニュアルに変更内容がまとめられていますので、MySQL 5.6のリリースノートやマニュアルを参照下さい。

また、MySQLの最新バージョンは現在MySQL 5.6ですが、次期バージョンとしてMySQL 5.7の開発が既に始まっており、開発途上版をDMRとして公開しています。MySQL 5.7での機能強化点については、今後の連載でご紹介する予定です。

※本稿において示されている見解は、私自身の見解であって、私の所属するオラクルの見解を必ずしも反映したものではありません。