【PostgreSQL/EPAS11 新機能】バックアップと同時にデータ破損チェック！

2018年10月18日に、様々な機能追加・機能改善が行われたPostgreSQL 11がリリースされました。今回はその中でもデータベース管理者（DBA）にとって嬉しい機能改善の一つである、pg_basebackupのチェックサムの検証機能についてご紹介します。

※ EDB Postgres Advanced Server（EPAS）11は2018年10月18日時点で未リリースですが、PostgreSQL 11がベースになるため本機能も実装されます。

PostgreSQL／EPAS 10以前のpg_basebackup

pg_basebackupコマンド実行時に全データブロックのチェックサムを検証する機能はありません。PostgreSQL／EPAS 10以前のpg_basebackupでデータベースクラスタのバックアップを取得した場合、一部のテーブルデータが破損していたとしてもpg_basebackupコマンドは正常に完了します。
　
また、そのバックアップをリストア・リカバリしてデータベースクラスタを起動する際にもエラーは発生しません。そのため、データ破損に気づくことができるタイミングは、しばらく運用して実際に破損しているデータがアクセスされた時です。
　
以下、pg_basebackupの実行例です。こちらの例では、破損したテーブルデータを含めてバックアップを取得しています。

　
　--データチェックサム機能が有効な環境でデータ破損が発生していることを確認
　$ psql
　psql (10.5)
　Type "help" for help.
　
　postgres=# SELECT * FROM test;
　2018-08-31 17:28:46.233 JST [8059] WARNING:  page verification failed, calculated checksum 48854 but expected 38159
　WARNING:  page verification failed, calculated checksum 48854 but expected 38159
　2018-08-31 17:28:46.244 JST [8059] ERROR:  invalid page in block 0 of relation base/13158/16396
　2018-08-31 17:28:46.244 JST [8059] STATEMENT:  SELECT * FROM test;
　ERROR:  invalid page in block 0 of relation base/13158/16396
　
　--pg_basebackupコマンドで正常にバックアップを取得できるか確認
　$ pg_basebackup -D /home/p105/backup -v
　pg_basebackup: initiating base backup, waiting for checkpoint to complete
　pg_basebackup: checkpoint completed
　pg_basebackup: write-ahead log start point: 0/4000028 on timeline 1
　pg_basebackup: starting background WAL receiver
　pg_basebackup: write-ahead log end point: 0/40000F8
　pg_basebackup: waiting for background process to finish streaming ...
　pg_basebackup: base backup completed　　# <==正常に実行できました。
　
　--終了コードを確認
　$ echo $?
　0　　# <== 一部のデータが破損しているにも関わらず終了コードは0です。

PostgreSQL／EPAS 11以降のpg_basebackup

pg_basebackupコマンド実行時に全データブロックのチェックサムを検証する機能が存在し、デフォルトで有効になっています。PostgreSQL／EPAS 11以降のpg_basebackupでデータチェックサム機能が有効になっているデータベースクラスタのバックアップを取得した場合、一部のテーブルデータが破損していればWARNINGメッセージを出力し、終了コードは0以外で終了します。
　
ただし、一部のテーブルデータが破損した状態でもバックアップは取得されており、このバックアップを使用することも可能です。
　
なお、予めデータベースクラスタにてデータチェックサムが有効になっていない場合には、PostgreSQL／EPAS 10以前と同様の挙動となります。
　
以下、PostgreSQL 11.0でpg_basebackupを使用して破損したデータを含む、データチェックサム機能が有効になっているデータベースクラスタのバックアップを取得した際の実行例です。

　
　--データチェックサム機能が有効な環境でデータ破損が発生していることを確認
　$ psql
　psql (11.0)
　Type "help" for help.
　
　postgres=# SELECT * FROM test;
　2018-10-18 20:22:06.007 JST [8964] WARNING:  page verification failed, calculated checksum 47946 but expected 13388
　WARNING:  page verification failed, calculated checksum 47946 but expected 13388
　2018-10-18 20:22:06.008 JST [8964] ERROR:  invalid page in block 0 of relation base/13231/16403
　2018-10-18 20:22:06.008 JST [8964] STATEMENT:  SELECT * FROM test;
　ERROR:  invalid page in block 0 of relation base/13231/16403
　
　--pg_basebackupコマンドで正常にバックアップを取得できるか確認
　$ pg_basebackup -D /home/p110/backup -v
　pg_basebackup: initiating base backup, waiting for checkpoint to complete
　pg_basebackup: checkpoint completed
　pg_basebackup: write-ahead log start point: 0/13000060 on timeline 1
　pg_basebackup: starting background WAL receiver
　pg_basebackup: created temporary replication slot "pg_basebackup_8976"
　2018-10-18 20:22:40.024 JST [8975] WARNING:  checksum verification failed in file "./base/13231/16403", block 0: calculated BB4A but expected 344C
　WARNING:  checksum verification failed in file "./base/13231/16403", block 0: calculated BB4A but expected 344C
　2018-10-18 20:22:40.425 JST [8975] ERROR:  checksum verification failure during base backup
　pg_basebackup: write-ahead log end point: 0/13000130
　pg_basebackup: checksum error occured　　# <==pg_basebackupコマンド実行時にエラーが発生。
　
　--終了コードを確認
　$ echo $?
　1　　# <==終了コードは1。この終了コードをもとにDBAにメールで通知するなど対策を取れます。

その他、pg_basebackupコマンドの--no-verify-checksumsオプションを付けることでチェックサムの検証機能を無効にできます。弊社にて実施した簡単な検証では、このオプションの有無によるpg_basebackupコマンドの処理時間に大きな差は確認できていませんが、以前のバージョン使用時よりもバックアップ処理に時間がかかる場合には、このオプションを追加して改善されるかお試しください。

チェックサムの検証で異常を検知した際の対策

チェックサムの検証で異常を検知した際の対策は、バックアップの有無により異なります。

バックアップが存在する場合

pg_dump/pg_dumpallなどで取得されている直近のバックアップが存在している場合は、バックアップから復旧します。

バックアップが存在しない場合

以下のように、zero_damaged_pagesパラメーターを有効にして破損データを含むブロックをゼロ埋めします。当該ブロックに含まれるデータは消失しますが、テーブルを参照できるようになります。

　
　--1000万件のデータを持つtest表の件数を確認
　postgres=# SELECT COUNT(*) FROM test;
　2018-10-18 20:59:54.129 JST [10426] WARNING:  page verification failed, calculated checksum 7386 but expected 11326
　2018-10-18 20:59:54.129 JST [10426] ERROR:  invalid page in block 83333 of relation base/13231/16391
　2018-10-18 20:59:54.129 JST [10426] STATEMENT:  SELECT COUNT(*) FROM test;
　2018-10-18 20:59:54.129 JST [10413] WARNING:  page verification failed, calculated checksum 7386 but expected 11326
　2018-10-18 20:59:54.129 JST [10413] CONTEXT:  parallel worker
　WARNING:  page verification failed, calculated checksum 7386 but expected 11326
　2018-10-18 20:59:54.129 JST [10413] ERROR:  invalid page in block 83333 of relation base/13231/16391
　2018-10-18 20:59:54.129 JST [10413] CONTEXT:  parallel worker
　2018-10-18 20:59:54.129 JST [10413] STATEMENT:  SELECT COUNT(*) FROM test;
　2018-10-18 20:59:54.142 JST [9332] LOG:  background worker "parallel worker" (PID 10426) exited with exit code 1
　2018-10-18 20:59:55.528 JST [10427] FATAL:  terminating connection due to administrator command
　2018-10-18 20:59:55.528 JST [10427] STATEMENT:  SELECT COUNT(*) FROM test;
　2018-10-18 20:59:55.544 JST [9332] LOG:  background worker "parallel worker" (PID 10427) exited with exit code 1
　ERROR:  invalid page in block 83333 of relation base/13231/16391
　CONTEXT:  parallel worker
　
　--zero_damaged_pagesパラメーターをonに設定した上でtest表にVACUUMを実行
　postgres=# SET zero_damaged_pages=on;
　SET
　postgres=# VACUUM test;
　2018-10-18 21:05:14.273 JST [10413] WARNING:  page verification failed, calculated checksum 7386 but expected 11326
　WARNING:  page verification failed, calculated checksum 7386 but expected 11326
　2018-10-18 21:05:14.274 JST [10413] WARNING:  invalid page in block 83333 of relation base/13231/16391; zeroing out page
　WARNING:  invalid page in block 83333 of relation base/13231/16391; zeroing out page
　2018-10-18 21:05:14.274 JST [10413] WARNING:  relation "test" page 83333 is uninitialized --- fixing
　WARNING:  relation "test" page 83333 is uninitialized --- fixing
　VACUUM
　
　--test表の件数を確認
　postgres=# SELECT COUNT(*) FROM test;
　  count
　---------
　 9999960　　# <==破損ブロックをゼロで埋めたため、一部データが消失しています。 
　(1 row)

まとめ

今回は、PostgreSQL／EPAS 11で追加されたpg_basebackupのチェックサム検証機能について紹介しました。PostgreSQL／EPAS 11のpg_basebackupを使用することでバックアップ時にデータ破損に気づくことができ、以前より早くデータ破損の対策を取れます。

また、今回紹介した機能改善以外にもPostgreSQL/EPAS 11では様々な機能追加・機能改善が行われていますので、 EPASやPostgreSQLをメジャーバージョンアップする方法（pg_dumpall編）などをご参考にぜひアップグレードすることをご検討ください。今回紹介できなかったPostgreSQL/EPAS 11の機能追加・機能改善については、また別の機会にご紹介したいと考えています。

執筆者情報

家島拓也

サービス事業部サポートセンター

2007年にアシストに入社して以来、ORACLE製品やPostgreSQL・EDB Postgres製品のサポートに従事してきました。このブログではサポート対応で得た知識を元に、お客様がお困りになることが多い問題や各製品の新機能に関する検証結果などを紹介します。

■商標に関して
OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。

Pythonの「Django」とPostgreSQLを接続してデータを取得してみた！

この記事ではPythonの WebアプリケーションフレームワークであるDjangoからPostgreSQLのデータにアクセスする方法をご紹介します。また、Djangoのインストール方法の説明後、簡単なDjangoアプリケーションを作成する方法をご紹介します。

EDB
PostgreSQL

2021.09.09

WordPress のデータベースをPostgreSQLに変更する方法

WordPressはデータベース管理システムとしてMySQLを使用していますが、PostgreSQLを好むユーザーからは「MySQLではなくPostgreSQLでWordPressを使用する方法はありませんか？」といった声をよく聞きます。そこで今回はPostgreSQLでWordPress をデプロイする方法をご紹介いたします。