【動画で製品解説】EDB Postgres Distributed（PGD）6.0.2
音声ガイド１：概要早わかり
音声ガイド２：何が変わったか？
エグゼクティブサマリー
PGD 5.8.0から6.0.2への移行は、簡素化、信頼性、使いやすさに焦点を当てた重要な進化を示しています。最も大きな変更点は、外部コンポーネントであったPGDプロキシが、完全に統合されたコネクションマネージャーに置き換えられたことです。これにより、アーキテクチャとデプロイメントが簡素化されます。また、PGD 6では、PGD EssentialとPGD Expandedという新しい製品戦略を導入し、新規ユーザーの導入障壁を低減させています。強力な新しいCLIコマンド（pgd node setup）と、すぐに利用可能な事前定義済みの耐久性設定（コミットスコープ）によって、セットアップと管理のエクスペリエンス全体が効率化されています。
1. PGD 6.0.2は5.8.0から何が変わったか？
バージョン間の変更は根本的なもので、製品のアーキテクチャ、デプロイメント手法、製品ラインナップに影響を与えています。
- アーキテクチャの転換：PGDプロキシから統合コネクションマネージャーへ
- PGD 5.8.0： PGDは外部のPGDプロキシサービスに依存していました。これは、トラフィックを適切なデータベースノードにルーティングするために、個別にデプロイ、設定、管理する必要があるコンポーネントでした (PGD 5.8.0, p. 198)。
- PGD 6.0.2： PGDプロキシは、新しく組み込まれたコネクションマネージャーに完全に置き換えられました。このマネージャーは各PGDデータノード内で動作するバックグラウンドワーカープロセスであり、外部プロキシサービスが不要になりました。
- 製品戦略：PGD Essentialエディションの導入
- PGD 5.8.0： PGDは単一の強力で設定自由度の高い製品として提供されていました。
- PGD 6.0.2： 製品ラインが2つのエディションに分かれました。高可用性と災害復旧をシンプルかつ容易に始められるように設計された「簡素化バージョン」として、新しいPGD Essentialエディションが導入されました。これにはノード数などの制限がありますが、フル機能のPGD Expandedエディションへの明確なアップグレードパスを提供します。
- デプロイメントとセットアッププロセス
- PGD 5.8.0： 手動でクラスターをセットアップするには、bdr.create_node、bdr.create_node_group、bdr.join_node_groupといった一連のSQL関数を実行する必要がありました (PGD 5.8.0, p. 114)。
- PGD 6.0.2： 強力な新しいCLIコマンド**pgd node setup**が導入されました。この単一のコマンドで、初期クラスターの作成、ノードの追加、設定が行えるようになり、デプロイプロセスが大幅に簡素化されました
- 中核的な識別方法：ノードUUIDの採用
- PGD 5.8.0： ノードは主にユーザー定義の名前で識別されていました。
- PGD 6.0.2： PGDは各ノードインスタンスを一意に識別するためにUUIDを使用するようになりました。これにより、あるノードが切り離された後、同じ名前の新しいノードが再参加した場合でも、それぞれが不変の個別のIDを持つことが保証されます。この変更に伴い、レプリケーションスロットとオリジンの命名規則もより堅牢になりました。
2. PGD 6.0.2の主な新機能と改善点
6.0.1リリースを基盤とするPGD 6.0.2では、使いやすさと信頼性を向上させるためのいくつかの主要な改善が導入されています。
- 内蔵コネクションマネージャー： 前述の通り、これが最大の改善点です。クライアント接続を適切なライトリーダーに自動でルーティングし、セッションプーラーを含み、外部ソフトウェアなしで専用の読み取り専用ポートを提供します (PGD 6.0.2, p. 499)。
- 事前定義済みコミットスコープ： PGD 6では、local protect、lag protect、majority protect、adaptive protectの4つの標準コミットスコープが導入されました。これらはパフォーマンスとデータ一貫性のバランスを取るための事前定義された耐久性プロファイルを提供し、以前は複雑だった手動設定を簡素化します (PGD 6.0.2, pp. 50-51, 499)。
- 効率化されたCLIによるクラスターセットアップ： 新しいpgd node setupコマンドにより、ユーザーはコマンドラインから直接初期クラスター作成やノード追加を行えるようになり、デプロイメントがより柔軟かつ自動化しやすくなりました (PGD 6.0.2, p. 499)。
- シーケンスの自動変換： PGD 6では、ノードがグループに参加する際に、そのローカルシーケンスがbdr.default_sequence_kind GUCに基づいてグローバルに一意な分散シーケンスに自動的に変換されます。これにより、以前はシーケンスの競合を防ぐために必要だった手動手順が不要になりました (PGD 6.0.2, pp. 129, 499)。
- ノードUUIDによる信頼性の向上： 内部識別子としてUUIDを使用することで、特にノードが頻繁に交換される動的な環境において、クラスターの堅牢性が向上します。これにより、ノード名の再利用によって発生しうる重大な複製エラーを防ぎます。
3. これらの変更がもたらす顧客へのメリット
これらの変更は、複雑さの軽減、信頼性の向上、運用負担の削減に焦点を当てており、顧客に直接的な大きなメリットをもたらします。
- 総所有コスト（TCO）の削減と複雑さの軽減： 外部PGDプロキシが統合コネクションマネージャーに置き換えられたことは、最大のメリットです。これにより、顧客はプロキシサーバー群を個別にプロビジョニング、設定、パッチ適用、監視する必要がなくなりました。全体的なアーキテクチャが簡素化され、潜在的な障害点が減り、運用オーバーヘッドが削減されます。
- 導入障壁の低下と迅速な採用： PGD Essentialの導入により、新規ユーザー向けのシンプルでガイド付きのパスが提供されます。顧客は基本的な高可用性ソリューションから容易に始め、ニーズの進化に応じてPGD Expandedのより高度な機能へと移行できるため、製品がより導入しやすくなりました。
- より迅速で信頼性の高いデプロイメント： 新しい**pgd node setup CLIコマンド**は、冪等性のある単一コマンドでクラスター作成を効率化します。これは自動化（例：Ansible, Terraform, シェルスクリプト）に非常に適しており、より速く、一貫性があり、エラーが発生しにくいデプロイメントを実現します。
- 耐久性と一貫性管理の簡素化： 事前定義済みコミットスコープにより、顧客は分散システムの専門家でなくても、望ましいレベルのデータ保護を簡単に設定できます。「majority protect」のようなプロファイルを選択するだけで、データの耐久性がノードの過半数にわたって保証されるため、以前は複雑だったタスクが簡素化され、設定ミスのリスクが低減します。
- クラスターの堅牢性の向上： 内部識別子としてノードUUIDを使用することで、運用上の変更（例：障害ノードの交換）に対するクラスターの回復力（レジリエンス）を高めます。これにより、ノード名の再利用によって発生しうる、検知しにくい重大な複製エラーを防ぎ、分散システム全体の信頼性とデータ整合性を向上させます。
日本語マニュアルを見る
※ 日本語マニュアルの閲覧には ユーザー登録（パスワード）が必要です。
