バックアップが正常に完了すると、業務ニーズに応じてテナントのクリーンアップ戦略を設定できます。クリーンアップ戦略が設定されたテナントは、毎時間1回の自動クリーンアップが実行され、期限切れのバックアップやアーカイブデータが直ちにクリーンアップされます。
注意事項
ログアーカイブデータのクリーンアップはデータのバックアップに依存しているため、ログアーカイブデータをクリーンアップする前に、既存のデータバックアップファイルがあることを確認してください。データバックアップファイルがない場合、ログアーカイブデータをクリーンアップできません。
自動クリーンアップは、
DATA_BACKUP_DESTおよびLOG_ARCHIVE_DESTで現在指定されているパス配下のバックアップまたはアーカイブデータのみを対象とし、使用されなくなったバックアップパスやアーカイブパス内のデータはクリーンアップしません。バックアップ先またはアーカイブ先を変更したシナリオでは、元のバックアップパスまたはアーカイブパス配下のデータは手動でのみクリーンアップできます。バックアップまたはアーカイブデータを手動でクリーンアップする詳細な操作と説明については、指定したバックアップまたはアーカイブデータを手動でクリーンアップするおよびバックアップパスまたはアーカイブパスを手動で空にするを参照してください。
自動クリーンアップは有効なバックアップデータを少なくとも1つ保持します。有効なバックアップデータが1つしかない場合、その有効なデータはクリーンアップされません。
バックアップメディアによって、バックアップまたはアーカイブデータの自動クリーンアップの結果は異なります：
- バックアップメディアがNFSまたはS3互換のオブジェクトストレージ(OBS、GCSなど)の場合、バックアップデータのクリーンアップ時に、システムは要件を満たすバックアップファイルを直接削除します。
- バックアップ先がS3/COS(S3プロトコルアクセス)の場合、バックアップファイルのクリーンアップ方法は、
data_backup_destおよびlog_archive_destのdelete_modeパラメータの値によって決まります。このパラメータの詳細については、SET LOG_ARCHIVE_DESTおよびSET DATA_BACKUP_DESTを参照してください。
特に、パス属性で
enable_worm=trueパラメータが設定されている場合、バックアップまたはアーカイブデータの自動クリーンアップ時に、システムはRECOVERY_WINDOWで指定された時間に基づいて条件を満たすバックアップまたはアーカイブデータを選択してクリーンアップします。ただし、最終的にクリーンアップが成功するかどうかは、そのパスに対応するクリーンアップモード(delete_modeパラメータの値)および対応するBucketの保持戦略に関係します。注意
enable_worm=trueパラメータは、コンプライアンス保持戦略(WORM)が有効なシナリオに適用されます。例えば、あるバックアップセットが
RECOVERY_WINDOWで指定された時間外にあるものの、まだWORM(Write Once Read Many)保持期間内である場合：当該バックアップセットのクリーンアップモードが
deleteの場合、OceanBaseデータベースはバックアップセットのクリーンアップに失敗します。クリーンアップは、当該オブジェクトの保持期間が経過した後にのみ実行可能です。そのバックアップセットのクリーンアップモードが
taggingの場合、OceanBaseデータベースはそのバックアップセットにタグを付け、最終的にオブジェクトストレージがライフサイクルを終え、WORM保持期間が過ぎた後に削除を実行します。
システムテナントが指定ユーザーテナントにクリーンアップ戦略を設定する
rootユーザーでクラスタのsysテナントにログインします。クリーンアップ戦略を設定します。これは、テナントの自動クリーンアップ機能を有効にすることに相当します。
ステートメントは以下のとおりです：
ALTER SYSTEM ADD DELETE BACKUP POLICY [=] policy_name RECOVERY_WINDOW [=] recovery_window TENANT [=] tenant_name;このうち：
policy_name：指定するクリーンアップ戦略の名前です。サポートされている値は以下のとおりです：default：自動クリーンアップの対象範囲は、テナントの現在のDATA_BACKUP_DESTおよびLOG_ARCHIVE_DESTパラメータで指定されたパス下のバックアップデータとアーカイブデータに限定されます。log_only：自動クリーンアップの対象範囲は、テナントの現在のLOG_ARCHIVE_DESTパラメータで設定されたアーカイブパス内のログに限定されます。データバックアップはなく、ログアーカイブのみが有効な場合に適用されます。クリーンアップ戦略をlog_onlyに設定する場合、当該テナントの現在のDATA_BACKUP_DESTパラメータの値は空である必要があります。つまり、データバックアップの出力先は設定されていない状態である必要があります。同様に、クリーンアップ戦略をlog_onlyに設定した場合、DATA_BACKUP_DESTパラメータでバックアップの出力先を設定することはできません。
recovery_windowパラメータは、バックアップデータのリストア可能時間窓を制御します。このパラメータの詳細については、recovery_window パラメータの紹介を参照してください。TENANTパラメータは、クリーンアップ戦略が適用されるテナントを指定するために使用されます。ユーザーテナントのテナント名を指定する必要があり、現在は1つのテナント名のみの指定をサポートしています。
注意
現在、クリーンアップ戦略はテナントレベルでのみ設定でき、クラスタレベルでは設定できません。各コマンドは1つのテナントに対して1つのクリーンアップ戦略のみを設定できます。
例：
システムテナントが
mysql001テナントにクリーンアップ戦略を指定するobclient(root@sys)[(none)]> ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d' TENANT mysql001;システムテナントが
oracle001テナントにクリーンアップ戦略を指定するobclient(root@sys)[(none)]> ALTER SYSTEM ADD DELETE BACKUP POLICY 'log_only' RECOVERY_WINDOW '7d' TENANT oracle001;
説明
自動クリーンアップタスクは、バックグラウンドシステムによって毎時定期的にトリガーされます。そのため、クリーンアップ戦略の設定完了後、対応するクリーンアップタスクが確認できるまでには、しばらくの時間（1時間以内）を要する場合があります。
設定済みのクリーンアップ戦略を確認します。
設定が成功すると、
oceanbase.CDB_OB_BACKUP_DELETE_POLICYビューですべてのテナントのクリーンアップ戦略を確認できます。obclient(root@sys)[oceanbase]> SELECT TENANT_ID, POLICY_NAME, RECOVERY_WINDOW FROM oceanbase.CDB_OB_BACKUP_DELETE_POLICY;クエリ結果は次のとおりです：
+-----------+-------------+-----------------+ | TENANT_ID | POLICY_NAME | RECOVERY_WINDOW | +-----------+-------------+-----------------+ | 1002 | default | 7d | | 1004 | log_only | 7d | +-----------+-------------+-----------------+ 2 rows in set
ユーザーテナントが自身のテナントに対するクリーンアップ戦略を設定する
ユーザーテナントのテナント管理者がデータベースにログインします。
説明
MySQLテナントの管理者ユーザーは
rootユーザー、Oracleテナントの管理者ユーザーはSYSユーザーです。クリーンアップ戦略を設定します。これは、テナントの自動クリーンアップ機能を有効にすることに相当します。
ステートメントは以下のとおりです：
ALTER SYSTEM ADD DELETE BACKUP POLICY [=] policy_name RECOVERY_WINDOW [=] recovery_window;このうち：
policy_name：クリーンアップ戦略名を指定します。サポートされている値は以下のとおりです：default：自動クリーンアップの範囲は、テナントの現在のDATA_BACKUP_DESTおよびLOG_ARCHIVE_DESTパラメータで指定されたパス配下のバックアップデータとアーカイブデータに限定されます。log_only：自動クリーンアップの範囲は、テナントの現在のLOG_ARCHIVE_DESTパラメータで設定されたアーカイブパス内のログに限定されます。データバックアップを行わず、ログアーカイブのみを有効にしている場合に適用されます。クリーンアップ戦略をlog_onlyに設定する場合、当該テナントの現在のDATA_BACKUP_DESTパラメータの値は空でなければなりません。つまり、データバックアップの出力先は設定されていない状態である必要があります。同様に、クリーンアップ戦略をlog_onlyに設定した場合は、DATA_BACKUP_DESTパラメータを設定することはできません。
recovery_window：バックアップデータのリストア可能時間窓を制御します。このパラメータの詳細については、recovery_windowパラメータの紹介を参照してください。
例：
MySQLモードOracleモードMySQLモードでは、テナントのクリーンアップ戦略を
defaultに設定し、バックアップのリストア可能な期間を7日間としています。obclient(root@mysql001)[(none)]> ALTER SYSTEM ADD DELETE BACKUP POLICY 'default' RECOVERY_WINDOW '7d';Oracleモードでは、テナントのクリーンアップ戦略を
log_onlyに設定し、バックアップからリストア可能な期間を7日間とします。obclient(SYS@oracle001)[SYS] ALTER SYSTEM ADD DELETE BACKUP POLICY 'log_only' RECOVERY_WINDOW '7d';説明
自動クリーンアップタスクは、バックグラウンドシステムによって毎時定期的にトリガーされます。そのため、クリーンアップ戦略の設定完了後、対応するクリーンアップタスクが確認できるまでには、しばらくの時間（1時間以内）がかかる場合があります。
設定済みのクリーンアップ戦略を確認します。
設定が成功すると、
oceanbase.DBA_OB_BACKUP_DELETE_POLICY（MySQLモード）ビューまたはsys.DBA_OB_BACKUP_DELETE_POLICY（Oracleモード）ビューを使用して、現在のテナントのクリーンアップ戦略を確認できます。MySQLモードOracleモードMySQLモードでのクエリ例は次のとおりです：
obclient(root@mysql001)[oceanbase]> SELECT POLICY_NAME, RECOVERY_WINDOW FROM oceanbase.DBA_OB_BACKUP_DELETE_POLICY;クエリ結果は次のとおりです：
+-------------+-----------------+ | POLICY_NAME | RECOVERY_WINDOW | +-------------+-----------------+ | default | 7d | +-------------+-----------------+ 1 row in setOracleモードでのクエリ例は次のとおりです：
obclient(SYS@oracle001)[SYS]> SELECT POLICY_NAME, RECOVERY_WINDOW FROM SYS.DBA_OB_BACKUP_DELETE_POLICY;クエリ結果は次のとおりです：
+-------------+-----------------+ | POLICY_NAME | RECOVERY_WINDOW | +-------------+-----------------+ | log_only | 7d | +-------------+-----------------+ 1 row in set
次のステップ
クリーンアップ戦略の設定が完了した後、クリーンアップ戦略を変更する必要がある場合は、まず既存のクリーンアップ戦略を削除してから新しい戦略を設定する必要があります。クリーンアップ戦略の削除手順の詳細については、クリーンアップ戦略の削除を参照してください。
クリーンアップ戦略の設定が完了した後、期限切れのクリーンアップをできるだけ早く実行したい場合は、手動で即座に1回の期限切れクリーンアップをトリガーできます。期限切れバックアップの手動クリーンアップの詳細な操作と説明については、手動で期限切れクリーンアップをトリガーするを参照してください。