MySQL Clusterのバックアップ/リストアの仕組み

2015年8月25日(火)
山﨑 由章

本連載では、実際に「MySQL Cluster」を利用するためのチュートリアルとなるように、その特徴と基本的なアーキテクチャからインストール方法、基本的な操作などをコマンド付きで解説していきます。第4回の今回は、MySQL Clusterのバックアップ/リストアの仕組みや関連するパラメータ等について解説します。

MySQL Clusterがデータを永続化する仕組み

MySQL Clusterのバックアップ/リストアの仕組みについて解説する前に、まずMySQL Clusterがどのようにデータを永続化しているかを解説します。MySQL Clusterでは、「LCP」と「GCP」と呼ばれる2つのチェックポイント処理によってデータをディスクに書き込んで永続化しています。

LCP(Local CheckPoint):1台のデータノードでのチェックポイント処理

データノード毎に、定期的にLCPが実行されます。データノード1台の中で完結した処理であるため、「ローカル」チェックポイントと呼ばれています。LCPが実行されると、データノードのメモリ上にあるすべてのデータ(DataMemory上のデータ)がディスクに書き込まれます(IndexMemory上のデータはディスクに書き込まれない。また、IndexMemory上のデータはデータノード起動時にLCPのデータから再作成されるため、ディスク上に永続化する必要はない)。

GCP(Global CheckPoint):全データノードで同期を取ったチェックポイント処理

全データノードで同期を取り、随時GCPが実行されます。GCPはLCPよりも細かい間隔で実行され、連続的に更新された内容をログに書き続けます。GCPでは一定周期毎の更新内容を「Epoch(エポック)」と呼ばれる単位にまとめ、REDOログとして記録します。全データノードで同期が取られているため、「同じEpochのGCPは、同じ時間帯に更新された内容」となります。

LCPとGCPによるデータの復元

LCPはある一時点でのデータ全体であり、GCPはLCPとLCPの間の差分です。そのため、MySQL ClusterはまずLCPを読み込み、そこへGCPを適用することによって最新のデータを復元します。

LCPとGCPの関係についてイメージしたものを図1に示します。

LCPとGCPの関係

図1:LCPとGCPの関係

バックアップ/リストアの仕組み

MySQL Clusterには、ネイティブなオンラインバックアップ機能があるため、通常運用時はこの機能を利用してオンラインバックアップを取得します。オンラインバックアップを実行すると、LCPのようにデータ全体(テーブルレコード全体)をバックアップとして取得します。さらに、バックアップ取得中に実行されたトランザクションによる変更もログファイルとして取得することで、ある一時点(あるEpoch時点)における一貫性のあるデータをオンラインバックアップできます。

また、MySQL Clusterでは、基本的に通常のMySQL Serverで用いられるmysqldumpではバックアップを取得できません。SQLノードが複数ある場合に、あるSQLノードから他のSQLノードへ行われる更新をブロックできず、全ノードにおけるデータの整合性が保証できないためです。

しかし、シングルユーザーモードを活用することで、mysqldumpによるバックアップも取得可能です。シングルユーザーモードでは、データノードにアクセスするSQLノードを1台に限定できるため、他のSQLノードからの更新を防げます。メンテナンス時間帯や初期環境構築時などであれば、一旦シングルユーザーモードに切り替えることでmysqldumpによるバックアップを取得できるのです。

バックアップの仕組み

オンラインバックアップは、管理ノードからSTART BACKUPコマンドを実行することで取得できます。START BACKUPコマンドを実行すると、図2のように各データノードのBackupDataDirで設定したディレクトリにフルバックアップが取得されます(BackupDataDirの説明は後述)。

オンラインバックアップのイメージ

図2:オンラインバックアップのイメージ

BackupDataDir配下に取得されるバックアップファイルは3種類あります。それぞれのファイル名と内容は、表1の通りです。

表1:MySQL Clusterのバックアップファイルの種類

ファイル名 内容
BACKUP-..ctl テーブル定義等のメタデータ
BACKUP--0..data データノードが保持しているデータ
BACKUP-..log バックアップ取得中に実行されたトランザクションによる変更

MySQL Clusterのオンラインバックアップは、フルバックアップのみ取得可能です。差分/増分バックアップは取得できません。差分/増分バックアップを用いたい場合は、バイナリログを差分/増分ログとして用いる必要があります。

MySQL Clusterにおけるバイナリログの扱いは、通常のMySQL Serverと異なる点があります。これらについては、今後の連載で解説予定です。

リストアの仕組み

リストアには、ndb_restoreという専用のコマンドを用います。通常は図3のようにバックアップファイルをデータノード以外のどこかのサーバ1台に集約し、そのサーバからndb_restoreコマンドを実行してリストアを行います。

リストアのイメージ

図3:リストアのイメージ

なぜバックアップファイルをデータノード以外に集約しておくかというと、データノードに障害が発生した時に、バックアップファイルにアクセスできなくなることを防ぐためです。

また、データノード毎にバックアップファイルを復元する仕組みになっていないのは、データノード数の増減にも対応するためです。例えば、図4のようにデータノードが4台の構成で、運用中にあるノードグループを構成するサーバ2台に障害が発生し、それらのサーバをすぐに復旧できなかった場合を想定します。この場合、リストアの仕組みがデータノード数に依存する仕組みになっている場合は、障害が発生した2台のサーバが復旧できるまでリストアを開始できません。しかし、実際にはリストアの仕組みはデータノード数に依存しないため、障害が発生した2台のサーバの復旧を待たずして、障害が発生していないサーバ2台に対してバックアップをリストアし、縮退運転でシステムを再開することもできます。

データノード数が減少した構成でのリストアイメージ

図4:データノード数が減少した構成でのリストアイメージ

バックアップ、リストア関連のパラメータ

ここでは、バックアップ、リストア関連の主要なパラメータについて解説します。第3回の記事で解説した通り、各パラメータの再起動タイプ、デフォルト値などの詳細は、マニュアルを参照してください。

BackupDataDir

バックアップが格納されるディレクトリを指定します。実際には、BackupDataDirで指定したディレクトリ上にBACKUPというサブディレクトリが作成され、その中にバックアップファイルが格納されます。
 

CompressedBackup

バックアップファイルを圧縮します。使用される圧縮は"gzip --fast"と同等であり、圧縮しない場合に比べて50%以下のサイズになると言われています。圧縮を有効にすると、I/O帯域やディスクスペースを節約できますが、その分バックアップ取得中およびリストア処理実行中のCPU負荷は高くなります。
 

BackupDataBufferSize

MySQL Clusterにはバックアップ専用のバッファが2つあり、これはその1つで、データを格納するための領域です。大半のプロジェクトではこの値はデフォルト値で問題ありません。
 

BackupLogBufferSize

バックアップ専用のバッファのうち、バックアップ取得中に行われたテーブルへの変更ログを記録するための領域です。大半のプロジェクトではこの値はデフォルト値で問題ありませんが、更新処理が多い環境ではこのパラメータが小さいとバックアップの取得に失敗することがあります。本パラメータの不足によりバックアップ取得が失敗するようであれば、設定値を拡張してエラーを回避してください。
 

BackupMemory

バックアップ専用バッファのサイズで、単純にBackupDataBufferSizeとBackupLogBufferSizeの合計値です。このパラメータは自動的には設定されないため、BackupDataBufferSizeやBackupLogBufferSizeを変更した場合には、それらに合わせてBackupMemoryも変更する必要がありますので、注意してください。
 

BackupWriteSize

バックアップをディスクに書き込む最小の単位です。細か過ぎる単位でディスクに書き込むより、ある程度まとまった単位でディスクに書き込むほうがシーケンシャルなアクセスになるため、高速化が期待できます。バックアップを書き込むストレージのI/O性能やI/O特性よっても最適値が異なるため、本番運用前にベンチマークを行ってチューニングしておくことが望ましいです。
 

BackupWriteSizeの設定は、バックアップだけでなくLCPにも適用されるため、通常稼働時(オンラインバックアップを取得していない時)の性能にも影響します。また、このパラメータを調整する時は、以下の関係が有効である必要があります。以下の関係が有効でない場合はデータノードを起動できません。

  • BackupDataBufferSize >= BackupWriteSize + 188Kバイト
  • BackupLogBufferSize >= BackupWriteSize + 16Kバイト
  • BackupMaxWriteSize >= BackupWriteSize

BackupMaxWriteSize

バックアップをディスクに書き込みしている間にも、バックアップ専用バッファには随時データが溜まっていきます。そのため、ディスクへの書き込みに時間がかかる場合には、BackupWriteSize以上に書き込めていないデータが溜まることがあります。その場合に、最大でどの程度まとめて書き込むかを指定します。
 

おわりに

今回は、MySQL Clusterのバックアップ/リストアの仕組みや関連するパラメータ等について解説しました。第5回では、MySQL Clusterのバックアップ/リストアの具体例について解説する予定です。

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

日本オラクル株式会社

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

連載バックナンバー

データベース技術解説

MySQL Clusterにおけるチューニングの基礎

2015/12/10
第9回の今回は、MySQL Clusterにおけるチューニングの基礎について解説します。
データベース技術解説

MySQL Clusterにおけるレプリケーション環境構築例

2015/11/19
MySQL Clusterにおけるレプリケーション環境構築の具体例について解説します。

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

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

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

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