PolarDB:データの管理とクリーンアップ

保持ポリシー

バイナリログには、次の 2 つの保持ポリシーがあります。

• バイナリロギングを有効にした後、ファイルはデフォルトで 3 日間保存されます。 3 日より古いファイルは自動的に削除されます。

  説明

  • 2023 年 11 月 23 日より前に購入した PolarDB for MySQL クラスタの場合、バイナリログはデフォルトで 2 週間（14 日間）保存されます。

  • 2024 年 1 月 17 日より前に購入した PolarDB for MySQL クラスタの場合、バイナリログはデフォルトで 1 週間（7 日間）保存されます。

• バイナリロギングを無効にした後、既存のバイナリログは無期限に保持され、自動的には削除されません。

  説明

  バイナリログを削除するには、バイナリロギングを有効にし、保持期間パラメーター（loose_expire_logs_hours または binlog_expire_logs_seconds）を小さい値に設定し、保持期間が経過した後、ファイルが自動的に削除されるまで待ってから、バイナリロギングを無効にする必要があります。

保持期間を変更する

バイナリログの保持期間は、次の方法で変更できます。

• MySQL 5.6：loose_expire_logs_hours パラメーターの値を変更することで、バイナリログの保持期間を設定できます。 値は時間単位です。 値の範囲は 0 ～ 2376 です。 デフォルト値は 72 です。 値 0 は、バイナリログが自動的に削除されないことを示します。

• MySQL 5.7 または MySQL 8.0：binlog_expire_logs_seconds パラメーターの値を変更することで、バイナリログの保持期間を設定できます。 値は秒単位です。 値の範囲は 0 ～ 4294967295 です。 デフォルト値は 259200 です。 値 0 は、バイナリログが自動的に削除されないことを示します。

履歴ファイルをクリーンアップする

バイナリログの保持期間パラメーター（loose_expire_logs_hours または binlog_expire_logs_seconds）を変更した後、クラスタ内の履歴バイナリログはすぐにパージされません。 この場合、次の 3 つの方法のいずれかを使用して、履歴ファイルをクリーンアップできます。

• 自動クリーンアップを待つ：クラスタ内の最後のバイナリログが最大サイズ（max_binlog_size パラメーター）に達すると、システムは新しいバイナリログに切り替わり、履歴バイナリログは自動的にパージされます。

• 手動クリーンアップ：特権アカウントを使用して flush binary logs コマンドを実行し、バイナリログの切り替えをすぐにトリガーして、期限切れのバイナリログをパージします。

• クラスタを再起動する：クラスタを再起動すると、システムは履歴バイナリログを自動的にパージします。

保持期間を変更する

loose_innodb_polar_log_file_max_reuse パラメーターを変更することで、保持するキャッシュされた REDO ファイルの数を調整できます。 これにより、ログ領域の使用量が削減されますが、高負荷下ではパフォーマンスが定期的にわずかに変動する可能性があります。

コミットされていないトランザクションを特定して終了する

1. データベースにログインする：PolarDBコンソール に移動します。 ターゲットクラスタの 概要 ページで、右上隅にある データベースにログイン をクリックして、DMS プラットフォームで PolarDB for MySQL クラスタにログインします。

2. コミットされていないトランザクションを見つける：次のコマンドを実行して、長時間実行されているコミットされていないトランザクションがあるかどうかを確認します。

   SELECT * FROM INFORMATION_SCHEMA.innodb_trx;

   trx_started（トランザクションの開始時刻）が非常に古いトランザクション、または trx_state（トランザクションステータス）が長時間 RUNNING になっているトランザクションに細心の注意を払ってください。 trx_mysql_thread_id（スレッド ID）の値を記録します。

3. トランザクションを終了する：ビジネスに影響を与えないことを確認した後、KILL コマンドを実行して、ターゲットトランザクションを終了します。

   kill [thread ID];

バックグラウンドクリーンアップの進捗状況を確認する

トランザクションに対応するスレッドを終了した後、現在の Undo history の進捗状況を確認する必要があります。 Undo history の長さがまだ急速に増加していることがわかった場合は、バックグラウンドクリーンアップ（パージ）のパフォーマンスを最適化する必要があります。

1. クリーンアップの進捗状況を監視する：次のコマンドを実行して、Undo history の長さを監視します。

   SELECT COUNT FROM INFORMATION_SCHEMA.innodb_metrics WHERE name = 'trx_rseg_history_len';

   この値が 100 万を超える場合、または数分以上にわたって上昇し続け、現在の負荷が実際に高い場合は、クリーンアップ速度が書き込み速度に追いつかないことを意味します。

2. クリーンアップパラメーターを調整する：クリーンアップ効率を向上させます。

   1. innodb_purge_batch_size パラメーターの値を大きくして、各クリーンアップバッチを大きくします。

   2. innodb_purge_threads パラメーターの値を大きくして、クリーンアップスレッドの数を増やします。 クラスタ仕様の CPU コア数と一致するように設定します。

      説明

      この操作により、クラスタが再起動されます。 この操作は、オフピーク時に実行してください。

占有されている領域を解放する

Undo history の長さが減少し、安定した後、UNDO ログによって占有されている領域をクリーンアップする場合は、undo log truncation 機能を有効にできます。

• 機能を有効にする：innodb_undo_log_truncate パラメーターの値を ONに設定します。

• トリガーメカニズム：単一の UNDO ファイルのサイズが innodb_max_undo_log_size を超えると、undo log truncation がトリガーされます。

• バージョンの制限：一部の履歴バージョンには、undo log truncation に関連するバグがあります。 システムは、これらのバージョンでこのパラメーターを変更する権限を無効にしています。 このような状況が発生した場合は、クラスタの マイナーバージョンを最新バージョンにアップグレードする必要があります。

• すぐに無効にする：この機能により、クラスタの切り替えまたは再起動中に追加のオーバーヘッドが発生します。 領域が解放されたら、すぐにこのパラメーターを OFF に戻してください。特に、マイナーバージョンのアップグレードなどの O&M 操作を実行する前には必ず行ってください。 必要に応じてのみ有効にしてください。