Commit At Most Once#

Commit At Most Once CAMO機能の目的は、アプリケーションが複数回コミットしないようにすることです。

CAMOがないと、 COMMIT が送信された後にクライアントが接続を失うと、アプリケーションはサーバーから応答を受け取らない場合があるため、トランザクションがコミットしたかどうかがわかりません。

アプリケーションは、次の2つのオプションの間を簡単に決定できません。

場合によっては、データが2回入力される可能性があるため、同じデータでトランザクションを再試行します。
トランザクションを再試行せず、データがまったく処理されないリスク

これらはいずれも、高値のデータに関する重大なエラーです。

この状況を回避する1つの方法は、トランザクションの一意のインデックスを持つテーブルに少なくとも1つのINSERT を含めることです。ただし、これはアプリケーションのデザインに依存し、アプリケーション固有のエラー処理ロジックが必要であるため、すべての場合に効果的ではありません。

PGDのCAMO機能は、より一般的なソリューションを提供し、INSERT を必要としません。 bdr.commit_scope によってアクティブ化されると、アプリケーションはトランザクション識別子が既に割り当てられている場合を含むメッセージを受信します。それ以外の場合、トランザクションの最初のwriteステートメントはその情報をクライアントに送信します。

アプリケーションが明示的なCOMMIT を送信する場合、プロトコルは、COMMIT が送信される前にアプリケーションがトランザクション識別子の通知を受信することを保証します。サーバーがCOMMIT に応答しない場合、アプリケーションはトランザクション識別子を使用して別のPGDノードからトランザクションの最終ステータスを要求することにより、このエラーを処理できます。以前のトランザクションステータスがわかっている場合、アプリケーションはトランザクションを再試行するかどうかを安全に決定できます。

CAMOは、同じPGDグループからの2つのPGDノードであるパートナーノードのペアを作成することにより機能します。この操作モードでは、ペアの各ノードは、他のピアで実行された最近のトランザクションの結果を知っており、特にニーズに応じて、COMMIT 中に切断されたトランザクションの結果を知っています。アプリケーションからトランザクションを受信するノードは「オリジン」と呼ばれ、これらのトランザクションを確認するノードは「パートナー」と呼ばれます。ただし、 CAMOペアのノードのCAMO構成に違いはありません。ペアは対称です。

警告

CAMOでは、高度なエラー処理を利用するには、ユーザーのアプリケーションを変更する必要があります。パラメーターを有効にするだけでは保護を得るには十分ではありません。リファレンスクライアント実装は、要求に応じてお客様に提供されます。

要件#

CAMOを使用するには、アプリケーションはマルチステートメント要求の一部としてではなく、別の要求として明示的なCOMMIT メッセージを発行する必要があります。 CAMOは、プロシージャーまたは暗黙的なコミットを使用する単一ステートメントトランザクションから発行されたトランザクションのステータスを提供できません。

構成#

CAMOの構成は、コミットスコープを介して発生します。

障害シナリオ#

さまざまな構成では、さまざまな障害シナリオが発生します。

レシーバー側のデータの永続性#

デフォルトでは、PGLライタはリモートノードからトランザクションを適用するときにbdr.synchronous_commit = off モードで動作します。これはCAMOにも当てはまります。つまり、トランザクションは、 CAMOパートナーのディスクに到達する前に、オリジンノードに確認されます。クラッシュまたはハードウェア障害が発生した場合、確認されたトランザクションはCAMOパートナーで自分自身では回復できない場合があります。これは、 CAMOパートナーノードが復旧するとトランザクションを再配布するため、 CAMO起点ノードが動作している限り問題ではありません。

これは、 CAMOが単一ノードの障害から保護できることを意味します。これは、ローカルモードおよびリモート書き込みと同様に、またはそれと組み合わせて正しいです。

CAMOペアの両方のノードの停止をカバーするには、 bdr.synchronous_commit = local を使用して、コミット前の確認の前にフラッシュを強制できます。これは、リモート書き込みモードでもローカルモードでも動作せず、レイテンシーの影響を受けやすいコミットパスにあるCAMOパートナーのI/O要件により、パフォーマンスに影響を与えます。

非同期モード#

コミットスコープでDEGRADE ON ... TO ASYNC 句が使用される場合、ノードはCAMOパートナーの準備ができているかどうかを検出します。そうでない場合、一時的に非同期ローカルモードに切り替わります。このモードの場合、ノードはCAMOモードに戻すまで、ローカルにトランザクションをコミットします。

これでは、 COMMITステータスを取得することはできませんが、一貫性よりも可用性を選択できます。このモードは、単一ノードの障害を許容できます。 CAMOペアの両方のノードに障害が発生した場合、可用性を維持するために一致しないコミット決定を選択する可能性があり、データの不一貫性が発生します。

CAMOパートナーが準備ができているように切り替えるには、接続する必要があり、推定キャッチアップインターバルはTO ASYNC のtimeout 値を下回る必要があります。 bdr.is_camo_partner_ready を使用してCAMOパートナーの現在の準備状況を確認できます。bdr.node_replication_rates は、キャッチアップ時間の現在の推定値を提供します。

CAMO保護から非同期モードへのスイッチは、コミットがTO ASYNC のtimeout 値を超えるため、またはCAMOパートナーが既に知られている場合、コミット時に切断されるため、実際のCAMOトランザクションによってのみトリガーされます。このスイッチは、推定キャッチアップインターバルとは無関係です。 CAMOペアが、現在のノードがenable_proxy_routing ノードグループオプションで構成されたグループの書き込みリードであることを必要とするように構成されている場合。構文については、

コミットスコープを参照してください。これにより、分離されたノードが非同期モードに切り替わらないことによるスプリットブレイン状況を防ぐことができます。

CAMOグループにenable_proxy_routing が設定されていない場合、オリジンノードはすぐに非同期モードに切り替わります。

非同期モードからCAMOモードへの切り替えは、接続を開始するCAMOパートナーノードに依存します。 CAMOパートナーは、少なくとも30秒ごとに再接続を試行します。したがって、接続が再確立された後、 CAMOパートナーが元のノードに接続するまでに最大30秒かかる場合があります。 CAMOパートナーに蓄積された遅延は、 CAMO保護モードへの切り替えをさらに遅延させます。

通常のCAMOオペレーション中とは異なり、非同期モードでは、コミットオーバーヘッドの追加はありません。これは、 CAMOペアが通常処理できるよりも多くのトランザクションをノードが継続的に処理できるため、問題になる可能性があります。 CAMOパートナーが最終的に再接続してトランザクションを適用した場合でも、このような状況では遅延が増加するだけであり、 CAMO保護の再確立を妨げます。トランザクションのスループットを人為的に調整するために、PGDはbdr.camo_local_mode_delay 設定を提供します。これにより、ローカルモードでCOMMIT を任意の時間遅延できます。予想されるワークロード中に通常のCAMOモードでコミット時間を測定し、それに応じてこの遅延を構成することをお勧めします。デフォルトは5ミリ秒で、これは非同期ネットワークと比較的迅速なCAMOパートナーの応答を反映しています。

アーキテクチャと可用性要件を考慮して、非同期モードを許可するかどうかの選択を検討します。次の例は、詳細を提供します。

例#

この例では、互いにCAMOパートナーである2つのPGDノードを使用したセットアップを検討します。

edb_notranlate_0 このCAMOコミットスコープが正当であるためには、グループ内のノードの数が正確に2である必要があります。複数のノードで構成されるグループでALLまたはANY 2を使用すると、非定量化グループ式が明確なペアに解決されないため、エラーになりますノードの。

非同期モードの場合#

非同期モードが許可されている場合、単一障害点はありません。 1つのノードに障害が発生した場合

他のノードは、障害が発生したノードでCOMMIT 中に切断されたすべてのトランザクションのステータスを判断できます。
新しい書き込みトランザクションが許可されます。 2番目のノードにも障害が発生した場合、その時点でコミットされていたトランザクションの結果は不明です。

非同期モードなし#

非同期モードが許可されない場合、各ノードはトランザクションをコミットするために他のノードを必要とします。つまり、各ノードは単一障害点です。 1つのノードに障害が発生した場合

他のノードは、障害が発生したノードでCOMMIT 中に切断されたすべてのトランザクションのステータスを判断できます。
ノードが復旧するまで、新しい書き込みトランザクションは防止されます。

アプリケーションの使用#

概要と要件#

CAMOは、再試行ループとクライアント側での特定のエラー処理に依存しています。それには3つの側面があります。

トランザクションのCOMMIT の結果を確認する必要があり、一時的なエラーが発生した場合、クライアントはトランザクションを再試行する必要があります。
COMMIT の前に、クライアントはノードIDとトランザクションID両方32ビット整数で構成されるトランザクションのグローバル識別子を取得する必要があります。
トランザクションのCOMMIT を試行中に現在のサーバーに障害が発生した場合、アプリケーションはCAMOパートナーに接続し、そのトランザクションのステータスを取得し、応答に応じて再試行する必要があります。

アプリケーションは、 COMMIT 中に切断された場合にトランザクションステータスを確認する目的でのみグローバルトランザクション識別子を保存する必要があります。特に、アプリケーションは別の永続レイヤーを必要としません。アプリケーションに障害が発生した場合、データベースの情報のみを再起動します。

CAMOパートナーの接続ステータス#

ファンクションbdr.is_camo_partner_connected を使用すると、ペアモードで構成されたCAMOパートナーノードの接続ステータスを確認できます。現在、 Eager Replicationで使用されるCAMOに相当するものはありません。

概要#

bdr.is_camo_partner_connected()

戻り値#

CAMOパートナーが現在ローカルノード上のWAL送信プロセスに接続しているため、トランザクションデータを受信し、確認を送り返すことができるかどうかを示すブール値。

CAMOパートナーの準備状況#

ファンクションbdr.is_camo_partner_ready を使用すると、ペアモードで構成されたCAMOパートナーノードの準備状況を確認できます。その下で、これはローカルモードへの、またはローカルモードからのスイッチをトリガーします。

概要#

bdr.is_camo_partner_ready()

戻り値#

CAMOパートナーがタイムリーに、つまりTO ASYNC のtimeout の有効期限が切れる前に、ローカルノードから発生したトランザクションを確認することが合理的に期待できるかどうかを示すブール値。

注釈

このファンクションは、過去または現在の状態を照会します。正の戻り値は、 CAMOパートナーが将来のトランザクションを確認できるかどうかを示しません。

CAMOパートナーを取得する#

この機能は、ローカルノードのCAMOパートナーペアモードで構成を表示します。

bdr.get_configured_camo_partner()

CAMOパートナーからの適用キューの消費を待機します#

ファンクションbdr.wait_for_camo_partner_queue は、 CAMOパートナーノードを照会することがデフォルトのbdr.wait_for_apply_queue のラッパーです。ローカルノードがCAMOペアの一部でない場合、エラーを返します。

概要#

bdr.wait_for_camo_partner_queue()

CAMOノード間のトランザクションステータス#

この機能により、 CAMOトランザクションが完全に解決されるまでの待機が有効になります。

bdr.camo_transactions_resolved()

トランザクション状態照会機能#

ノードに障害が発生したときにコミットされていたトランザクションのステータスを確認するには、アプリケーションはこのファンクションを使用する必要があります。

bdr.logical_transaction_status(node_id OID, xid OID,
                               require_camo_partner boolean)

ペアモードでCAMOを使用する場合、 CAMOペアの一部であるノードでのみこの機能を使用します。 Eager Replicationと併せて、すべてのノードで使用できます。

どちらの場合も、コミットが発行されてから15分以内にファンクションを呼び出す必要があります。 CAMOパートナーはこのようなメタ情報を定期的にパージする必要があるため、古いトランザクションに正しい回答を提供できません。

トランザクションのステータスを照会する前に、このファンクションは、受信キューが消費され完全に適用されるまで待機します。このメカニズムは、受信されたがまだ適用されていないトランザクションの早期の否定的な回答を防ぎます。

その名前にもかかわらず、それは常に読み取り専用操作であるわけではありません。ステータスが不明な場合、 CAMOパートナーはトランザクションをコミットするか中止するかを決定し、その決定をローカルに保存して、今後の一貫性を保証します。

クライアントは、オリジンでコミットする前にこのファンクションを呼び出してはなりません。そうしないと、トランザクションが強制的にロールバックされる可能性があります。

概要#

bdr.logical_transaction_status(node_id OID, xid OID,
                               require_camo_partner boolean DEFAULT true)

パラメーター#

node_id —トランザクションが発生するPGDノードのノードID。通常はクライアントがPQパラメーターbdr.local_node_id からCOMMIT の前に取得します。
xid —オリジンノードのトランザクションID。通常はクライアントがPQパラメーター transaction_id からCOMMIT の前に取得します。
require_camo_partner —デフォルトでtrueで、構成チェックが有効になります。これらのチェックを無効にし、 CAMOトランザクションではないトランザクションのステータスを照会するには、falseに設定します。

戻り値#

ファンクションは、次のいずれかの結果を返します。

'committed'::TEXT —トランザクションはコミットされ、 CAMOペアの両方のノードで可視され、最終的に他のすべてのPGDノードにレプリケートされます。クライアントが再試行する必要はありません。
'aborted'::TEXT —トランザクションは中止され、他のPGDノードにレプリケートされません。クライアントは再試行するか、トランザクションのコミットの失敗をエスカレートする必要があります。
'in progress'::TEXT —トランザクションはこのローカルノードでまだ進行中であり、まだコミットまたは中止されていません。トランザクションはCOMMITフェーズにあり、 CAMOパートナーがコミットを確認または拒否するのを待機している可能性があります。推奨されるクライアントの反応は、元のノードから切断し、 CAMOパートナーに再接続して、代わりにそれを照会することです。間にロードバランサーまたはプロキシがあり、クライアントがどのノードを照会するかを制御できない場合、クライアントはステータスが'committed' または'aborted' に切り替わるまで、繰り返しポーリングのみできます。

Eager All-Node Replicationの場合、ピアノードは、まだコミットまたは中止されていないトランザクションに対してこの結果を生成します。この場合、まだレプリケートされていないトランザクション、またはオリジンノードで開始されていないトランザクションでも、ピアPGDノードでin progress 結果を生成する場合があります。ただし、クライアントは、オリジンでコミットする前にトランザクションステータスを照会してはなりません。

'unknown'::TEXT —指定されたトランザクションは、将来であるか、その特定のノードにまだレプリケートされていない、または過去すぎるため不明です。このようなトランザクションのステータスはまだ知られていない、または不明です。この戻り値は、クライアントによる不適切な使用の兆候です。

クライアントは、エラーが発生した場合にファンクション呼び出しを再試行する準備をする必要があります。

接続プールとプロキシ#

CAMOクラスターをデザインするときは、接続プールとプロキシの効果を考慮してください。プロキシは、コミットグループ内のすべてのノード、つまりCAMOペアの両方のノード、またはEager All-Node Replicationの場合はすべてのPGDノードにトランザクションを自由に分散することができます。

アプリケーションが適切なノードIDを取得するように注意してください。セッションプーリングを使用する場合、クライアントは同じノードに接続されたままであるため、ノードIDはクライアントセッションの有効期間を通じて一定のままです。ただし、より詳細なトランザクションプーリングでは、クライアントはすべてのトランザクションのノードIDを取得する必要があります次の例のように。

PGDノードに直接接続されていないクライアントは、フェールオーバーまたはスイッチオーバーに気付かない場合があります。ただし、 bdr.local_node_id パラメーターを使用して、現在接続しているノードを判断することができます。 COMMIT中の切断という重要な状況では、プロキシはその切断をエラーとしてCAMOプロトコルを適用するクライアントに適切に転送する必要があります。

received モードのCAMOの場合、 CAMOペア間を切り替える可能性のあるプロキシは、 bdr.wait_for_camo_partner_queue ファンクションを使用して、古い読み取りを防ぐ必要があります。

例#

この例は、 CAMO対応クライアントアプリケーションの再試行ループがCのような擬似コードでどのように見えるかを示しています。接続情報を提供する2つのDSN origin_dsn およびpartner_dsn を想定しています。これらは通常、bdr.create_node への最初の呼び出しに使用されるDSNと同じであり、 bdr.node_summary 、interface_connstr 列でルックアップできます。

PGconn *conn = PQconnectdb(origin_dsn);

loop {
    // start a transaction
    PQexec(conn, "BEGIN");

    // apply transactional changes
    PQexec(conn, "INSERT INTO ...");
    ...

    // store a globally unique transaction identifier
    node_id = PQparameterStatus(conn, "bdr.local_node_id");
    xid = PQparameterStatus(conn, "transaction_id");

    // attempt to commit
    PQexec(conn, "COMMIT");
    if (PQresultStatus(res) == PGRES_COMMAND_OK)
        return SUCCESS;
    else if (PQstatus(res) == CONNECTION_BAD)
    {
        // Re-connect to the partner
        conn = PQconnectdb(partner_dsn);
        // Check if successfully reconnected
        if (!connectionEstablished())
            panic();

        // Check the attempted transactions status
        sql = "SELECT bdr.logical_transaction_status($node_id, $xid)";
        txn_status = PQexec(conn, sql);
        if (txn_status == "committed")
            return SUCCESS;
        else
            continue;   // to retry the transaction on the partner
    }
    else
    {
        // The connection is intact, but the transaction failed for some
        // other reason.  Differentiate between permanent and temporary
        // errors.
        if (isPermanentError())
            return FAILURE;
        else
        {
            // Determine an appropriate delay to back-off to account for
            // temporary failures due to congestion, so as to decrease
            // the overall load put on the servers.
            sleep(increasing_retry_delay);

            continue;
        }
    }
}

この例は、再試行やエラー処理を含む、接続のための適切なロジックで拡張する必要があります。 PgBouncerのようなロードバランサーを使用している場合、PQreset を使用して再接続を実装できます。ロードバランサーがクライアントをCAMOパートナーにのみリダイレクトし、他のPGDノードではないことを確認します。

実際には、再試行の上限を設定することをお勧めします。トランザクションで実行されるアクションによっては、他の一時的なエラーが発生する可能性があります。これらは、SERIALIZABLE 分離モードでのデッドロックまたはシリアル化障害のベストプラクティスと同様に、エラーコードに応じてトランザクションを再試行することにより処理する必要があります。

DDLおよびグローバルロックとの相互作用#

CAMOによって保護されたトランザクションには、 DDL操作を含めることができます。ただし、 DDLはグローバルロックを使用します。これは既にノード間である程度の同期を提供しています。詳細については、

DDLロックの詳細を参照してください。

CAMOとDDLを組み合わせると、レイテンシーが長くなり、グローバルデッドロックの可能性が高くなります。したがって、比較的低いbdr.global_lock_timeout を使用することをお勧めします。これはDDLを中止し、適切な時間でデッドロックを解決します。

非トランザクションDDL#

次のDDL操作はトランザクションブロックでは許可されていないため、 CAMO保護の恩恵を受けることはできません。これらの場合、 CAMOは内部で自動的に無効になります。

すべての同時インデックス操作 CREATE 、DROP 、およびREINDEX
REINDEX DATABASE 、REINDEX SCHEMA 、およびREINDEX SYSTEM
VACUUM
パラメーターなしのCLUSTER
ALTER TABLE DETACH PARTITION CONCURRENTLY
ALTER TYPE [enum] ADD VALUE
ALTER SYSTEM
CREATE およびDROP DATABASE
CREATE およびDROP TABLESPACE
ALTER DATABASE [db] TABLESPACE

CAMOの制限#

CAMOの制限については、 PGD limitations ページでカバーされています。

パフォーマンスへの影響#

CAMOは、コミット時にメッセージのラウンドトリップを追加することにより、Postgresレプリケーションプロトコルを拡張します。アプリケーションのコミットレイテンシーは非同期レプリケーションの場合よりも高く、これは主に、関係するノード間の往復時間によって決まります。同時セッションの数を増やすと、並列処理が増加して、合理的なトランザクションスループットを取得できます。

トランザクションを確認するCAMOパートナーは、トランザクションの状態を保存する必要があります。非CAMOオペレーションと比較して、これは、オリジンから適用される各トランザクションの追加シークが必要になる場合があります。

クライアントアプリケーションのテスト#

クライアント側でCAMOを適切に使用することは簡単ではありません。ノードのクラッシュやネットワークの停止などの障害シナリオに対して、PGDクラスターでアプリケーションの動作をテストすることを強くお勧めします。

Commit At Most Once

目次

Commit At Most Once#

要件#

構成#

障害シナリオ#

レシーバー側のデータの永続性#

非同期モード#

例#

非同期モードの場合#

非同期モードなし#

アプリケーションの使用#

概要と要件#

CAMOパートナーの接続ステータス#

概要#

戻り値#

CAMOパートナーの準備状況#

概要#

戻り値#

CAMOパートナーを取得する#

CAMOパートナーからの適用キューの消費を待機します#

概要#

CAMOノード間のトランザクションステータス#

トランザクション状態照会機能#

概要#

パラメーター#

戻り値#

接続プールとプロキシ#

例#

DDLおよびグローバルロックとの相互作用#

非トランザクションDDL#

CAMOの制限#

パフォーマンスへの影響#

クライアントアプリケーションのテスト#