Terminology

この用語リストには、EDB Postgres Distributedに関連する馴染みのない用語が含まれています。

非同期レプリケーション

オリジナルノードでトランザクションが完了した後、他のPGDクラスターメンバーにデータをコピーするレプリケーションのタイプ。非同期レプリケーションは、 Near/Farアーキテクチャでの同期レプリケーション よりも高いパフォーマンスと低いレイテンシーを提供できます。ただし、非同期レプリケーションでは、さまざまなクラスターメンバーに変更が表示されるまでにかかる時間に遅延が発生する場合があります。クラスターは 最終的な一貫性 になりますが、ノードが明らかに互いに同期していない可能性があります。

コミットスコープ

PGDクラスターのノードとグループ間でトランザクションがコミットされる方法を管理するためのルール。 Near/Farアーキテクチャでの同期レプリケーション 、 耐久性オプショングループコミット/ CAMO 、 CAMOまたはコミット・アット・モスト・ワンス 、 熱心な 、Lag Control、およびその他のPGD機能を構成するために使用されます。

CAMOまたはコミット・アット・モスト・ワンス

一部のアプリケーションの高価値トランザクションでは、アプリケーションが正確に1回だけ、フェールオーバーと再試行が発生した場合に1回だけ正常にコミットする必要があります。 PGDでこれが発生するように保証には、 CAMOを有効にして、アプリケーションがトランザクションにアクティブに参加できるようにします。

競合

データはPGDクラスターのノードにわたってレプリケートされるため、あるソースからの変更が別のソースからの変更と衝突する場合があります。これは競合であり、競合の解決で処理できます。競合の解決は、どのソースが正しいまたは優先されるかを決定するルールセットです。競合は、競合のないデータ型を使用して回避することもできます。

コンセンサス

Monitoring Raftコンセンサス がグループ全体の決定を行う方法。グループ内のノードの数を指定すると、Raftは、決定に投票するマジョリティのコンセンサスノードの数を2プラス1で割ったものを探します。たとえば、書き込みリーダーが選択される場合、グループ内のどのノードが書き込みリーダーになるかについてRaftコンセンサスが求められます。投票メンバーのクォーラムがある場合にのみコンセンサスに到達できます。

クラスター

一般に、クラスターは、エンドユーザーに1つのシステムとして見えるように配置された複数のシステムのグループです。 PGDクラスターへのアクセス および Postgresクラスター も参照してください。

DDLデータ定義言語

データベースの構造の定義と管理を処理するSQLコマンドのサブセット。 DDLステートメントは、データベース内のオブジェクトつまりスキーマ、テーブル、インデックスを作成、変更、および削除できます。一般的なDDLコマンドは、 CREATE、ALTER、およびDROPです。

DMLデータ操作言語

データベースに保持されているデータの操作を処理するSQLコマンドのサブセット。 DMLステートメントは、データベース内のテーブルの行を作成、変更、および削除できます。一般的なDMLコマンドは、 INSERT、UPDATE、およびDELETEです。

熱心な

競合する可能性のある着信トランザクションを検出し、それらのいずれかを「迅速に」中止して一貫性を維持することにより競合を回避する同期コミットモード。

最終的な一貫性

異なるクラスターメンバーの同じ項目への変更を記述する分散コンピューティング一貫性モデルは、最終的に同じ値に収束します。競合解決と競合のないレプリケートデータ型を使用した非同期論理レプリケーションは、PGDの最終的一貫性を示します。

フェイルオーバー

高可用性データベースクラスターの障害を認識し、一貫性と可用性を維持するためのアクションを実行する自動プロセス。目標は、ダウンタイムとデータの損失を最小限に抑えることです。

グループコミット

複数のPGDノードがコミット時にトランザクションを正常に受信および確認する必要がある同期コミットモード。

即時一貫性

すべてのレプリカが同期的かつ同時に更新される分散コンピューティングモデル。このモデルでは、書き込みが完了した後のすべての読み取りが、すべてのノードで同じ値を参照します。このアプローチの欠点は、パフォーマンスへの悪影響です。

論理レプリケーション

データベース内の変更をレプリケートするより効率的な方法。物理的ストリーミングレプリケーションは元のデータベースのディスクブロックを複製しますが、論理レプリケーションは代わりに、基になる物理的記憶形式とは無関係に変更を取得し、変更を表示するようにサブスクライブしたすべてのシステムに公開します。次に、各サブスクライバーは変更をローカルに適用します。論理レプリケーションは、ほとんどのDDLコマンドをサポートできません。

ノード

分散システムの要素の総称。ノードは任意のサービスのホストとして機能できます。 PGDでは、 PGDノードのセットアップ はPostgresデータベース、 BDR拡張機能、およびConnection Managerを実行します。

通常、高可用性を実現するために、各ノードは別の物理ハードウェアで実行されますが、常にそうとは限りません。

ノードグループ

PGDクラスター内のPGDノードをグループに編成して、クラスターの論理操作を反映できます。たとえば、特定の物理的な場所にあるデータノードは、その場所の専用ノードグループの一部であることができます。

PGDクラスター

エンドユーザーには1つのシステムとして見えながら、単一障害点を回避するように配置された複数の冗長データベースシステムとプロキシのグループ。 PGDクラスターは、Dockerインスタンス、クラウドインスタンス、または「ベア」Linuxホスト、またはこれらのプラットフォームの組み合わせで実行できます。 PGDクラスターには、バックアップノードを含めることもできます。クラスター内のデータノードは、トップレベルグループにグループ化され、さまざまなローカル ノードグループ にグループ化されます。

PGDノード

PGDクラスターには、データベースを実行し、PGDクラスターに参加するノードがあります。一般的なPGDノードは、 Postgresデータベース、 BDR拡張機能、およびConnection Managerを実行します。 PGDモードは データノード とも呼ばれ、データを保存することを示唆しています。ただし、一部のPGDノード、特に Witnessノード はそれを行いません。

物理的レプリケーション

物理レプリケーションは、1つ以上のスタンバイクラスターメンバーに変更されるときにデータベースディスクブロックの正確なコピーを作成することにより、サーバーをレプリケートする簡単に実装された方法を提供します。ただし、使用方法には制限があります。たとえば、1つのマスターノードのみが書き込みトランザクションを実行できます。また、この方法では、すべてのクラスターメンバーが、同じオペレーティングシステムとCPUアーキテクチャを備えたデータベースソフトウェアの同じメジャーバージョンを使用している必要があります。

Postgresクラスター

通常、PostgreSQLでは、単一のサーバーで実行されている多数のデータベースをデータベースのクラスターと呼びます。この種類のPostgresクラスターは、可用性が高くありません。高可用性と冗長性を取得するには、 PGDクラスターへのアクセス が必要です。

クォーラム

クォーラムとは、分散投票に参加するために必要な投票ノードの最小数です。これにより、行われた決定が有効であることが保証されます。たとえば、 PGDクラスターで Raft Monitoring Raftコンセンサス が必要な場合、投票に参加する最小数の投票ノードが必要です。 5ノードクラスターの場合、クォーラムはクラスター投票の3ノードです。コンセンサスは5/2+1ノード、3つのノードが同じように投票します。投票ノードが2つだけの場合、コンセンサスは決して確立されません。 PGDでは、 DDL locking details およびRaftの決定にクォーラムが必要です。

レプリケートされた利用可能なフォールトトレランスRaft

分散クラスター内のマシンのクォーラムからの投票を使用してコンセンサスを確立するコンセンサスアルゴリズム。 PGDは、グループトップレベルまたはローカル内でRaftを使用して、書き込みリーダーであるノードを確立します。

読み取りスケーラビリティ

増加する読み取りワークロードを処理するシステムの機能。たとえば、PGDは1つ以上のリードレプリカノードをクラスターに導入し、アプリケーションにプライマリノードに書き込みを指示し、レプリカノードに読み取りを行わせることができます。読み取りワークロードの増加に応じて、リードレプリカノードの数を増加してパフォーマンスを維持できます。

サブスクリプション

PGDノードは、データに加えられた変更を関心のあるノードに公開します。他のPGDノードは、これらの変更をサブスクライブするように求めます。この動作により、サブスクリプションが作成され、各ノードが更新されるメカニズムです。 PGDノードは、他のPGDノードの変更を双方向にサブスクライブします。

スイッチオーバー

アプリケーションまたはプロキシとクラスター内のアクティブなデータベースノード間の接続の計画的な変更。通常はメンテナンスのために行われます。

同期レプリケーション

変更がすべての参加ノードで同時に更新される場合、通常は2フェーズコミットを活用します。このアプローチでは、コミットする前に変更を複製し、競合を解決しますが、ノード全体で必要な調整のため、レイテンシーのパフォーマンスコストが発生します。

サブスクライバー専用ノード

PGDクラスターは、双方向レプリケーションをベースとしています。ただし、読み取り専用サーバーが必要な場合など、一部のユースケースでは、双方向レプリケーションは必要ありません。この場合、加入者専用ノードが使用されます。データベース内の変更のみをサブスクライブして自分自身を最新の状態に保ち、ノードで直接実行に対して正しい結果を提供します。この機能を使用して、PGDクラスターでのホリゾンタル読み取りのスケーラビリティを有効にできます。

2フェーズコミット2PC

複数のデータベースノード間の一貫性を実現するためのマルチステップのプロセス。最初のフェーズでは、元のノードで準備され、すべての参加ノードに送信されるトランザクションが表示されます。各参加ノードは、トランザクションを適用できることを検証し、その準備ができていることを元のノードに通知します。これは準備フェーズです。第2フェーズでは、すべての参加ノードが準備ができていることを通知した場合、元のノードはトランザクションのコミットを続行し、参加ノードにもコミットするように通知します。これはコミットフェーズです。準備フェーズで、いずれかのノードが準備ができていないことを通知した場合、トランザクション全体が中止されます。このプロセスにより、すべてのノードが同じ変更を取得します。

垂直スケーリングまたはスケールアップ

Oracle Exadataなど、そのアーキテクチャの物理的制限に到達するまで、特定のワークロードをサポートするリソースCPU、メモリ、ストレージ、ネットワークを増加する従来のコンピューティングアプローチ。

Witnessノード

Witnessノードは、主にクラスターがコンセンサスを確立するのを支援するために機能します。コンセンサスを確立するには、奇数のデータノードが必要です。リソースが制限されている場合、監視ノードを使用してクラスターの決定に参加できますが、データを複製することはできません。データを保持しないことは、スタンバイサーバーとして動作できない、または同期コミットのマジョリティを提供できないことを意味します。

ライトリーダー

Always-onアーキテクチャでは、ノードがアプリケーションの正しい接続エンドポイントとして選択されます。このノードは書き込みリーダーと呼ばれます。選択すると、 PGD Connection Managerはクエリと更新をルーティングします。 1つのノードのみが書き込みを受信するため、意図しないマルチノードの書き込みを回避できます。書き込みリーダーは、データノードのクォーラムのコンセンサスによって選択されます。書き込みリーダーが使用できなくなると、データノードは別のノードを選択して書き込みリーダーになります。書き込みリーダーではないノードは、 シャドウノード と呼ばれます。

ライター

EDB_SUBSCRIPTION_TOKEN がデータ変更をPGDノードに配信すると、データベースサーバーはライタと呼ばれるワーカープロセスに、これらの変更を適用するタスクを実行します。