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

2014年1月23日(木)
山﨑 由章

レプリケーション:耐障害性、信頼性の向上

GTIDとレプリケーションユーティリティ

複数台でレプリケーションを構成している場合の運用管理を簡素化するために、GTID(グローバルトランザクションID)が実装されました。GTIDはトランザクションを一意に識別できる識別子です。従来のレプリケーションではバイナリログのポジションの情報を使ってレプリケーションがどこまで伝搬されたのかを管理しているため、スレーブを新しいマスターに昇格させる場合などにポジションの情報を確認する必要があり、確認作業が煩雑になっていました。

図2:グローバルトランザクションID(クリックで拡大)

GTIDを使うと、この課題を解決できます。GTIDにより、スレーブが既に実行完了したトランザクションを一意に識別できるようになったため、ポジションの情報を確認することなくスレーブを新しいマスターに昇格させることが可能です。また、GTIDを使ってレプリケーションを運用している場合に、フェイルオーバーを自動化できるmysqlfailoverや計画停止時のスイッチオーバー/スイッチバックを実現できるmysqlrpladminといったレプリケーションユーティリティも用意しています。これらのユーティリティの実体は、pythonでかかれたスクリプトのため、スクリプトをカスタマイズして活用頂くことも可能です。

GTIDを使ったレプリケーションの詳細については、こちらを参照下さい。

クラッシュセーフなスレーブ

レプリケーション実行時、どこまでバイナリログを伝搬したかというポジションの情報や、伝搬されたログファイルの内容をどこまでスレーブに反映したかというポジションの情報は、データベースのデータを格納するファイルとは別のファイルに記録されています。そのため、データベース上のデータとポジションの情報は同時に変更できません。
それにより、スレーブのサーバーにおいてクラッシュが発生した場合に、データは更新されたがポジションの情報は更新されていない、という不整合が発生する可能性があります。この場合、不整合を取り除かないとレプリケーションを再開できないため、ポジションの情報を修正してからレプリケーションを再開したり、スレーブを再構築したりする必要があります。

この問題を解決するために、MySQL 5.6ではポジションの情報をInnoDB上のテーブルに記録し、データの変更とポジション情報の変更をトランザクショナルに書き込みできるようにしました。これにより、スレーブサーバーがクラッシュした場合でも、データとポジションの情報の整合性を保つことができ、スレーブをクラッシュセーフな状態にできます。

スレーブをクラッシュセーフな状態にするためには、以下のパラメータを設定します。

-	relay_log_info_repository=TABLE

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

-	relay_log_recovery=ON

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

チェックサムの追加

バイナリログが破損した場合に破損を検出し易くするために、バイナリログにチェックサムを追加できるようになりました(厳密には、追加できる誤り訂正符号はチェックサムではなくCRC32になります)。

チェックサムはデフォルトで追加されています。チェックサムを無効化したい場合は、以下のパラメータを設定します。

-	binlog_checksum=NONE

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

日本オラクル株式会社

MySQLのセールスコンサルタント。元々はOracleデータベースのコンサルティング、サポート等に従事していたが、オープンソースとフリーソフトウェア(自由なソフトウェア)の世界に興味を持ち、MySQLの仕事を始める。趣味は旅行と美味しいものを食べること。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています