バックアップが正常に完了すると、ビジネスニーズに応じてテナントのクリーンアップポリシーを設定できます。クリーンアップポリシーが設定されたテナントは、毎時間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データベースはそのバックアップセットのクリーンアップに失敗し、そのObjectの保持期間が満了するまで待たなければなりません。そのバックアップセットのクリーンアップモードが
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回の期限切れクリーンアップをトリガーできます。期限切れバックアップの手動クリーンアップの詳細な操作と説明については、手動で期限切れクリーンアップをトリガーするを参照してください。