永続化バッファプール (PBP) 機能により、クラスターがクラッシュまたは再起動したときに、以前の共有バッファプールを使用できるようになります。
前提条件
PolarDB for PostgreSQLクラスターは、次のエンジンを実行します。
PostgreSQL 14 (リビジョンバージョンは14.5.2.0以降)
PostgreSQL 11 (リビジョンバージョンは1.1.1以降)
次のステートメントを実行して、PolarDB for PostgreSQLクラスターのマイナーバージョンを表示できます。
PostgreSQL 14
select version();PostgreSQL 11
show polar_version;
背景情報
PolarDB for PostgreSQL クラスタのメモリは、共有バッファプール、動的共有メモリ領域、およびプロセスグローバル領域で構成されています。
共有バッファプール: クラスターの起動時に事前に割り当てられた共有メモリの大部分。 様々なモジュールへの割り当ては、オフセット値によって決定される。
動的共有メモリ領域: プロセス間並列コンピューティングを実装するためにPostgreSQLで設計された共有メモリ領域。 動的に拡張できます。
プロセスグローバル領域: プロセスによって使用されるメモリ領域。 それは以下の部分を含む。
メモリコンテキスト
プライベートメモリ
メモリの分割方法を次の図に示します。
共有バッファプールは、PolarDB for PostgreSQL クラスターのメモリを最も多く占有し、クラスターのパフォーマンスに直接影響します。 ネイティブPostgreSQLでは、クラスターが再起動または予期せず終了すると、共有バッファプールがクリアされ、再初期化されます。 クラスターが再起動されて障害回復状態になると、データページはWALログに基づいて変更されます。 その結果、データをリロードまたは変更する必要があります。 これは、クラスターの可用性に影響します。 さらに、共有バッファプールが再初期化されると、ビジネス関連データが再ロードされ得る。 これは、深刻な性能ジッタを引き起こす。
上記の問題を解決するために、PolarDB for PostgreSQL にはPBP機能があり、クラスターが再起動または予期せず終了したときに元の共有バッファプールを使用できるようにします。 この機能には次の利点があります。
クラスターの可用性を向上させるための短いRTO。
クラスターがクラッシュする前後の明らかなパフォーマンスのジッターはありません。
この機能の仕組み
PolarDB for PostgreSQL は、一部の共有バッファプールを、ポッドレベルのライフサイクルを持つ永続バッファプールに変更します。 PolarDB for PostgreSQL のPBP機能には、ポッドレベルのライフサイクルを持つバッファプールとバッファ記述子のみが含まれます。 他のメモリ部分は、依然としてクラスタレベルのライフサイクルを有する。
ポッドレベルのライフサイクル: PolarDB for PostgreSQL クラスターがKubernetesにデプロイされます。 ポッドレベルのライフサイクルを持つメモリパーツは、クラスターが予期せず存在しても破壊されません。
クラスターレベルのライフサイクル: ポッドレベルのライフサイクルを持つメモリパーツは、クラスターがクラッシュした後にクリアされます。
次の図は、ポッドレベルとクラスターレベルのライフサイクルを持つメモリがどのように分割されるかを示しています。
PBP可用性関連のメトリック
PBP機能は、すべてのシナリオに適用できるわけではありません。 PBP機能は、クラスターの起動時に次の条件では使用できません。
異なるサイズのクラスタ変更およびバッファプールの仕様が必要です。
現在のPBPはこのクラスターに対して作成されていません。
現在のPBP内の制御情報は無効である。
PBPの全体的な可用性に加えて、各PBPページは可用性チェックを必要とする。 次の条件では、現在のページは使用できません。
コミットされていないトランザクションは現在のページに存在します。
現在のページの記述子が無効です。
無効なログシーケンス番号 (LSN) が現在のページに存在します。
現在のページのプロパティが例外的または無効です。
次の図は、PBP可用性関連のメトリックを示しています。
PBP機能のパフォーマンスの向上
PBP機能により、クラスターの再起動時に以前の共有バッファプールを使用できるようになります。 したがって、クラスターが障害回復状態または実行中のいずれかで、キャッシュされたデータをすばやく使用してパフォーマンスを向上させることができます。 次の図は、PBP機能のパフォーマンスの向上を示しています。
リカバリパフォーマンスの比較
次のシナリオがテストされます。クラスターがクラッシュし、2093 MBのログが再生されます。
項目
ログ再生期間
リカバリ期間
PBP機能が無効
598s
746s
PBP機能の有効化
68s
294s
次の図は、PBP機能が有効になる前と後に消費される時間を示しています。
再起動のパフォーマンスの比較
バッファプールのすべてのページを再利用できるわけではありません。 たとえば、プロセスはページにXロックを追加します。 その後、クラスターがクラッシュした場合、どのプロセスもXロックを解除できません。 したがって、クラスターがクラッシュした後、バッファプール内のすべてのページの可用性がチェックされ、再利用できないページを削除するために再起動されます。 バッファプールの再利用もKubernetesに依存します。 PBP機能は、クラスターが再起動される前と後のパフォーマンスを安定させることもできます。 次の図は、クラスターの再起動前後のパフォーマンス値を示しています。
使用上の注意
次のパラメーターをONに設定します。
polar_enable_persisted_buffer_pool = ONパラメーター値を変更した後、変更を有効にするには、クラスターを再起動する必要があります。