このトピックでは、過剰なログファイルによって引き起こされるクラスターのストレージ枯渇の原因と解決策について説明し、フォローアップメンテナンスの推奨事項を提示します。
問題の説明
PolarDB for MySQL クラスターは、過剰なバイナリログ、redo ログ、または undo ログが原因でストレージ領域を使い果たします。領域分析により、ログ領域の使用率が高いことが確認されます。次の図に例を示します。
この問題は、大規模なトランザクションがバイナリログ、redo ログ、または undo ログを急速に生成し、クラスターのストレージ領域を過剰に消費する場合に発生する可能性があります。
解決策
バイナリログ、undo ログ、または redo ログをクリーンアップした後、インターフェイスに変更が反映されるまでに時間がかかる場合があります。更新が完了するまでお待ちください。
ラージオブジェクトに対する操作など、データ操作言語 (DML) 操作は、バイナリログ、undo ログ、または redo ログを急速に生成する可能性があります。この場合、ストレージ領域のスケールアウトと、ログが急速に生成される原因の調査を検討してください。
以下の解決策で十分なストレージ領域が解放されない場合は、他の種類のデータファイルをクリーンアップしてストレージ使用量を削減できます。詳細については、「過剰なデータファイルによるクラスターのストレージ枯渇の解決」をご参照ください。
バイナリログ
保持ポリシー
バイナリログファイルでは、次の保持ポリシーがサポートされています。
バイナリログ機能が有効になっている場合、バイナリログファイルはデフォルトで 3 日間保持されます。保持期間が 3 日を超えたバイナリログファイルは自動的に削除されます。
説明2023 年 11 月 23 日より前に購入された PolarDB for MySQL クラスターの場合、バイナリログファイルはデフォルトで 2 週間 (14 日間) 保持されます。
2024 年 1 月 17 日より前に購入された PolarDB for MySQL クラスターの場合、バイナリログファイルはデフォルトで 1 週間 (7 日間) 保持されます。
バイナリログ機能が無効になっている場合、既存のバイナリログファイルは永続的に保持されます。
保持期間の変更
バイナリログファイルの保持期間を変更しても、接続が中断されたり、クラスターの再起動が必要になったりすることはありません。
ただし、保持期間の変更により 10 TB などの大量のバイナリログファイルをパージする必要がある場合、書き込み操作中に短い例外が発生する可能性があります。大量のバイナリログが存在する場合は、オフピーク時に保持期間を変更することをお勧めします。保持期間を段階的に短縮することもできます。これにより、毎回バイナリログの一部のみがクリアされます。これにより、ビジネス運用への影響が軽減されます。
削除されたバイナリログファイルは復元できません。
クラスターでバイナリログ機能が有効になっている場合は、次の操作を実行してバイナリログの保持期間を変更します。
PolarDB for MySQL V5.6 クラスター: loose_expire_logs_hours パラメーターの値を変更します。このパラメーターの有効な値: 0～2376。単位: 時間。デフォルト値: 72。値 0 は、バイナリログファイルが自動的に削除されないことを指定します。詳細については、「クラスターとノードのパラメーターを設定する」をご参照ください。
PolarDB for MySQL 5.7 または 8.0 クラスター: binlog_expire_logs_seconds パラメーターの値を変更します。このパラメーターの有効な値: 0～4294967295。単位: 秒。デフォルト値: 259200。値 0 は、バイナリログファイルが自動的に削除されないことを指定します。詳細については、「クラスターとノードのパラメーターを設定する」をご参照ください。
重要これら 2 つのパラメーターの値を変更した後、クラスター内の履歴バイナリログはすぐにはクリアされません。次のいずれかの方法を使用して、即時パージをトリガーできます。
バイナリログファイルのローテーションを待ちます。アクティブなバイナリログファイルが
max_binlog_sizeで設定された最大サイズに達すると、新しいバイナリログファイルが作成され、すべての履歴バイナリログファイルが自動的に削除されます。特権アカウントを使用して flush binary logs コマンドを実行します。
クラスターを再起動します。履歴バイナリログファイルは、クラスターの再起動後にクリアされます。
クラスターでバイナリログ機能が無効になっていて、バイナリログファイルを削除したい場合は、次の手順を実行します。クラスターのバイナリログ機能を有効にします。詳細については、「バイナリログを有効にする」をご参照ください。loose_expire_logs_hours または binlog_expire_logs_seconds パラメーターをより小さい値に設定し、バイナリログの有効期限が切れて自動的にパージされるのを待ちます。その後、バイナリログ機能を無効にします。
Redo ログ
PolarDB for MySQL クラスターは、バイナリログの代わりに redo ログを使用して、プライマリノードと読み取り専用ノード間のデータ同期を実現します。
ログバックアップを除き、ローカル redo ログは 2 GB から 11 GB のストレージ領域を占有します。これには、バッファープール内の 8 つの redo ログ (8 GB)、書き込み中の redo ログ (1 GB)、事前に作成された redo ログ (1 GB)、および最後の redo ログ (1 GB) が含まれます。
ログバックアップを含め、ローカル redo ログはバックアップ完了後約 1 時間保持されます。書き込み速度が速い場合 (たとえば、35 MB/s 超)、ローカル redo ログが一時的に蓄積される可能性があります。
クリーンアップルール
Redo ログは手動クリーンアップをサポートしていません。通常、ログバックアップが完了した後に自動的にクリーンアップされます。
クラスターの ログバックアップポリシー は PolarDB コンソールで調整できます。デフォルトの保持期間は 7 日です。
Undo ログ
古い、コミットされていないトランザクションを確認します。PolarDB では、undo ログは Multi-Version Concurrency Control (MVCC) の履歴バージョンとして機能します。コミットされていないトランザクションが古い読み取りビューを保持している場合、undo ログのクリーンアップがブロックされ、蓄積されます。次のコマンドを使用して、大規模なトランザクションを確認します。
SELECT * FROM INFORMATION_SCHEMA.innodb_trx;PolarDB クラスターの読み取り専用ノードと読み書きノードは、共有ストレージを使用します。読み取り専用ノード上のコミットされていない大規模なトランザクションも、undo ログのクリーンアップに影響します。トランザクションに対応するスレッドを強制終了すると、undo ログの増加が停止します。undo ファイルから領域を再利用するには、undo 履歴の進行状況を確認してから、ファイルをクリーンアップします。
書き込み負荷が高い場合は、undo ログのクリーンアップが遅れていないか確認します。PolarDB ポリシーは現在の書き込みパフォーマンスを優先するため、undo ログのクリーンアップが遅れる場合があります。次のコマンドを使用して、現在の undo 履歴の長さを表示します。
SELECT COUNT FROM INFORMATION_SCHEMA.innodb_metrics WHERE name = 'trx_rseg_history_len';この値が 100 万を超える場合、または高負荷下で数分間にわたって増加し続ける場合は、次のように設定を調整します。
innodb_purge_batch_sizeパラメーターの値を増やします。この操作では、クラスターを再起動する必要はありません。innodb_purge_threadsパラメーターの値を増やします。クラスター仕様のコア数と一致するように値を設定します。この操作にはクラスターの再起動が必要なため、オフピーク時に実行する必要があります。undo 履歴の長さが減少するのを待ちます。その後、undo 領域の増加が停止します。undo 領域を再利用するには、undo ログの切り捨てを有効にします。
innodb_undo_log_truncateパラメーターを ON に設定して、undo ログの切り捨てを有効にします。undo ログの切り捨て機能は、クラスターのスイッチオーバーまたは再起動中にオーバーヘッドを追加します。領域が再利用された直後、特にマイナーバージョンのアップグレードなどのタスクを実行する前に、この機能を無効にする必要があります。必要に応じて再度有効にできます。PolarDB は 8 つの undo ファイルを維持します。単一のファイルがinnodb_max_undo_log_sizeで指定されたサイズを超えると、undo ログの切り捨てがトリガーされます。innodb_max_undo_log_sizeのデフォルト値は 8 GB です。ファイルサイズが長時間 8 GB を超え、書き込み負荷が低く、初期のクラスターバージョンを使用している場合は、クラスターを最新のマイナーバージョンにアップグレードできます。説明一部のレガシーバージョンには、undo ログの切り捨てに関連するバグがあり、
innodb_undo_log_truncateパラメーターを変更できません。その結果、パラメーター変更インターフェイスでパラメーターが使用できなくなります。この場合、マイナーバージョンのアップグレードを実行して、クラスターを最新バージョンに更新する必要があります。
フォローアップメンテナンス
ストレージ領域をスケールアウトできます。PolarDB for MySQL はストレージとコンピューティングが分離されたアーキテクチャを使用しており、手動でのストレージ領域のスケールアウトまたはスケールインのいずれかによってストレージ容量を拡張できます。