
- EDB
- PostgreSQL
PostgreSQLの拡張機能「system_stats」のご紹介
EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。
|
2018年10月18日に、様々な機能追加・機能改善が行われたPostgreSQL 11がリリースされました。今回はその中でもデータベース管理者(DBA)にとって嬉しい機能改善の一つである、pg_basebackupのチェックサムの検証機能についてご紹介します。
※ EDB Postgres Advanced Server(EPAS)11は2018年10月18日時点で未リリースですが、PostgreSQL 11がベースになるため本機能も実装されます。
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です。
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の機能追加・機能改善については、また別の機会にご紹介したいと考えています。
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。
PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます
EDB Postgres Workload Reportsは、Postgresデータベースのパフォーマンス診断とトラブルシューティングを強化する新しいツールです。OracleのAWRに似た詳細なレポートを提供し、データベースの問題を迅速に特定・解決できるようサポートします。本記事では概要と利用手順をご紹介します。