Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 20.9Mb
PDF (A4) - 21.0Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  MySQL Cluster 管理クライアントを使用したバックアップの作成

18.5.3.2 MySQL Cluster 管理クライアントを使用したバックアップの作成

バックアップを開始する前に、バックアップを実行するためにクラスタが適切に構成されていることを確認します。(セクション18.5.3.3「MySQL Cluster バックアップ用の構成」を参照してください。)

START BACKUP コマンドは、バックアップを作成するために使用されます。

START BACKUP [backup_id] [wait_option] [snapshot_option]

wait_option:
WAIT {STARTED | COMPLETED} | NOWAIT

snapshot_option:
SNAPSHOTSTART | SNAPSHOTEND

連続したバックアップは自動的に順次識別されるため、backup_id (1 以上の整数) はオプションです。これを省略すると、次に使用可能な値が使用されます。既存の backup_id 値が使用されると、 Backup failed: file already existsというエラーでバックアップに失敗します。これを使用する場合は、その他のオプションを使用する前に、START BACKUP の直後に backup_id を指定する必要があります。

wait_option を使用すると、次のリストに示すように、START BACKUP コマンドを発行したあとに、管理クライアントに制御が返されるタイミングを判断できます。

  • NOWAIT を指定すると、すぐに次に示すようなプロンプトが管理クライアントに表示されます。

    ndb_mgm> START BACKUP NOWAIT
    ndb_mgm>

    この場合、バックアッププロセスから進行状況の情報が出力されている間でも、管理クライアントを使用できます。

  • WAIT STARTED を指定すると、次に示すように、管理クライアントはバックアップが開始されるまで待機してから、ユーザーに制御を返します。

    ndb_mgm> START BACKUP WAIT STARTED
    Waiting for started, this may take several minutes
    Node 2: Backup 3 started from node 1
    ndb_mgm>
  • WAIT COMPLETED を指定すると、管理クライアントはバックアッププロセスが完了するまで待機してから、ユーザーに制御を返します。

WAIT COMPLETED はデフォルトです。

snapshot_option を使用すると、START BACKUP が発行されたとき、またはそれが完了したときのクラスタの状態とバックアップが一致するかどうかを判断できます。SNAPSHOTSTART を使用すると、バックアップがバックアップを開始したときのクラスタの状態と一致します。SNAPSHOTEND を使用すると、バックアップはバックアップが終了したときのクラスタの状態を反映します。SNAPSHOTEND はデフォルトであり、以前の MySQL Cluster リリースで見られた動作と一致します。

注記

START BACKUP を付けて SNAPSHOTSTART を使用するときに、CompressedBackup パラメータが有効になっている場合、データファイルおよび制御ファイルのみが圧縮され、ログファイルは圧縮されません。

wait_optionsnapshot_option の両方を使用する場合、それらはいずれの順序でも指定できます。たとえば、ID として 4 を持つ既存のバックアップが存在しないと仮定すると、次のコマンドはすべて有効です。

START BACKUP WAIT STARTED SNAPSHOTSTART
START BACKUP SNAPSHOTSTART WAIT STARTED
START BACKUP 4 WAIT COMPLETED SNAPSHOTSTART
START BACKUP SNAPSHOTEND WAIT COMPLETED
START BACKUP 4 NOWAIT SNAPSHOTSTART

バックアップを作成する手順は、次のステップで構成されます。

  1. 管理クライアント (ndb_mgm) がまだ実行されていない場合は、起動します。

  2. START BACKUP コマンドを実行します。これにより、次に示すように、バックアップの進行状況を示す複数行の出力が生成されます。

    ndb_mgm> START BACKUP
    Waiting for completed, this may take several minutes
    Node 2: Backup 1 started from node 1
    Node 2: Backup 1 started from node 1 completed
     StartGCP: 177 StopGCP: 180
     #Records: 7362 #LogRecords: 0
     Data: 453648 bytes Log: 0 bytes
    ndb_mgm>
  3. バックアップが開始されると、次のメッセージが管理クライアントに表示されます。

    Backup backup_id started from node node_id

    backup_id は、特定のバックアップを表す一意の識別子です。ほかに構成されていない場合、この識別子はクラスタログに保存されます。node_id は、データノードとバックアップを調整する管理サーバーの識別子です。バックアッププロセスのこの時点で、クラスタはバックアップリクエストを受信して処理しています。バックアップが終了したことを意味するわけではありません。次に、このステートメントの例を示します。

    Node 2: Backup 1 started from node 1
  4. 管理クライアントは、次のようなメッセージでバックアップが開始されたことを示します。

    Backup backup_id started from node node_id completed

    バックアップが開始されたことを示す通知の場合も同様に、backup_id は、この特定のバックアップを表す一意の識別子であり、node_id は、データノードとバックアップを調整する管理サーバーのノード ID です。この出力には、次に示すように、関連するグローバルチェックポイント、バックアップされたレコードの数、およびデータのサイズを含む追加情報が記載されます。

    Node 2: Backup 1 started from node 1 completed
     StartGCP: 177 StopGCP: 180
     #Records: 7362 #LogRecords: 0
     Data: 453648 bytes Log: 0 bytes

また、次の例に示すように、-e または --execute オプションを付けて ndb_mgm を呼び出して、システムシェルからバックアップを実行することもできます。

shell> ndb_mgm -e "START BACKUP 6 WAIT COMPLETED SNAPSHOTSTART"

この方法で START BACKUP を使用する際は、バックアップ ID を指定する必要があります。

クラスタのバックアップは、デフォルトで各データノード上の DataDirBACKUP サブディレクトリに作成されます。これは、1 つ以上のデータノードごとに個別にオーバーライドすることも、BackupDataDir 構成パラメータを使用することで、config.ini ファイル内のすべてのクラスタデータノードに対してオーバーライドすることもできます。特定の backup_id を持つバックアップ用に作成されたバックアップファイルは、バックアップディレクトリ内の BACKUP-backup_id という名前のサブディレクトリに格納されます。

すでに進行中のバックアップを中止するには:

  1. 管理クライアントを起動します。

  2. 次のコマンドを実行します。

    ndb_mgm> ABORT BACKUP backup_id

    数値 backup_id は、バックアップが開始されたときに管理クライアントの応答 (「Backup backup_id started from node management_node_id」メッセージ内) に含まれていたバックアップの識別子です。

  3. 管理クライアントは、「Abort of backup backup_id ordered」で中止リクエストを承認します。

    注記

    この時点で、管理クライアントはまだクラスタデータノードからこのリクエストへの応答を受信していないため、実際にはバックアップはまだ中止されていません。

  4. バックアップが中止されると、管理クライアントは次に示すものと同様の方法で、このことをレポートします。

    Node 1: Backup 3 started from 5 has been aborted. 
      Error: 1321 - Backup aborted by user request: Permanent error: User defined error
    Node 3: Backup 3 started from 5 has been aborted. 
      Error: 1323 - 1323: Permanent error: Internal error
    Node 2: Backup 3 started from 5 has been aborted. 
      Error: 1323 - 1323: Permanent error: Internal error
    Node 4: Backup 3 started from 5 has been aborted. 
      Error: 1323 - 1323: Permanent error: Internal error

    この例では、4 つのデータノードを持つクラスタのサンプル出力を示します。ここで、中止されるバックアップのシーケンス番号は 3 で、クラスタ管理クライアントが接続される管理ノードのノード ID は 5 です。バックアップの中止時にその役割を最初に完了したノードは、中止の理由がユーザーからのリクエストのためであったことをレポートします。(残りのノードは、不明な内部エラーが原因でバックアップが中止されたことをレポートします。)

    注記

    クラスタノードが特定の順序で ABORT BACKUP コマンドに応答する保証はありません。

    「Backup backup_id started from node management_node_id has been aborted」というメッセージは、バックアップが終了し、このバックアップに関連するすべてのファイルがクラスタファイルシステムから削除されたことを示しています。

このコマンドを使用すると、システムシェルから進行中のバックアップを中止することもできます。

shell> ndb_mgm -e "ABORT BACKUP backup_id"
注記

ABORT BACKUP の発行時に、ID backup_id を持つバックアップが実行されていない場合は、管理クライアントが応答することも、クラスタログに無効な中止コマンドが送信されたことが表示されることもありません。