バックアップが正常に完了すると、ビジネスニーズに応じてテナントのクリーンアップポリシーを設定できます。クリーンアップポリシーが設定されたテナントでは、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回の期限切れクリーンアップをトリガーできます。期限切れバックアップの手動クリーンアップの詳細な操作と説明については、手動で期限切れクリーンアップをトリガーするを参照してください。