削除した行がデータベースを縮小しない理由
PostgreSQLQLのMulti-Version Concurrency Control(MVCC)アーキテクチャは、並行データベース操作の基盤である一方、テーブルの肥大化という固有のコストを伴います。行が更新されると、PostgreSQLQLはその行をその場で変更せず、まったく新しいコピーを書き込み、古いバージョンを「dead(不要)」としてマークします。この仕組みにより、トランザクションは常にデータの一貫したスナップショットを参照できますが、不要になったデータが残ります。
やがてVACUUMプロセスがこれらの不要な行をクリーンアップし、その領域を同じテーブル内の新しいデータ用に利用可能にします。重要な点として、通常のVACUUM操作は、この回収した領域をオペレーティングシステムに返却しません。テーブルの半分を削除しても、ディスク上のファイルのサイズは変わらないことが多く、DBAにとって一般的な不満の原因となっています。
従来、テーブルを物理的に縮小して領域をOSに返却できる組み込みの方法はVACUUM FULLだけでした。このコマンドはテーブル全体を書き直し、新しいディスクページに圧縮します。しかしVACUUM FULLはACCESS EXCLUSIVEロックを取得し、完了するまでテーブルへのすべての読み取りと書き込みをブロックします。その影響は非常に深刻で、PostgreSQLQL自身のドキュメントでも本番環境での使用は推奨されていません。そのため、DBAはオンラインでのテーブル圧縮にpg_repackなどのサードパーティ製拡張機能に頼ることになっていました。
REPACKは負荷の大きい処理をクリティカルパスから外す
PostgreSQLQL 19は、テーブルの肥大化に対する組み込みのオンライン解決策として、ついにREPACK CONCURRENTLYをDBAに提供します。このコマンドは、元のテーブルへの並行した読み取りと書き込みを許可しながら、テーブルの新しいコンパクトなバージョンを作成することで、ブロッキングを伴うVACUUM FULLを回避します。ダウンタイムなしでパフォーマンスを維持するための画期的な機能です。
その仕組みは巧妙です。REPACKはまず、すべての有効な行を新しい一時テーブルにコピーします。重要なのは、その後WAL-based logical decoding(WALベースの論理デコーディング)を使用して、このコピー段階の間に元のテーブルで発生した変更(挿入、更新、削除)を取得することです。取得した変更は新しいテーブルに再適用され、置き換え後のテーブルが完全に最新の状態になります。
最後に、REPACKは短時間の排他ロックを行い、古いテーブルファイルを新しいコンパクトなものにアトミックに入れ替えます。これにより、テーブルが利用できなくなる重要な時間帯が最小限に抑えられます。Better Stackのテストでは、493 MBのテーブルが10秒未満で228 MBに縮小され、その間、最後の一瞬の切り替えまでテーブルにアクセス可能な状態が保たれました。これはあらゆる環境に当てはまるベンチマークではありませんが、REPACKがもたらす大きなディスク削減効果と運用効率を示しています。
小さなロックが大きなトラフィックの渋滞を引き起こすことがある
REPACK CONCURRENTLYは魔法ではなく、負荷の大きい作業を肩代わりするものにすぎません。テーブルコピーの大部分はオンラインで進行しますが、古いテーブルファイルを新しい圧縮済みのものに入れ替える最終的で重要なステップでは、排他ロックが必要です。このACCESS EXCLUSIVEロックは、そのテーブルに対する読み取りか書き込みかを問わず、あらゆる並行操作を妨げます。ごく短いアトミックな時間ですが、そのテーブルに触れているすべてのアクティブなトランザクションが完了するのを待たなければなりません。
このボトルネックは、運用上の大きなリスクを生みます。Better Stackのテストはこれを明確に示しました。切り替え時に実行中だった20秒の分析レポートが最終的な入れ替えを遅延させ、そのテーブルを対象とする後続のすべてのクエリが18秒間にわたって待機しました。これは事実上、head-of-line blocking(先頭ブロッキング)の状況です。1つの長時間実行クエリが並行処理を妨げ得るのであれば、オンラインでのリパックという利点は損なわれます。
これを軽減するには、最終的な切り替えを重要なイベントとして扱ってください。長時間実行されるレポートやバッチジョブがテーブルを競合する可能性が低い、ピーク時間外にREPACK CONCURRENTLYを実行するようスケジュールします。コマンドを開始する前に、対象テーブルに対するアクティブなセッションを事前に確認してください。テーブルメンテナンスの管理については、PostgreSQLQL Documentation: Routine Vacuumingなどの資料も参照できます。目標は、メタデータの入れ替えが予期せぬ遅延なく行われるようにし、巧妙な手法を信頼できる運用ツールにすることです。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
ネイティブなツールであっても、計画を省略してよい理由にはならない
PostgreSQLQL 19のネイティブなREPACK CONCURRENTLYは、10年以上にわたりコミュニティで定番となってきたpg_repackなどのサードパーティ製ツールに代わる有力な選択肢です。組み込みサポートにより、拡張機能の管理が簡素化され、互換性の問題を避けられ、コアのデータベース操作との統合が改善される可能性があります。この進化は、重要なDBA向け機能を内部に取り込む傾向が強まっていることを反映しています。
ただし、「ネイティブ」であることは「魔法」を意味しません。Better Stackの動画ではPostgreSQLQL 19のリリース目標日がNovember 19と示されていますが、移行を計画する前に、現在のリリース状況とプロバイダーによるサポートを必ず確認してください。特にマネージドサービスでは、機能の採用が遅れたり、新しいコマンドに制限が課されたりする場合があるため、利用するベンダーに必ず機能を確認してください。
動画でも触れられているとおり、PostgreSQLQL 19の開発は「困難」なものでした。安定性を優先して、機能が発表され、取り消され、縮小されました。この慎重な姿勢は、PostgreSQLQL Global Development Groupの特徴です。したがって、本番ワークロードでREPACK CONCURRENTLYに頼る前に、その正確な動作と運用上の注意点を、PostgreSQLQL 19の公式ドキュメントで確認してください。
結局のところ、REPACK CONCURRENTLYはDBAにとって強力な新しい手段であり、万能の解決策ではありません。短時間ではあっても重要な排他ロックがあるため、戦略的な計画は引き続き不可欠です。アクティビティの少ない時間帯や、長時間実行クエリが存在しないときに実行することで、効果を最大化し、Better Stackのテストで見られた18秒間のキューイングを防げます。
よくある質問
PostgreSQL 19のREPACKは何をしますか?
REPACKは、テーブルをよりコンパクトな物理レイアウトに再構築し、未使用のディスク領域を回収します。その間も通常のデータベース処理を継続できます。
REPACKはVACUUM FULLとどう違いますか?
VACUUM FULLは、処理の間ずっとブロッキングロックを保持したままテーブルを書き直します。REPACK CONCURRENTLYは、作業の大部分をテーブルにアクセスできる状態で行い、ファイルを切り替える際にのみ短時間の排他ロックを必要とします。
REPACK CONCURRENTLYでもアプリケーションのトラフィックに影響が出ることはありますか?
はい。最後の入れ替えでは、そのテーブルを使用しているクエリの完了を待つ必要があり、新しいリクエストはロックの後ろで待機することがあります。
PostgreSQL 19によってpg_repackは不要になりますか?
場合によってはpg_repackの必要性が減る可能性がありますが、組み込み機能の提供状況や運用上の適合性を、既存のツールと比較して検討する必要があります。