【製品情報】EDB Postgres Distributed(PGD)6.1.0
音声ガイド1:概要早わかり
1. PGDとは?
EDB Postgres Distributed (PGD) は、PostgreSQLを基盤とした分散データベースソリューションです。その主な目的は、PostgreSQLインスタンスのクラスター全体でマルチマスターレプリケーションを可能にすることにより、高可用性、フォールトトレランス(耐障害性)、およびスケーラビリティを提供することです。
これにより、複数のサーバー(ノード)がすべて書き込み操作を受け入れることができ、変更はクラスター内の他のすべてのノードに複製(レプリケート)されます。PGDは、スタンドアロンのPostgreSQLデータベースを、複数のデータセンターやクラウドリージョン、あるいはハイブリッド環境にまたがることができる、回復力のある分散システムに変換します。
PGDには2つのエディションがあります。
- PGD Essential: 最小限の複雑さで高可用性と災害復旧を迅速に設定したいユーザー向けに設計された、シンプルなバージョンです。ノード数やグループ数に制限があります。
- PGD Expanded: カスタマイズ可能な構成、高度な競合管理、大規模な地理分散配備のサポートなど、全機能を備えたバージョンです。
2. 現代のIT環境におけるPGDの利点
常時稼働、低レイテンシ、そして回復力が求められる現代のIT環境において、PGDは以下の主要な利点を提供します。
- 極めて高い可用性(最大99.999%): 単一障害点を排除することで、1つ以上のノードに障害が発生してもデータベースの運用を継続できます。手動介入なしで新しい書き込みリーダーが選出される自動フェイルオーバーをサポートし、ダウンタイムを最小限に抑えます。
- 無停止でのメンテナンスとアップグレード: PGDはPostgresとPGD自体の両方でローリングアップグレードをサポートします。クラスターの他の部分がトラフィックを処理し続けている間に、ノードを1つずつアップグレードできるため、メンテナンスウィンドウが不要になります。
- 災害復旧(DR): 複数の地理的リージョンにまたがるアーキテクチャを設計できます。データセンターやクラウドリージョン全体がオフラインになっても、データベースサービスは別の場所から運用を継続できます。
- 地理的なデータ分散とレイテンシの削減: 世界中のユーザーの近くにデータを配置することができます。これにより、読み書きのレイテンシが削減され、グローバルなユーザーベースに対するアプリケーションのパフォーマンスが向上します。また、データを特定の地域に保持することを要求するデータ主権規制への準拠にも役立ちます。
- 読み取りスケーラビリティ: 読み取りクエリをクラスター内の複数ノードに分散させることで、システム全体の読み取りスループットを大幅に向上させ、読み取り負荷の高いワークロードが書き込みパフォーマンスに影響を与えるのを防ぎます。
3. PGDのアーキテクチャ
PGDは、可用性、回復性、およびスケールに関する特定の要件に基づいて選択できる、さまざまなアーキテクチャをサポートしています。
PGD Essential アーキテクチャ
シンプルさを重視して設計されており、最も一般的なユースケースをカバーします。
- 標準アーキテクチャ(単一拠点HA): 3つのノードを持つ単一のデータグループで構成され、通常は同一リージョン内の異なるアベイラビリティゾーンに配置されます。1つのノードに障害が発生しても、残りの2つが運用を継続し、新しい書き込みリーダーを選出することで高可用性を提供します。
- Near/Farアーキテクチャ(災害復旧): プライマリ拠点に2つのデータノード、セカンダリ(DR)拠点に1つのデータノードを配置します。プライマリサイト内での高可用性を確保しつつ、災害復旧用の完全なデータレプリカを保持します。
PGD Expanded アーキテクチャ
より複雑で大規模なデプロイメントに対応するための高い柔軟性を提供します。
- Always-Onアーキテクチャ: 1拠点あたり3つまたは5つのノードを使用する基本的な高可用性モデルで、堅牢なローカル冗長性を実現します。
- マルチロケーションアーキテクチャ: Always-Onモデルを2つ以上の稼働拠点に拡張し、すべてのサイト間でデータが複製されるメッシュネットワークを構築します。これにより、高可用性と災害復旧の両方を提供し、サイト全体に障害が発生しても他方が運用を継続できます。
- 地理分散アーキテクチャ: より高いレイテンシを持つ広範な地理的エリアで運用するために設計されたマルチロケーションアーキテクチャです。潜在的なネットワーク分断を管理し、世界中でデータの一貫性を確保するための高度な機能を備えています。
4. PGDの仕組み
PGDは、以下の主要技術の組み合わせによってその利点を実現しています。
- 双方向レプリケーション(BDR): PGDの中核には、PostgreSQLネイティブの論理レプリケーションを基盤とするBDRがあります。物理的なディスクブロックを複製するのではなく、論理的なデータ変更(例:INSERT、UPDATE文)を複製します。これにより、異なるメジャーバージョンのPostgres間でのレプリケーションが可能となり、ローリングアップグレードに不可欠です。
- コネクションマネージャー: PGD 6には、すべてのデータノードで動作する組み込みのコネクションマネージャーが含まれています。書き込みトラフィックを特定のライトリーダーノードに、読み取りトラフィックを他のノードに自動的にルーティングすることで、アプリケーション開発を簡素化します。この「単一ライトリーダー」アプローチがデフォルトであり、データ競合の可能性を劇的に低減します。
- Raftコンセンサス: PGDは、クラスター全体の重要な意思決定(現在のライトリーダーに障害が発生した場合の新しいリーダーの選出、DDL(スキーマ変更)ロックの管理、ノードのメンバーシップ変更の調整など)にRaftコンセンサスプロトコルを使用します。これにより、ノード障害に直面してもクラスターが確実に意思決定を行えるようになります。
- コミットスコープ: PGDは、トランザクションの永続性を制御する設定可能な「コミットスコープ」を提供します。デフォルトは高性能な非同期レプリケーションですが、重要なデータについては、トランザクションが大多数(またはすべて)のノードで複製・永続化されたことを確認してからアプリケーションに成功を報告するように設定でき、データ損失を防ぎます。
- 競合管理: マルチマスターシステムでは、異なるノードでの2つの変更が競合する可能性があります。PGDは、これらの競合を検出し、自動的に解決するための高度なシステムを備えており、デフォルトの戦略はコミットタイムスタンプに基づく「後勝ち(last update wins)」です。これにより、データは最終的にすべてのノードで一貫した状態に収束します。
5. リリース 6.1.0 の新機能
6.1.0は、主要な新機能や機能強化を導入する重要なマイナーリリースであり、特に旧バージョンを使用しているユーザーにとって、PGDをより強力で管理しやすくします。
- PGD 4およびPGD 5からのシームレスなアップグレード:
5.8/6.0.2との違い: これは6.1.0の最も重要な機能です。このリリース以前は、PGD 4や5のような旧メジャーバージョンからPGD 6へのアップグレードは、しばしばクラスターの再構築を伴う複雑な手動プロセスでした。PGD 6.1.0は、PGD 4.4.0以降およびPGD 5.9.0以降から直接的なインプレースアップグレードパスをサポートする初のPGD 6バージョンです。これにより、移行プロセスが劇的に簡素化され、リスクが低減し、既存のユーザーが大規模な運用変更なしに最新機能を採用することが可能になります。 - Apache Icebergへのレプリケーション(Analytics Accelerator):
5.8/6.0.2との違い: これは全く新しい機能です。以前は、大規模分析のためにPGDをデータレイクと統合するにはカスタム対応が必要でした。現在、PGD 6.1はデータ変更をApache Icebergデータレイクに直接ストリーミングできます。これにより、本番のPGDクラスターのパフォーマンスに影響を与えることなく、トランザクションデータをスケーラブルでオープンな形式でクエリできるようになり、強力な分析やビジネスインテリジェンスのユースケースが可能になります。 - マテリアライズドビューの完全サポート:
5.8/6.0.2との違い: 以前のバージョンではサポートが限定的または皆無でしたが、PGD 6.1はマテリアライズドビューのコマンド(CREATE、ALTER、REFRESH、DROP)を完全に複製するようになりました。これにより、パフォーマンス最適化やレポート作成によく使用されるマテリアライズドビューがクラスター内の全ノードで一貫して保持され、分散環境で信頼性の高いツールとなります。 - リーダーDDLロックの強化:
5.8/6.0.2との違い: これはパフォーマンスと信頼性の重要な改善点です。以前は、スキーマ変更(DDL)ロックにはクラスター内の大多数のノードからの合意が必要でした。新しいデフォルトのリーダーDDLロックは、ライトリーダーノード上でのみロックを必要とします。これにより、DDL操作がより高速になり、ネットワークの遅延や一時的に利用できないノードに対する回復力が高まります。 - PGD CLIによるノード設定の簡素化:
5.8/6.0.2との違い: pgd node get-configおよびpgd node set-configという新しいコマンドが追加されました。以前は、特定のPostgreSQL設定(GUC)を変更するには、管理者が各ノードに接続して手動で設定ファイルを編集する必要がありました。この機能強化により、これらの設定をクラスター内の任意のノードに対してCLIから直接管理できるようになり、管理が効率化されます。
日本語マニュアルを見る
※ 日本語マニュアルの閲覧には ユーザー登録(パスワード)が必要です。