【ITニュース解説】Online enabling checksums in PostgreSQL 19

データベースにおいて、データが意図せず破損する現象は、システムの信頼性を揺るがす重大な問題となる。特に「サイレント・コリプション」と呼ばれる、気づかないうちにデータが少しずつ壊れていく事象は厄介である。これは、ストレージデバイスや入出力（I/O）システムといった、データベースの「下」の層で発生することが多く、そのまま放置されると誤ったデータが使われ続け、結果的に間違った情報に基づいた判断や処理が行われる危険性がある。PostgreSQLのようなデータベースは、データページの基本的な構造（ページヘッダ）が正しいかどうかの確認は行うものの、ページに格納されている実際のデータ内容が完全に正しいかどうかを暗号学的に検証する機能は持っていない。このため、チェックサムがない状態では、多くの種類のサイレント・コリプションが見過ごされ、不正なクエリ結果が返される可能性がある。

このような問題への対策として、データの整合性を保証する「データチェックサム」という技術が利用される。チェックサムとは、データの内容から特定の計算方法で生成される短い値であり、データの指紋のようなものと考えると良い。データがディスクに書き込まれる際にこのチェックサムが計算されてデータと共に保存され、データが読み込まれる際には再度チェックサムが計算され、保存されている値と一致するかどうかが確認される。もし値が一致しなければ、データが破損していると判断できるのである。

PostgreSQL 18以降のバージョンでは、新しく作成されるデータベースクラスターにおいて、デフォルトでデータページにチェックサムが付与されるようになった。これはクラスター内の全てのデータベースに適用されるため、広い範囲でデータの整合性が保護される。しかし、以前のPostgreSQLバージョンからアップグレードした既存のデータベース環境では、チェックサムが有効になっていないことが多いのが実情だ。既存のデータベースにチェックサムを追加するには、これまでpg_checksumsという専用のツールを使う必要があったが、この操作を行うにはデータベースを一度シャットダウンしなければならず、処理に時間がかかることもあり、サービスを停止できないシステムにとっては大きな課題となっていた。

この課題を解決するため、PostgreSQL 19では、データベースを停止することなく「オンラインでチェックサムを有効化する」機能が導入される。この新機能により、アプリケーションが稼働し続けている最中にも、バックグラウンドでチェックサムの追加処理を進めることが可能になる。システムの負荷を考慮して、処理速度が調整される（スロットリング）場合もある。

チェックサムがない状態でデータが破損した場合の危険性を理解するため、実際にどのようなことが起こるかを見てみよう。まず、initdbコマンドを使って--no-data-checksumsオプションを指定し、チェックサムが無効なデータベースを初期化する。そのデータベースの中にhackmeというテーブルを作成し、「Hello World!」というテキストデータを一行だけ保存する。このデータがメモリ上ではなく、確実にディスクに書き込まれるようにcheckpointコマンドを実行し、さらにpg_buffercache_evict_all()関数で共有バッファ（データベースが頻繁にアクセスするデータを一時的に保存するメモリ領域）からデータをクリアする。これにより、次にデータを読み出す際には、必ずディスクから読み込まれる状態にする。

PostgreSQLのデータは、オペレーティングシステムから見ると通常のファイルとしてディスクに保存されている。このデータファイルへのパスを確認し、オペレーティングシステムのコマンドを使って、直接ファイルの内容を書き換える。デモンストレーションでは、「Hello World!」というテキストを「Hello Hacker」に改ざんした。これは、ストレージデバイスの故障や不正アクセスによって、ディスク上のデータがサイレントに書き換わってしまう状況をシミュレートしている。この状態でPostgreSQLからhackmeテーブルのデータを読み出すと、驚くべきことに、改ざんされた「Hello Hacker」というデータがそのまま表示されてしまう。PostgreSQLはデータが外部から不正に書き換えられたことに全く気づかず、破損したデータを正しいものとして扱ってしまったのである。これは非常に危険な状態であり、このようなデータに基づいて重要な意思決定が行われると、深刻な問題を引き起こす可能性がある。

PostgreSQL 19で導入されるオンラインチェックサム有効化の機能は、この問題を根本から解決する。データベースが稼働している状態で、show data_checksumsコマンドで現在のチェックサムの状態が「off」であることを確認した後、pg_enable_data_checksums()という特別な関数を実行する。この関数を実行すると、データベースは停止することなく、バックグラウンドでチェックサムの有効化プロセスが開始される。pg_stat_progress_data_checksumsというビューを確認すると、このプロセスの進捗状況を追跡でき、show data_checksumsは「inprogress-on」（有効化が進行中）という状態を示す。プロセスが完了すると、show data_checksumsは「on」に変わり、データベース全体にチェックサムが適用されたことがわかる。この一連の操作は、サービスを中断することなく実行されるため、既存のシステムにとって非常に大きなメリットとなる。

チェックサムが有効になった状態で、先ほどと同様にデータ破損のシナリオを再現する。再び共有バッファをクリアし、データファイルを直接編集して「Hello Hacker」を「Hello Franck」に改ざんする。この状態でPostgreSQLからhackmeテーブルのデータを読み出すと、今回は「ERROR: invalid page in block 0 of relation ...」というエラーメッセージが表示される。これは、PostgreSQLがディスクから読み込んだデータページのチェックサムを検証した結果、保存されているチェックサム値と、読み込んだデータから計算したチェックサム値が一致しないことを検出したことを意味する。つまり、データが破損していることを明確に認識し、破損したデータをアプリケーションに渡すことを拒否したのである。

このような早期の破損検出は、システムの復旧において極めて重要である。破損したデータがサイレントに使われ続けることを防ぎ、問題が顕在化することで、データベース管理者は迅速に状況を把握し、対策を講じることができる。例えば、健全なスタンバイデータベースへの切り替えを行ったり、信頼できるバックアップからデータを復元したりといった対応が可能になる。pg_basebackupのようなPostgreSQLの標準バックアップツールは、チェックサムが有効なデータベースに対してバックアップ時にチェックサム検証を実行し、破損を検出できる。また、それ以外のバックアップツールを使用する場合でも、pg_checksums --checkコマンドを使ってバックアップデータの整合性を後から検証することが推奨される。

オンラインでのチェックサム有効化は非常に強力な機能だが、利用に際していくつか注意すべき点がある。まず、pg_enable_data_checksums()関数を実行するには、データベースのスーパーユーザー権限が必要であり、プライマリデータベースで実行しなければならない。この変更は、Write-Ahead Log (WAL)という仕組みを通じてスタンバイデータベースにも伝播される。次に、この操作はPostgreSQLのバックグラウンドワーカープロセスを2つ利用するため、max_worker_processesという設定値に十分な余裕があることを事前に確認しておく必要がある。また、チェックサム有効化の処理は、実行時に全てのデータベースでオープンになっている長時間のトランザクションや一時テーブルが完了するのを待機するため、非常に長いセッションや大規模な一時テーブルが存在する場合、処理が遅延したり、最悪の場合 indefinitely に停止したりする可能性もある。チェックサムは有効化処理中にデータページに順次計算されて付与されるが、実際にデータが読み出される際にそのチェックサムが検証されるようになるのは、処理が完全に完了し、データベースの状態が「on」に遷移した後である。さらに、チェックサム有効化が進行中の「inprogress-on」の状態でデータベースがクラッシュしたり再起動したりすると、その時点までの進行状況は失われ、チェックサムの有効化は最初からやり直す必要が生じる。スタンバイデータベースにおいては、WALリプレイ（プライマリからの更新を適用する処理）が一時的にブロックされ、データ同期の遅延（ラグ）が発生することがある。場合によってはプライマリの処理に影響を与える可能性もあるため、事前にmax_wal_sizeという設定値を一時的に減らすなどの対策を検討することで、この影響を軽減できる場合もある。

結論として、データチェックサムはPostgreSQLのデータ保護戦略において極めて重要な要素である。ストレージ層で発生するサイレントな問題を、具体的なエラーとして検出可能にし、適切な対応を促す役割を果たす。新しいデータベースクラスターを構築する際には、初期設定でチェックサムを有効にすることが強く推奨される。既存のデータベースクラスターに対しては、PostgreSQL 19で導入されるオンライン有効化機能を活用し、サービスを中断することなくチェックサムを追加できる。ただし、この作業は影響がゼロではないため、有効化プロセスの監視、バックアップデータやレプリカ（スタンバイデータベース）の整合性検証、そしてシステムのトランザクション寿命やワークロード特性を考慮に入れた計画が、データベースシステムの堅牢性を確保するためには不可欠である。