
- EDB
- PostgreSQL
意外な落とし穴!アプリケーション⇒DBデータ型によるパフォーマンス影響
PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます
|
この記事は
PostgreSQL Advent Calendar 2016
の21日目の記事です。
【SR+HS環境の落とし穴】スタンバイのリカバリに必要なWALが上書きされる障害の予防策
でStreaming Replication + Hot Standby(SR+HS)環境で発生しうる「FATAL: requested WAL segment <WALセグメント名> has already been removed」のメッセージの予防策を紹介しました。
このメッセージはSR+HS運用中だけではなく、
pg_basebackup
コマンドや
pg_receivexlog
コマンドの実行中にも発生する可能性があります。各コマンドの実行中に本メッセージが発生した場合、再実行が必要になり所定の時間でバックアップが終わらなかったり、必要なWALファイルが取得できておらず、ベースバックアップを取り直す対応が必要になったりします。
そこで、今回はpg_basebackupコマンドとpg_receivexlogコマンドの実行中に発生しうる本メッセージの予防策について紹介します。
pg_basebackup
コマンドは、稼動中のPostgreSQLのデータベースクラスタのベースバックアップ(オンラインバックアップ)を取得するためのものです。9.1以降で使用可能です。
9.0以前ではオンラインバックアップを取得するために複数のコマンドを実行する必要がありましたが、9.1以降ではpg_basebackupコマンドを実行するだけでオンラインバックアップを取得できます。pg_basebackupコマンド実行時に-X fetch(-Xf/-x)または-X stream(-Xs)オプションを付けることで、リカバリに必要なWALセグメントを含む一貫性のあるバックアップを取得することもできます。
-Xfまたは-Xsオプションを付けたpg_basebackupコマンドを実行中に、リカバリに必要なWALレコードを含むWALセグメントが上書きされた場合に、本メッセージが発生します。
pg_basebackupコマンドの詳細は、マニュアルもご確認ください。
pg_receivexlog
コマンドは、稼動中のPostgreSQLのデータベースクラスタからWALレコードを任意のディレクトリにリアルタイムに転送し続けるものです。このディレクトリはポイントインタイムリカバリを用いてリストアする際のアーカイブ場所として使用することができます。9.2以降で使用可能です。
pg_receivexlogコマンドの-Dオプションで指定したディレクトリにWALセグメント/WALレコードを転送しようとした際に、転送対象のWALレコードを含むWALセグメントが上書きされていた場合、本メッセージが発生します。
pg_receivexlogの詳細は、マニュアルもご確認ください。
WALセグメントは循環利用されますが、pg_basebackupコマンドやpg_receivexlogコマンドの実行中に必要なWALセグメントは削除されないよう保持しておく必要があります。この予防策として2つの方法がありますが、--slotオプションが用意されているバージョンでは、WALセグメントをバックアップ元で確実に保持できるレプリケーションスロットを使う方法を推奨します。
上述の各コマンドを実行する際に--slotオプションを付けレプリケーションスロットを使用することで、各コマンドの実行中に必要なWALレコードを含むWALセグメントが保持されるようになります。そのため、各コマンドを実行中に必要なWALセグメントが消されてしまうことを防げます。
--slotオプションは、pg_basebackupでは9.6から、pg_receivexlogでは9.4から使用できます。--slotオプションが存在しないバージョンをご利用の場合は、後述するもう一つの予防策の採用をご検討ください。
pg_xlogディレクトリに保持しておくWALセグメント数の最小値を設定するwal_keep_segments に、上述の各コマンドの実行中に必要なWALレコードを含むWALセグメントを保持できるくらい大きな値を設定することにより、本メッセージの発生を予防できます。ただし、お客様環境によってマシンの性能や処理量が異なるため、一概にwal_keep_segmentsに設定すべき設定値を紹介することはできません。トライアンドエラーで本メッセージの発生を予防するために十分な設定値を見積もる必要があります。
今回は、pg_basebackupコマンドとpg_receivexlogコマンドを実行中に「FATAL: requested WAL segment <WALセグメント名> has already been removed」のメッセージが発生する障害の予防策について紹介しました。この記事で紹介した予防策を実施することで各コマンドの実行中に必要なWALレコードを含むWALセグメントを保持することができ、想定外にバックアップを取得できない事態を防ぐことができます。
-Xfまたは-Xsオプションを付けたpg_basebackupコマンドやpg_receivexlogコマンドを実行されている方で、まだ今回紹介した予防策を実施されていない方は、ぜひこの機会に設定してみてください。
■本記事の内容について
本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。
■商標に関して
・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます
EDB Postgres Workload Reportsは、Postgresデータベースのパフォーマンス診断とトラブルシューティングを強化する新しいツールです。OracleのAWRに似た詳細なレポートを提供し、データベースの問題を迅速に特定・解決できるようサポートします。本記事では概要と利用手順をご紹介します。
35年以上教育事業を展開しているアシストが新たに取り組み始めた「ポスグレ学園」。連載10回目となる今回の記事では、OSS-DB Gold試験対策問題集 出版の経緯や内容を 新校長 我妻にインタビューしました。