MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
バックアップを開始する前に、バックアップを実行するためにクラスタが適切に構成されていることを確認します。 (セクション23.5.8.3「NDB Cluster バックアップの構成」を参照してください。)
START BACKUP コマンドは、バックアップを作成するために使用されます。
START BACKUP [backup_id] [encryption_option] [wait_option] [snapshot_option]encryption_option: ENCRYPT PASSWORD=passwordpassword: {'password_string' | "password_string"}wait_option: WAIT {STARTED | COMPLETED} | NOWAITsnapshot_option: SNAPSHOTSTART | SNAPSHOTEND
連続したバックアップは自動的に順次識別されるため、backup_id (1 以上の整数) はオプションです。これを省略すると、次に使用可能な値が使用されます。 既存の backup_id 値が使用されると、 Backup failed: file already existsというエラーでバックアップに失敗します。 これを使用する場合は、その他のオプションを使用する前に、START BACKUP の直後に backup_id を指定する必要があります。
NDB 8.0.22 以降では、ENCRYPT PASSWORD= を使用した暗号化バックアップの作成がサポートされています。passwordpassword は、次の要件をすべて満たす必要があります:
!, ', ", $, %, \および ^ 以外の印刷可能な ASCII 文字を使用
256 文字以下
一重引用符または二重引用符で囲みます
空のパスワード (''または"") を使用することは可能ですが、お薦めしません。
暗号化バックアップは、次のいずれかのコマンドを使用して復号化できます:
ndb_restore --decrypt --backup-password=
password
ndbxfrm --decrypt-password= passwordinput_file output_file
ndb_print_backup_file -P password file_name
必要な追加オプションなどの詳細は、これらのプログラムの説明を参照してください。
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 がデフォルトであり、以前の NDB Cluster リリースで検出された動作と一致します。
START BACKUP を付けて SNAPSHOTSTART を使用するときに、CompressedBackup パラメータが有効になっている場合、データファイルおよび制御ファイルのみが圧縮され、ログファイルは圧縮されません。
wait_option と snapshot_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
バックアップを作成する手順は、次のステップで構成されます。
管理クライアント (ndb_mgm) がまだ実行されていない場合は、起動します。
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>
バックアップが開始されると、次のメッセージが管理クライアントに表示されます。
Backupbackup_idstarted from nodenode_id
backup_id は、特定のバックアップを表す一意の識別子です。 ほかに構成されていない場合、この識別子はクラスタログに保存されます。node_id は、データノードとバックアップを調整する管理サーバーの識別子です。 バックアッププロセスのこの時点で、クラスタはバックアップリクエストを受信して処理しています。 バックアップが終了したことを意味するわけではありません。 次に、このステートメントの例を示します。
Node 2: Backup 1 started from node 1
管理クライアントは、次のようなメッセージでバックアップが開始されたことを示します。
Backupbackup_idstarted from nodenode_idcompleted
バックアップが開始されたことを示す通知の場合も同様に、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 を指定する必要があります。
クラスタのバックアップは、デフォルトで各データノード上の DataDir の BACKUP サブディレクトリに作成されます。 これは、1 つ以上のデータノードごとに個別にオーバーライドすることも、BackupDataDir 構成パラメータを使用することで、config.ini ファイル内のすべてのクラスタデータノードに対してオーバーライドすることもできます。 特定の backup_id を持つバックアップ用に作成されたバックアップファイルは、バックアップディレクトリ内の BACKUP- という名前のサブディレクトリに格納されます。
backup_id
バックアップの取消し. すでに進行中のバックアップを取り消すか中断するには、次のステップを実行します:
管理クライアントを起動します。
次のコマンドを実行します。
ndb_mgm> ABORT BACKUP backup_id
数値 backup_id は、バックアップが開始されたときに管理クライアントの応答 (「Backup メッセージ内) に含まれていたバックアップの識別子です。
backup_id started from node management_node_id」
管理クライアントは、Abort of backup で中断リクエストを確認します。
backup_id ordered
この時点で、管理クライアントはまだクラスタデータノードからこのリクエストへの応答を受信していないため、実際にはバックアップはまだ中止されていません。
バックアップが中断されると、管理クライアントは次のような方法でこの事実を報告します:
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 を持つバックアップが実行されていない場合は、管理クライアントが応答することも、クラスタログに無効な中止コマンドが送信されたことが表示されることもありません。