記事の翻訳はコースの学生向けに特別に用意されました 「データベース」。 この方向の開発に興味がありますか? ご招待します オープンデーでは、プログラム、オンライン形式の特徴、訓練後に卒業生を待つ能力とキャリアの見通しについて詳しく話します。

PostgreSQL と接続固有の書き込み一貫性設定
Compose では多くのデータベースを扱っているため、その機能と欠点についてさらに詳しく知る機会が得られます。 新しいデータベースの機能を愛するようになると、私たちが長年使ってきたより成熟したツールに同様の機能があればどんなに素晴らしいだろうと考えることがあります。 私が PostgreSQL に期待していた新機能の XNUMX つは、クラスター全体にわたる接続ごとの構成可能な書き込み一貫性でした。 そして、結局のところ、私たちはすでにそれを持っているので、今日はそれをどのように使用できるかについての情報を共有したいと思います。

なぜ必要なのですか？

クラスターがどのように動作するかは、アプリケーションによって異なります。 たとえば、請求書支払いアプリを考えてみましょう。 クラスター全体で XNUMX% の一貫性が必要となるため、データベースがすべての変更が行われるのを待機するように同期コミットを有効にする必要があります。 ただし、アプリケーションが急速に成長しているソーシャル ネットワークの場合は、XNUMX% の一貫性よりも高速な応答を好むでしょう。 これを実現するには、クラスターで非同期コミットを使用します。

妥協点を満たす

データの一貫性とパフォーマンスの間でトレードオフを行う必要があります。 PostgreSQL は、デフォルト構成が予測可能であり、予期せぬ事態が発生しないため、一貫性から遠ざかります。 次に、妥協点を見てみましょう。

トレードオフ 1: パフォーマンス

PostgreSQL クラスターに一貫性が必要ない場合は、非同期で実行できます。 書き込みはクラスター リーダーに対して行われ、更新は数ミリ秒後にそのレプリカに送信されます。 PostgreSQL クラスターに一貫性が必要な場合は、同期して実行する必要があります。 書き込みはクラスター リーダーに対して行われ、クラスター リーダーは更新をレプリカに送信し、各レプリカが書き込んだことの確認を待ってから、書き込みを開始したクライアントに成功した旨の確認を送信します。 これらのアプローチの実質的な違いは、非同期方式では XNUMX つのネットワーク ホップが必要であるのに対し、同期方式では XNUMX つのネットワーク ホップが必要であることです。

トレードオフ 2: 一貫性

これら 1 つのアプローチでリーダーが失敗した場合の結果も異なります。 作業が非同期で実行される場合、そのようなエラーが発生した場合、すべてのレコードがレプリカによってコミットされるわけではありません。 どれくらい失われますか？ アプリケーション自体とレプリケーションの効率によって異なります。 Compose レプリケーションでは、レプリカ内の情報量がリーダーよりも 1 MB 少ない場合、レプリカがリーダーになることができなくなります。つまり、非同期操作中に最大 XNUMX MB のレコードが失われる可能性があります。

これは同期モードでは発生しません。 リーダーで障害が発生すると、リーダーで確認された書き込みはレプリカでも確認される必要があるため、すべてのレプリカが更新されます。 これが一貫性です。

同期動作は、一貫性とパフォーマンスのトレードオフにおいて一貫性が明らかに有利な課金アプリケーションでは理にかなっています。 このようなアプリケーションにとって最も重要なのは、有効なデータです。 次に、リクエストにできるだけ早く応答してユーザーの注意を引き続けることが主なタスクであるソーシャル ネットワークについて考えてみましょう。 この場合、ネットワーク ホップが少なく、コミットの待ち時間が少ないパフォーマンスが優先されます。 ただし、考慮する必要があるのはパフォーマンスと一貫性の間のトレードオフだけではありません。

トレードオフ 3: クラッシュ

障害時にクラスターがどのように動作するかを理解することは非常に重要です。 XNUMX つ以上のレプリカに障害が発生した状況を考えてみましょう。 コミットが非同期で処理される場合、リーダーはレプリカが失われるのを待たずに機能し続けます。つまり、書き込みを受け入れて処理します。 レプリカがクラスターに戻ると、リーダーに追いつきます。 同期レプリケーションでは、レプリカが応答しない場合、リーダーには選択の余地がなく、レプリカがクラスターに戻り、書き込みを受け入れてコミットできるようになるまでコミット確認を待ち続けます。

トランザクションごとに XNUMX つの接続ですか?

すべてのアプリケーションには、一貫性とパフォーマンスの異なるタイプの組み合わせが必要です。 もちろん、それが完全に一貫性があると私たちが想像している料金支払いアプリや、ほとんど一時的なソーシャル ネットワーキング アプリの場合は別です。 他のすべての場合では、一部の操作は同期的でなければならず、一部の操作は非同期的でなければならない場合があります。 チャットに送信されたメッセージがコミットされるまでシステムを待機させたくない場合もありますが、同じアプリケーションで支払いが処理される場合は待機する必要があります。

もちろん、これらすべての決定はアプリケーション開発者によって行われます。 各アプローチをいつ使用するかについて適切な決定を下すことは、クラスターを最大限に活用するのに役立ちます。 開発者が接続とトランザクションの SQL レベルでそれらを切り替えることができることが重要です。

実際にコントロールを確保する

デフォルトでは、PostgreSQL は一貫性を提供します。 これはサーバーパラメータによって制御されます synchronous_commit。 デフォルトではこの位置にあります onですが、他にも XNUMX つのオプションがあります。 local, remote_write または off.

パラメータを設定する場合 off ローカル システム上であっても、すべての同期コミットが停止されます。 local パラメーターはローカル システムの同期モードを指定しますが、レプリカへの書き込みは非同期で実行されます。 Remote_write さらに詳しく言えば、レプリカへの書き込みは非同期で行われますが、レプリカが書き込みを受け入れてもディスクに書き込んでいない場合には、書き込みが返されます。

利用可能な選択肢の範囲を考慮して行動を選択します。 on – これらは同期録音です。選択します。 local ローカルのコミットは同期したままにして、ネットワーク経由で非同期コミットを実行します。

さて、これを設定する方法をすぐに説明しますが、次のように設定したと想像してください。 synchronous_commit в local サーバー用。 パラメータを変更できないか考えました synchronous_commit そして、それが可能であるだけでなく、これを行う方法が XNUMX つあることが判明しました。 XNUMX つ目は、接続のセッションを次のように設定することです。

SET SESSION synchronous_commit TO ON;  
// Your writes go here

セッション内での後続の書き込みはすべて、接続されたクライアントに肯定的な結果を返す前に、レプリカへの書き込みを確認します。 もちろん設定を変更しない限り synchronous_commit また。 一部を省略することもできます SESSION デフォルト値になるため、コマンドに含めます。

XNUMX 番目の方法は、単一トランザクションの同期レプリケーションを確実に取得したい場合に適しています。 多くの NoSQL 世代のデータベースにはトランザクションの概念が存在しませんが、PostgreSQL にはトランザクションの概念が存在します。 この場合、トランザクションを開始してから設定します。 synchronous_commit в on トランザクションのエントリを実行する前。 COMMIT 任意のパラメータ値を使用してトランザクションをコミットします synchronous_commitただし、他の開発者が書き込みが非同期ではないことを理解できるように、変数を事前に設定することが最善です。

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

データベースが接続されたクライアントに肯定的な応答を返す前に、すべてのトランザクションのコミットがレプリカに書き込まれたことが確認されるようになります。

PostgreSQL の構成

これまでは、次のような PostgreSQL システムを想像していました。 synchronous_commitにインストールされています local。 これをサーバー側で現実的にするには、XNUMX つのサーバー構成オプションを設定する必要があります。 もう XNUMX つのパラメータ synchronous_standby_names いつになったら本領を発揮するだろう synchronous_commit 入ります on。 どのレプリカが同期コミットに適格であるかを決定し、次のように設定します。 *これは、すべてのレプリカが関係していることを意味します。 これらの値は通常、次のように設定されます。 設定ファイル 以下を追加することで:

synchronous_commit = local  
synchronous_standby_names='*'

パラメータを設定することで synchronous_commit 意味に localでは、ローカル ディスクが同期を維持するシステムを作成しますが、ネットワーク レプリカのコミットはデフォルトで非同期になります。 もちろん、上に示したように、これらのコミットを同期することに決めた場合は別です。

開発をフォローしている場合 ガバナープロジェクト、最近の変更点に気づいたかもしれません (1, 2)、これにより、ガバナー ユーザーはこれらのパラメーターをテストし、その一貫性を監視できるようになりました。

もう少し言葉を...

ほんの XNUMX 週間前なら、PostgreSQL をこれほど細かく微調整するのは不可能だと私は言っていたでしょう。 そのとき、Compose プラットフォーム チームのメンバーである Kurt が、そのような機会が存在すると主張しました。 彼は私の反対意見をなだめ、PostgreSQL のドキュメントで次のことを見つけました。 次の:

この設定はいつでも変更できます。 トランザクションの動作は、コミット時に有効な設定によって決まります。 したがって、一部のトランザクションは同期的にコミットし、他のトランザクションは非同期的にコミットすることが可能であり、便利です。 たとえば、XNUMX つを強制するには multistatement パラメータのデフォルト値が逆の場合に非同期でコミットするトランザクションを設定します。 SET LOCAL synchronous_commit TO OFF トランザクション中。

構成ファイルに対するこの小さな変更により、ユーザーが一貫性とパフォーマンスを制御できるようになりました。

出所： habr.com