– PostgreSQLの可用性・性能・運用性を“もう一段”引き上げたい方へ –
PostgreSQLをより強化したい方に向けて、20年以上進化を続ける
多機能ミドルウェア「Pgpool-II」の全容をぎゅっと詰め込んだウェビナーを開催します！
PostgreSQL 18.3 に関する技術情報
このリリースは 18.2 からの修正リリース（2026年 2月 26日リリース）です。
18.X からのアップデートではダンプ、リストアは不要です。
しかしながら、18.2 よりも前のバージョンからアップデートする場合には、18.2のリリース情報も参照してください。
PostgreSQL 17.9 に関する技術情報
このリリースは 17.8 からの修正リリース（2026年 2月 26日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。
しかしながら、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。
PostgreSQL 16.13 に関する技術情報
このリリースは 16.12 からの修正リリース（2026年 2月 26日リリース）です。
16.X からのアップデートではダンプ、リストアは不要です。
しかしながら、16.10 よりも前のバージョンからアップデートする場合には、16.10のリリース情報も参照してください。
PostgreSQL 15.17 に関する技術情報
このリリースは 15.16 からの修正リリース（2026年 2月 26日リリース）です。
15.X からのアップデートではダンプ、リストアは不要です。
しかしながら、15.14 よりも前のバージョンからアップデートする場合には、15.14のリリース情報も参照してください。
PostgreSQL 14.22 に関する技術情報
このリリースは 14.21 からの修正リリース（2026年 2月 26日リリース）です。
14.X からのアップデートではダンプ、リストアは不要です。
しかしながら、14.19 よりも前のバージョンからアップデートする場合には、14.19のリリース情報も参照してください。
Pacemaker におけるスロットリング (Throttle) の仕組み
Pacemaker を運用していると、次のようなログを目にすることがあります。
notice: High CPU load detected info: New throttle mode debug: New job limit is 1
このログを初めて見たとき、「クラスタに異常が発生したのではないか」と不安に感じる方もいるかもしれません。しかし結論から言うと、これらのログは障害ではありません。クラスタノードの負荷が高くなったため、Pacemaker の 負荷保護機構 (スロットリング) が正常に動作したことを示すログです。
本記事では、Pacemaker の運用で頻繁に遭遇する負荷スロットリングについて、ログの意味を読み解きながら分かりやすく解説します。なお、本記事は Pacemaker 3.0.1 を前提としています。
クォーラムデバイスの紹介
前回の記事では、スプリットブレインの発生メカニズムおよび Pacemaker/Corosync におけるその対策について解説しました。
本記事では、スプリットブレイン対策の中でも、2 ノードクラスタにおけるクォーラム確立を支援する「クォーラムデバイス」に焦点を当て、その仕組みと基本的な使い方について紹介します。
Pacemaker クラスタのスプリットブレイン対策
システムを安定して稼働させるためには、冗長化構成が不可欠です。冗長化構成を採用することで、稼働系サーバに障害が発生してサービスが停止した場合でも、待機系サーバへ自動的に切り替えることができ、ダウンタイムを最小限に抑えられます。
一方で、冗長化によって単一障害点は解消できるものの、クラスタノード間の通信が途絶えた場合には「スプリットブレイン」状態に陥るリスクが残ります。スプリットブレインが発生すると、複数のノードが同時に稼働系として振る舞い、IP アドレスの競合やファイルシステムの二重マウントなどが発生する可能性があります。最悪の場合、データ破損といった深刻な障害につながる恐れもあります。
そのため、クラスタ構成を安定して運用するうえで、スプリットブレイン対策は欠かせないポイントです。
本記事では、Pacemaker/Corosync クラスタで広く利用されているスプリットブレイン対策の仕組みについて解説します。
PostgreSQL 18.2 に関する技術情報
このリリースは 18.1 からの修正リリース（2026年 2月 12日リリース）です。
18.X からのアップデートではダンプ、リストアは不要です。
しかしながら、ltree型の列に対するインデックスがある場合には、アップグレード後にインデックス再構築が必要です。