OceanBaseデータベースは、指定されたパス下のバックアップセットまたはログアーカイブピースの検証をサポートしています。この方法は、クラスタ間でのバックアップデータやコールドスタンバイデータの検証に適しています。
制限事項と注意点
チェックタスクは、バックアップメディアに頻繁にアクセスしてデータを読み取るため、バックアップタスクのネットワークリソースを占有します。そのため、ユーザーテナントがバックアップタスクを実行しておらず、負荷が低い時にチェックタスクを実行することを推奨します。
バックアップチェックの検証レベルを指定する場合:
V4.4.2バージョンでは、V4.4.2 BP2バージョン(V4.4.2 BP2バージョンを除く)以前のバックアップセットおよびログアーカイブピースについては、Basic検証、すなわちファイルの整合性検証はサポートされていません。
V4.3.4バージョン(V4.3.4バージョンを除く)以前のバックアップセットについては、Physical検証、すなわち物理データの正確性および論理的一貫性検証はサポートされていません。
チェック対象のバックアップセットに増分バックアップセットが含まれている場合、Physical検証レベルでは、指定したパスにその増分バックアップセットが依存するフルバックアップセットが含まれている必要があります。そうでない場合、チェックは失敗します。
指定パス下のバックアップセットのチェック
システムテナントがユーザーテナントの指定パス下のバックアップセットに対してバックアップチェックを開始する場合
rootユーザーでクラスタのsysテナントにログインします。接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A以下のコマンドを実行し、ユーザーテナントの指定パス下のバックアップセットに対するチェックを開始します。
ステートメントは以下のとおりです:
ALTER SYSTEM VALIDATE BACKUPSET [= 'backup_set_id[,backup_set_id,...]'] DATA_BACKUP_DEST = 'data_backup_path' [LEVEL = { 'basic' | 'physical' }] TENANT = tenant_name;ステートメント内の関連パラメータの説明は以下のとおりです:
BACKUPSET:チェック対象のバックアップセットを指定します。テナントが指定したバックアップパス下のすべてのバックアップセット、または指定したバックアップセットのリストをチェックすることができます。バックアップセットのリストを指定する場合、複数のバックアップセットのbackup_set_idは半角カンマで区切ります。バックアップセットのbackup_set_idが指定されていない場合、デフォルトでテナントが指定したバックアップパス下のすべてのバックアップセットがチェックされます。クラスタ間やコールドスタンバイデータのシナリオでは、バックアップセットの
backup_set_idはバックアップディレクトリ内のファイル名から取得できます。バックアップディレクトリ構造の詳細については、物理バックアップとリストアの概要のデータバックアップディレクトリを参照してください。注意
backup_set_idを指定しない場合、システムは現在設定されているバックアップパス下のすべてのバックアップセットを取得してチェックするため、多数のチェックタスクが生成され、時間がかかります。すべてのバックアップセットをチェックする必要がない場合は、チェックコマンドでbackup_set_idを指定することを推奨します。DATA_BACKUP_DEST:バックアップセットの保存パスを指定します。注意
OceanBaseデータベースは現在、単一のコマンドで複数のパスを指定することをサポートしていません。そのため、パスを指定した後に
backup_set_idを指定して増分バックアップセットをチェックすると、その増分バックアップセットが依存する他のバックアップセット情報を読み取れないため、エラーが発生する可能性があります。エラーコードは9159です。LEVEL:オプションパラメータで、チェックレベルを表します。指定しない場合、デフォルト値はphysicalです。詳細は以下のとおりです:basic検証:ファイルリストの整合性のみをチェックします。physical検証:物理データの正確性と論理的一致性をチェックします。
TENANT:検証タスクを実行するユーザーテナントを指定します。
例:
システムテナントは、指定されたユーザーテナント
mysqltenantの指定されたバックアップパス下のすべてのバックアップセットに対してBasic検証を開始します。obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE BACKUPSET DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'basic' TENANT = mysqltenant;システムテナントは、指定されたユーザーテナント
mysqltenantの指定されたバックアップパス下でbackup_set_idが1および2のバックアップセットに対してPhysical検証を開始します。obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE BACKUPSET = '1,2' DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'physical' TENANT = mysqltenant;
ステートメントの実行が成功した後、
CDB_OB_BACKUP_VALIDATE_JOBS、CDB_OB_BACKUP_VALIDATE_TASKS、CDB_OB_BACKUP_VALIDATE_JOB_HISTORY、およびCDB_OB_BACKUP_VALIDATE_TASK_HISTORYビューを使用して、検証タスクの状態、進捗状況、および実行結果を確認できます。バックアップ検証の進捗状況を確認する詳細な操作と説明については、バックアップ検証の進捗状況を確認するを参照してください。
バックアップ検証結果を確認する詳細な操作と説明については、バックアップ検証結果を確認するを参照してください。
ユーザーテナントが自身のテナント内の指定パス下のバックアップセットに対してバックアップ検証を開始する
ユーザーテナントのテナント管理者がデータベースにログインします。
説明
MySQLテナントの管理者ユーザーは
rootユーザー、Oracleテナントの管理者ユーザーはSYSユーザーです。接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A以下のコマンドを実行し、指定パス下のバックアップセットの検証を開始します。
ステートメントは以下のとおりです:
ALTER SYSTEM VALIDATE BACKUPSET [= 'backup_set_id[,backup_set_id,...]'] DATA_BACKUP_DEST = 'data_backup_path' [LEVEL = { 'basic' | 'physical' }];ステートメント内の関連パラメータの説明は以下のとおりです:
BACKUPSET:検証対象のバックアップセットを指定します。テナントが指定したバックアップパス下のすべてのバックアップセット、または指定されたバックアップセットリストを検証できます。バックアップセットリストを指定する場合、複数のバックアップセットのbackup_set_idは半角カンマで区切ります。バックアップセットのbackup_set_idが指定されていない場合、デフォルトでテナントが指定したバックアップパス下のすべてのバックアップセットが検証されます。クラスタ間やコールドスタンバイデータのシナリオでは、バックアップセットの
backup_set_idはバックアップディレクトリ内のファイル名から取得できます。バックアップディレクトリ構造の詳細については、物理バックアップとリストアの概要のデータバックアップディレクトリを参照してください。注意
backup_set_idを指定しない場合、システムは現在設定されているバックアップパス下のすべてのバックアップセットを取得して検証するため、多数の検証タスクが生成され、時間がかかります。すべてのバックアップセットを検証する必要がない場合は、検証コマンドでbackup_set_idを指定することを推奨します。DATA_BACKUP_DEST:バックアップセットの保存パスを指定します。注意
OceanBaseデータベースは現在、単一のコマンドで複数のパスを指定することをサポートしていません。そのため、パスを指定した後に
backup_set_idを指定して増分バックアップセットを検証する際、その増分バックアップセットが依存する他のバックアップセット情報を読み取れないため、エラー9159が発生する可能性があります。LEVEL:オプションパラメータで、検証レベルを示します。指定しない場合、デフォルト値はphysicalです。詳細は以下の通りです:basic検証:ファイルリストの整合性のみをチェックします。physical検証:物理データの正確性および論理的一貫性をチェックします。
例:
ユーザーテナントが、自身のテナントで指定されたバックアップパス下のすべてのバックアップセットに対してBasic検証を実行します。
obclient> ALTER SYSTEM VALIDATE BACKUPSET DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'basic';ユーザーテナントが、自身のテナントで指定されたバックアップパス下の
backup_set_idが1、2のバックアップセットに対してPhysical検証を実行します。obclient> ALTER SYSTEM VALIDATE BACKUPSET = '1,2' DATA_BACKUP_DEST = 'file:///data/nfs/backup/data' LEVEL = 'physical';
ステートメントの実行が成功した後、
DBA_OB_BACKUP_VALIDATE_JOBS、DBA_OB_BACKUP_VALIDATE_TASKS、DBA_OB_BACKUP_VALIDATE_JOB_HISTORYおよびDBA_OB_BACKUP_VALIDATE_TASK_HISTORYビューを使用して、検証タスクの状態、進捗状況、および実行結果を確認できます。バックアップ検証の進捗状況を確認する詳細な操作と説明については、バックアップ検証の進捗状況を確認するを参照してください。
バックアップ検証結果を確認する詳細な操作と説明については、バックアップ検証結果を確認するを参照してください。
指定パスのログアーカイブピースの検証
システムテナントがユーザーテナントの指定パスのログアーカイブピースに対してバックアップ検証を開始する
rootユーザーでクラスタのsysテナントにログインします。接続例は以下のとおりです。データベースへの接続時は、実際の環境に準じてください。
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A以下のコマンドを実行し、ユーザーテナントの指定パス下のログアーカイブピースに対する検証を開始します。
ステートメントは以下のとおりです:
ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE [= 'piece_id[,piece_id,...]'] LOG_ARCHIVE_DEST = 'log_archive_path' [LEVEL = { 'basic' | 'physical' }] TENANT = tenant_name;ステートメント内の関連パラメータの説明は以下のとおりです:
ARCHIVELOG_PIECE:検証対象のログアーカイブピースを指定します。テナントが指定したアーカイブパス下のすべてのアーカイブピース、または指定されたアーカイブピースリストを検証できます。アーカイブピースリストを指定する場合、複数のpiece_idを半角カンマで区切ります。piece_idが指定されていない場合、デフォルトでテナントが指定したアーカイブパス下のすべてのログアーカイブピースを検証します。クラスタ間やコールドスタンバイデータのシナリオでは、ログアーカイブピースの
piece_idはアーカイブディレクトリ内のファイル名から取得できます。アーカイブディレクトリ構造の詳細については、物理バックアップとリストアの概要 の ログアーカイブディレクトリ を参照してください。注意
piece_idを指定しない場合、システムは指定されたアーカイブパス下のすべてのアーカイブピースを取得して検証するため、多数の検証タスクが生成され、時間がかかります。すべてのアーカイブピースを検証する必要がない場合は、検証コマンドでpiece_idを指定することを推奨します。LOG_ARCHIVE_DEST:ログアーカイブピースの保存先パスを指定します。LEVEL:オプションパラメータで、検証レベルを表します。指定しない場合、デフォルト値はphysicalです。詳細は以下のとおりです:basic検証:ファイルリストの整合性のみをチェックします。physical検証:物理データの正確性と論理的一致性をチェックします。
TENANT:検証タスクを実行するユーザーテナントを指定するために使用します。
例:
システムテナントが指定アーカイブパス下のすべてのアーカイブピースに対してBasic検証を開始します。
obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'basic' TENANT = tenant1;システムテナントが指定アーカイブパス下の
piece_idが1、2のログアーカイブピースに対してPhysical検証を開始します。obclient(root@sys)[(none)]> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE = '1,2' LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'physical' TENANT = tenant1;
ステートメントの実行が成功すると、
CDB_OB_BACKUP_VALIDATE_JOBS、CDB_OB_BACKUP_VALIDATE_TASKS、CDB_OB_BACKUP_VALIDATE_JOB_HISTORY、およびCDB_OB_BACKUP_VALIDATE_TASK_HISTORYビューを使用して、検証タスクの状態、進捗状況、および実行結果をそれぞれ確認できます。バックアップ検証の進捗状況を確認する詳細な操作と説明については、バックアップ検証の進捗状況を確認する を参照してください。
バックアップ検証結果の詳細な操作と紹介については、バックアップ検証結果の確認を参照してください。
ユーザーテナントが自身のテナント内で指定されたパスのログアーカイブPieceに対してバックアップ検証を開始する
ユーザーテナントのテナント管理者がデータベースにログインします。
説明
MySQLテナントの管理者ユーザーは
rootユーザー、Oracleテナントの管理者ユーザーはSYSユーザーです。接続例は以下の通りです。データベースへの接続時は、実際の環境に準じてください。
obclient -h10.xx.xx.xx -P2883 -uroot@mysql001#obdemo -p***** -A以下のコマンドを実行し、指定されたパス下のログアーカイブPieceの検証を開始します。
ステートメントは以下の通りです:
ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE [= 'piece_id[,piece_id,...]'] LOG_ARCHIVE_DEST = 'log_archive_path' [LEVEL = { 'basic' | 'physical' }];ステートメント内の関連パラメータの説明は以下の通りです:
ARCHIVELOG_PIECE:検証対象のログアーカイブPieceを指定します。テナントの現在のアーカイブパス下のすべてのアーカイブPieceまたは指定されたアーカイブPieceリストを検証できます。アーカイブPieceリストを指定する場合、複数のpiece_idは半角カンマで区切ります。piece_idを指定しない場合、デフォルトでテナントの現在のアーカイブパス下のすべてのログアーカイブPieceが検証されます。クラスタ間やコールドスタンバイデータのシナリオでは、ログアーカイブPieceの
piece_idはアーカイブディレクトリ内のファイル名から取得できます。アーカイブディレクトリ構造の詳細については、物理バックアップとリストアの概要のログアーカイブディレクトリを参照してください。注意
piece_idを指定しない場合、システムは指定されたアーカイブパス下のすべてのアーカイブPieceを取得して検証するため、多数の検証タスクが生成され、時間がかかります。すべてのアーカイブPieceを検証する必要がない場合は、検証コマンドでpiece_idを指定することをお勧めします。LOG_ARCHIVE_DEST:ログアーカイブPieceの保存先パスを指定します。LEVEL:オプションパラメータで、検証レベルを表します。指定しない場合、デフォルト値はphysicalです。詳細は以下の通りです:basic検証:ファイルリストの整合性のみをチェックします。physical検証:物理データの正確性と論理的一致性をチェックします。
例:
ユーザーテナントが自身のテナント内で指定されたアーカイブパス下のすべてのアーカイブPieceに対してBasic検証を開始します。
obclient> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'basic';ユーザーテナントが自身のテナント内で指定されたアーカイブパス下の
piece_idが1、2のログアーカイブPieceに対してPhysical検証を開始します。obclient> ALTER SYSTEM VALIDATE ARCHIVELOG_PIECE = '1,2' LOG_ARCHIVE_DEST = 'file:///data/nfs/backup/archive' LEVEL = 'physical';
ステートメントの実行が成功した後、
DBA_OB_BACKUP_VALIDATE_JOBS、DBA_OB_BACKUP_VALIDATE_TASKS、DBA_OB_BACKUP_VALIDATE_JOB_HISTORY、およびDBA_OB_BACKUP_VALIDATE_TASK_HISTORYビューを使用して、検証タスクの状態、進捗状況、および実行結果を確認できます。バックアップ検証の進捗状況を確認する詳細な操作と説明については、バックアップ検証の進捗状況を確認するを参照してください。
バックアップ検証結果を確認する詳細な操作と説明については、バックアップ検証結果を確認するを参照してください。