Postgres Distributed terminology ================================ この用語リストには、 EDB Postgres DistributedPGDに関連する馴染みのない用語が含まれています。 非同期レプリケーション ^^^^^^^^^^^^^^^^^^^^^^ オリジナルノードでトランザクションが完了した後、他のPGDクラスターメンバーにデータをコピーするレプリケーションのタイプ。非同期レプリケーションは、 :ref:`Timing considerations and synchronous replication ` よりも高いパフォーマンスと低いレイテンシーを提供できます。ただし、非同期レプリケーションでは、さまざまなクラスターメンバーに変更が表示されるまでにかかる時間に遅延が発生する場合があります。クラスターは :ref:`最終的な一貫性 <最終的な一貫性>` になりますが、ノードが明らかに互いに同期していない可能性があります。 コミットスコープ ^^^^^^^^^^^^^^^^ PGDクラスターのノードとグループ間でトランザクションがコミットされる方法を管理するためのルール。 :ref:`Timing considerations and synchronous replication ` 、 :ref:`How Quorum Commit works ` 、 :ref:`Group Commit (legacy) ` 、 :ref:`CAMOまたはコミット・アット・モスト・ワンス ` 、 :ref:`熱心な競合解決 <熱心な競合解決>` 、 :ref:`Lag Control ` 、およびその他のPGD機能を構成するために使用されます。 CAMOまたはコミット・アット・モスト・ワンス ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 一部のアプリケーションの高価値トランザクションでは、アプリケーションが正確に1回だけ、フェールオーバーと再試行が発生した場合に1回だけ正常にコミットする必要があります。 PGDでこれが発生するように保証には、 CAMOを有効にして、アプリケーションがトランザクションにアクティブに参加できるようにします。 競合 ^^^^ データはPGDクラスターのノードにわたってレプリケートされるため、あるソースからの変更が別のソースからの変更と衝突する場合があります。これは競合であり、競合の解決で処理できます。競合の解決は、どのソースが正しいまたは優先されるかを決定する一連のルールです。競合は、競合のないデータ型を使用して回避することもできます。 接続マネージャー ^^^^^^^^^^^^^^^^ クライアントが分散クラスター内の適切なノードに接続できるように、PGDは、クライアントがニーズに基づいて適切なノードに接続できる接続管理システムを提供します。 このシステムは、クライアントがクラスターのパフォーマンスと可用性を維持しながら、必要なデータにアクセスできるように設計されています。プロキシシステムとは異なり、この接続管理システムはデータベースインスタンス自分自身に組み込まれているため、より効率的で信頼性の高い接続が可能になります。 コンセンサス ^^^^^^^^^^^^ :ref:`ノードの一部Raftプロトコルバージョン6003以降 <ノードの一部Raftプロトコルバージョン6003以降>` がグループ全体の決定を行う方法。グループ内のノードの数を指定すると、Raftは、決定に投票するマジョリティのコンセンサスノードの数を2プラス1で割ったものを探します。たとえば、書き込みリーダーが選択される場合、グループ内のどのノードが書き込みリーダーになるかについてRaftコンセンサスが求められます。投票メンバーのクォーラムがある場合にのみコンセンサスに到達できます。 クラスター ^^^^^^^^^^ 一般に、クラスターは、エンドユーザーに1つのシステムとして見えるように配置された複数のシステムのグループです。 :ref:`pgd cluster ` および :ref:`Postgresクラスター ` も参照してください。 DDLデータ定義言語 ^^^^^^^^^^^^^^^^^ データベースの構造の定義と管理を処理するSQLコマンドのサブセット。 DDLステートメントは、データベース内のオブジェクトつまりスキーマ、テーブル、インデックスを作成、変更、および削除できます。一般的なDDLコマンドは、 CREATE、ALTER、およびDROPです。 DMLデータ操作言語 ^^^^^^^^^^^^^^^^^ データベースに保持されているデータの操作を処理するSQLコマンドのサブセット。 DMLステートメントは、データベース内のテーブルの行を作成、変更、および削除できます。一般的なDMLコマンドは、 INSERT、UPDATE、およびDELETEです。 耐久性 ^^^^^^ 持続性は、トランザクションがコミットされると、システム障害が発生した場合でもコミットされたままであることを保証します。 PGDは、 :ref:`コミットスコープへの移行 <コミットスコープへの移行>` を介してこれを管理します。 熱心な ^^^^^^ 競合する可能性のある着信トランザクションを検出し、それらのいずれかを「迅速に」中止して一貫性を維持することにより競合を回避する同期コミットモード。 最終的な一貫性 ^^^^^^^^^^^^^^ 異なるクラスターメンバーの同じ項目への変更を記述する分散コンピューティング一貫性モデルは、最終的に同じ値に収束します。競合解決と競合のないレプリケートデータ型を使用した非同期論理レプリケーションは、PGDの最終的一貫性を示します。 フェイルオーバー ^^^^^^^^^^^^^^^^ 高可用性データベースクラスターの障害を認識し、一貫性と可用性を維持するためのアクションを実行する自動プロセス。目標は、ダウンタイムとデータの損失を最小限に抑えることです。 グループコミット ^^^^^^^^^^^^^^^^ 複数のPGDノードがコミット時にトランザクションを正常に受信および確認する必要がある同期コミットモード。 即時一貫性 ^^^^^^^^^^ すべてのレプリカが同期的かつ同時に更新される分散コンピューティングモデル。このモデルでは、書き込みが完了した後のすべての読み取りが、すべてのノードで同じ値を参照します。このアプローチの欠点は、パフォーマンスへの悪影響です。 遅延制御 ^^^^^^^^ Lag Controlは、セカンダリノードがプライマリノードから大きく遅れないようにするために使用される調整メカニズムです。ノードのレプリケーション遅延が設定されたしきい値を超えると、PGDは元のノードでの取り込みを自動的に調整して、クラスターの残りの部分が追いつくようにします。 論理レプリケーション ^^^^^^^^^^^^^^^^^^^^ データベース内の変更をレプリケートするより効率的な方法。物理的ストリーミングレプリケーションは元のデータベースのディスクブロックを複製しますが、論理レプリケーションは代わりに、基になる物理的記憶形式とは無関係に変更を取得し、変更を表示するようにサブスクライブしたすべてのシステムに公開します。次に、各サブスクライバーは変更をローカルに適用します。論理レプリケーションは、ほとんどのDDLコマンドをサポートできません。 論理スタンバイノード ^^^^^^^^^^^^^^^^^^^^ 論理スタンバイノードは、クラスター内のデータの読み取り専用レプリカを提供するために使用されます。これらは加入者専用ノードに似ていますが、より柔軟になるように設計されており、より幅広いシナリオで使用できます。 ノード ^^^^^^ 分散システムの要素の総称。ノードは任意のサービスのホストとして機能できます。 PGDでは、 :ref:`Creating PGD nodes ` はPostgresデータベース、 BDR拡張機能、およびConnection Managerを実行します。 通常、高可用性を実現するために、各ノードは別の物理ハードウェアで実行されますが、常にそうとは限りません。 ノードグループ ^^^^^^^^^^^^^^ PGDクラスター内のPGDノードをグループに編成して、クラスターの論理操作を反映できます。たとえば、特定の物理的な場所にあるデータノードは、その場所の専用ノードグループの一部であることができます。 各グループは、 :ref:`コンセンサスタイムアウトの設定 <コンセンサスタイムアウトの設定>` アルゴリズムを使用してリーダーを選択します。データ固有のグループでは、このリーダーは書き込みリーダーとして機能し、すべての着信書き込み操作を処理して一貫性を維持します。 グループはデータのレプリケーションを管理し、「トップレベル」グループはクラスター全体を表し、他のすべてのサブグループの親として機能します。 PGDクラスター ^^^^^^^^^^^^^ エンドユーザーには1つのシステムとして見えながら、単一障害点を回避するように配置された複数の冗長データベースシステムとプロキシのグループ。 PGDクラスターは、Dockerインスタンス、クラウドインスタンス、または「ベア」Linuxホスト、またはこれらのプラットフォームの組み合わせで実行できます。 PGDクラスターには、バックアップノードを含めることもできます。クラスター内のデータノードは、トップレベルグループにグループ化され、さまざまなローカル :ref:`ノードグループ <ノードグループ>` にグループ化されます。 PGDノード ^^^^^^^^^ PGDクラスターには、データベースを実行し、PGDクラスターに参加するノードがあります。一般的なPGDノードは、 Postgresデータベース、 BDR拡張機能、およびConnection Managerを実行します。 PGDモードは *データノード* とも呼ばれ、データを保存することを示唆しています。ただし、一部のPGDノード、特に :ref:`Witnessノード ` はそれを行いません。 物理的レプリケーション ^^^^^^^^^^^^^^^^^^^^^^ 物理レプリケーションは、1つ以上のスタンバイクラスターメンバーに変更されるときにデータベースディスクブロックの正確なコピーを作成することにより、サーバーをレプリケートする簡単に実装された方法を提供します。ただし、使用方法には制限があります。たとえば、1つのマスターノードのみが書き込みトランザクションを実行できます。また、この方法では、すべてのクラスターメンバーが、同じオペレーティングシステムとCPUアーキテクチャを備えたデータベースソフトウェアの同じメジャーバージョンを使用している必要があります。 Postgresクラスター ^^^^^^^^^^^^^^^^^^ 通常、PostgreSQLでは、単一のサーバーで実行されている多数のデータベースをデータベースのクラスターと呼びます。この種類のPostgresクラスターは、可用性が高くありません。高可用性と冗長性を取得するには、 :ref:`pgd cluster ` が必要です。 クォーラム ^^^^^^^^^^ クォーラムとは、分散投票に参加するために必要な投票ノードの最小数です。これにより、行われた決定が有効であることが保証されます。たとえば、 PGDクラスターで :ref:`ノードの一部Raftプロトコルバージョン6003以降 <ノードの一部Raftプロトコルバージョン6003以降>` :ref:`コンセンサスタイムアウトの設定 <コンセンサスタイムアウトの設定>` が必要な場合、投票に参加する最小数の投票ノードが必要です。 5ノードクラスターの場合、クォーラムはクラスター投票の3ノードです。コンセンサスは5/2+1ノード、3つのノードが同じように投票します。投票ノードが2つだけの場合、コンセンサスは決して確立されません。 PGDでは、 :ref:`DDL locking details ` およびRaftの決定にクォーラムが必要です。 クォーラムコミット ^^^^^^^^^^^^^^^^^^ ノードがローカルにコミットする前に、すべての参加ノードにわたってコミット決定を調整することにより、分散トランザクションの一貫性を保証するコミットスコープの種類。すべてのノードは一緒にコミットまたはロールバックします。熱心な競合解決は常にアクティブです。 レプリケートされた利用可能なフォールトトレランスRaft ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 分散クラスター内のマシンのクォーラムからの投票を使用してコンセンサスを確立するコンセンサスアルゴリズム。 PGDは、グループトップレベルまたはローカル内でRaftを使用して、書き込みリーダーであるノードを確立します。 読み取りスケーラビリティ ^^^^^^^^^^^^^^^^^^^^^^^^ 増加する読み取りワークロードを処理するシステムの機能。たとえば、PGDは1つ以上のリードレプリカノードをクラスターに導入し、アプリケーションにプライマリノードに書き込みを指示し、レプリカノードに読み取りを行わせることができます。読み取りワークロードの増加に応じて、リードレプリカノードの数を増加してパフォーマンスを維持できます。 サブスクリプション ^^^^^^^^^^^^^^^^^^ PGDノードは、データに加えられた変更を関心のあるノードに公開します。他のPGDノードは、これらの変更をサブスクライブするように求めます。この動作により、サブスクリプションが作成され、各ノードが更新されるメカニズムです。 PGDノードは、他のPGDノードの変更を双方向にサブスクライブします。 スイッチオーバー ^^^^^^^^^^^^^^^^ アプリケーションまたはプロキシとクラスター内のアクティブなデータベースノード間の接続の計画的な変更。通常はメンテナンスのために行われます。 同期レプリケーション ^^^^^^^^^^^^^^^^^^^^ 変更がすべての参加ノードで同時に更新される場合、通常は2フェーズコミットを活用します。このアプローチでは、コミットする前に変更を複製し、競合を解決しますが、ノード全体で必要な調整のため、レイテンシーのパフォーマンスコストが発生します。 サブスクライバー専用ノード ^^^^^^^^^^^^^^^^^^^^^^^^^^ PGDクラスターは、双方向レプリケーションをベースとしています。ただし、読み取り専用サーバーが必要な場合など、一部のユースケースでは、双方向レプリケーションは必要ありません。この場合、加入者専用ノードが使用されます。データベース内の変更のみをサブスクライブして自分自身を最新の状態に保ち、ノードで直接実行に対して正しい結果を提供します。この機能を使用して、PGDクラスターでのホリゾンタル読み取りのスケーラビリティを有効にできます。これらは2つの方法で構成できます。 - データグループ内 これらのノードは、標準のデータノードと並んで読み取り専用レプリカとして機能します。これらはデータへのローカルアクセスを提供しますが、特定のレプリケーションの最適化のメリットはありません。 - 加入者専用グループ内 この構成には、書き込みリーダーがありません。すべてのノードは厳密に読み取り専用であり、PGDはレプリケーションプロセスを合理化するオプションの最適化を適用できます。 2フェーズコミット2PC ^^^^^^^^^^^^^^^^^^^^ 複数のデータベースノード間の一貫性を実現するためのマルチステップのプロセス。最初のフェーズでは、元のノードで準備され、すべての参加ノードに送信されるトランザクションが表示されます。各参加ノードは、トランザクションを適用できることを検証し、その準備ができていることを元のノードに通知します。これは準備フェーズです。第2フェーズでは、すべての参加ノードが準備ができていることを通知した場合、元のノードはトランザクションのコミットを続行し、参加ノードにもコミットするように通知します。これはコミットフェーズです。準備フェーズで、いずれかのノードが準備ができていないことを通知した場合、トランザクション全体が中止されます。このプロセスにより、すべてのノードが同じ変更を取得します。 垂直スケーリングまたはスケールアップ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oracle Exadataなど、そのアーキテクチャの物理的制限に到達するまで、特定のワークロードをサポートするリソースCPU、メモリ、ストレージ、ネットワークを増加する従来のコンピューティングアプローチ。 Witnessノード ^^^^^^^^^^^^^ Witnessノードは、主にクラスターがコンセンサスを確立するのを支援するために機能します。コンセンサスを確立するには、奇数のデータノードが必要です。リソースが制限されている場合、監視ノードを使用してクラスターの決定に参加できますが、データを複製することはできません。データを保持しないことは、スタンバイサーバーとして動作できない、または同期コミットのマジョリティを提供できないことを意味します。 ライトリーダー ^^^^^^^^^^^^^^ Always-onアーキテクチャでは、ノードがアプリケーションの正しい接続エンドポイントとして選択されます。このノードは書き込みリーダーと呼ばれます。選択すると、 PGD Connection Managerはクエリと更新をルーティングします。 1つのノードのみが書き込みを受信するため、意図しないマルチノードの書き込みを回避できます。書き込みリーダーは、データノードのクォーラムのコンセンサスによって選択されます。書き込みリーダーが使用できなくなると、データノードは別のノードを選択して書き込みリーダーになります。書き込みリーダーではないノードは、 *シャドウノード* と呼ばれます。 ライター ^^^^^^^^ :ref:`無効になったサブスクリプションへの対応 <無効になったサブスクリプションへの対応>` がデータ変更をPGDノードに配信すると、データベースサーバーはライタと呼ばれるワーカープロセスに、これらの変更を適用するタスクを実行します。