Odyssey のロードマップ: 接続プーラーに他に何を求めるか。 アンドレイ・ボロディン (2019)

Andrey Borodin 氏の講演では、接続プーラーを設計する際に PgBouncer のスケーリングの経験をどのように考慮したかについて説明します。 Odyssey、本番環境でどのように展開したか。 さらに、新しいバージョンでどのようなプーラーの機能を期待するかについても議論します。私たちにとって、ニーズをカバーするだけでなく、ユーザー コミュニティを発展させることが重要です。 オデッセイ.

ビデオ：

こんにちは、みんな！ 私の名前はアンドリューです。

Yandex では、オープンソース データベースを開発しています。 そして今日は、接続プーラー接続に関するトピックがあります。

ロシア語で接続プーラーを呼び出す方法を知っている場合は、教えてください。 技術文献に定着すべき適切な専門用語を探したいと思っています。

多くのデータベースには接続プーラーが組み込まれており、それについて知る必要さえないため、このトピックは非常に複雑です。 もちろん、一部の設定はどこにでもありますが、Postgres ではこれは機能しません。 そして並行して (HighLoad++ 2019 で)、Postgres でのクエリの設定に関する Nikolai Samokhvalov によるレポートがあります。 そして、すでにリクエストを完璧に構成している人々がここに来ており、ネットワークやリソース使用率に関連するまれなシステム問題に直面している人々であることを私は理解しています。 また、場所によっては、問題が明らかではないという意味で、非常に困難な場合もあります。

Yandex には Postgres が搭載されています。 多くの Yandex サービスは Yandex.Cloud に存在します。 また、Postgres には XNUMX 秒あたり少なくとも XNUMX 万件のリクエストを生成する数ペタバイトのデータがあります。

そして、すべてのサービスに対して非常に典型的なクラスターを提供します。これは、ノードのメインのプライマリ ノード、通常の XNUMX つのレプリカ (同期および非同期)、バックアップ、レプリカ上の読み取りリクエストのスケーリングです。

各クラスター ノードは Postgres であり、Postgres と監視システムに加えて、接続プーラーもインストールされます。 接続プーラーは、フェンシングとその主な目的に使用されます。

接続プーラーの主な目的は何ですか?

Postgres は、データベースを操作するためにプロセス モデルを採用しています。 これは、XNUMX つの接続が XNUMX つのプロセス、XNUMX つの Postgres バックエンドであることを意味します。 また、このバックエンドにはさまざまなキャッシュが多数あり、接続ごとに異なるキャッシュを作成するには非常にコストがかかります。

また、Postgres コードには procArray と呼ばれる配列があります。 ネットワーク接続に関する基本的なデータが含まれています。 また、ほぼすべての procArray 処理アルゴリズムは線形の複雑さを持っており、ネットワーク接続の配列全体を通じて実行されます。 これは非常に速いサイクルですが、受信ネットワーク接続が増えると、コストが少し高くなります。 さらに、少し高価になると、多数のネットワーク接続に対して非常に高い料金を支払うことになります。

考えられるアプローチは 3 つあります。

• アプリケーション側。
• データベース側。
• そして、その間、つまりすべての可能な組み合わせ。

残念ながら、組み込みのプーラーは現在開発中です。 PostgreSQL Professional の友人たちは主にこれを行っています。 それがいつ現れるかを予測することは困難です。 そして実際、建築家の選択には XNUMX つの解決策があります。 これらは、アプリケーション側プールとプロキシ プールです。

アプリケーション側のプールが最も簡単な方法です。 そして、ほとんどすべてのクライアント ドライバーは、コード内で数百万の接続をデータベースへの数十の接続として表現する方法を提供します。

ある時点でバックエンドを拡張し、それを多くの仮想マシンにデプロイする必要があるという事実には問題があります。

その後も、さらにいくつかのアベイラビリティ ゾーン、複数のデータ センターがあることに気付きます。 そして、クライアント側のプーリングアプローチは大きな数字につながります。 大きいものでは約 10 接続になります。 これはうまく機能するエッジです。

プロキシ プーラーについて話す場合、多くのことを実行できる XNUMX つのプーラーがあります。 彼らは単なる資金調達者ではありません。 これらはプーラー + より優れた機能です。 これ pgプール и カリカリプロキシ.

しかし、残念ながら、誰もがこの追加機能を必要とするわけではありません。 そして、それはプーラーがセッション プーリングのみ、つまりデータベースへの XNUMX つの受信クライアントと XNUMX つの送信クライアントのみをサポートするという事実につながります。

これは私たちのタスクにはあまり適していないため、トランザクション プーリングを実装する PgBouncer を使用します。つまり、サーバー接続はトランザクション期間中のみクライアント接続にマップされます。

そして私たちの負荷に関しては、それは本当です。 しかし、いくつか問題があります.

すべての受信接続はローカルであるため、セッションを診断するときに問題が発生します。 全員がループバックで来ており、どういうわけかセッションを追跡するのが困難になります。

もちろん、application_name_add_host を使用することもできます。 これは、IP アドレスを application_name に追加するバウンサー側の方法です。 ただし、application_name は追加の接続によって設定されます。

このグラフでは、黄色の線が実際のリクエストであり、青の線がデータベースに飛び込むリクエストです。 そして、この違いは正確には application_name の設定であり、これはトレースにのみ必要ですが、まったく無料ではありません。

さらに、Bouncer は XNUMX つのプール、つまりユーザーごと、データベースごとのデータベース接続数を制限できません。

これは何をもたらすのでしょうか? C++ で書かれたロードされたサービスと、その近くのノード上の小さなサービスがあり、ベースには何の問題もありませんが、そのドライバーがおかしくなります。 20 個の接続が開かれ、残りはすべて待機します。 コードも正しいです。

もちろん、この設定を追加する、つまりクライアントをプールに制限する、Bouncer 用の小さなパッチを作成しました。

これを Postgres 側で行うこと、つまりデータベース内のロールを接続数に制限することは可能です。

しかし、その後、サーバーに接続できない理由が理解できなくなります。 PgBouncer は接続エラーをスローせず、常に同じ情報を返します。 そして、あなたは理解できません。パスワードが変更されたのかもしれない、データベースがダウンしただけかもしれない、何かが間違っているのかもしれません。 しかし、診断はありません。 セッションを確立できない場合、なぜセッションを確立できないのかわかりません。

ある時点で、アプリケーションのグラフを見ると、アプリケーションが動作していないことがわかります。

上部を見ると、Bouncer がシングルスレッドであることがわかります。 これはサービスの人生における転換点です。 あなたは、XNUMX 年半以内にデータベースを拡張する準備をしており、プーラーを拡張する必要があることを理解しています。

私たちは、さらに多くの PgBouncer が必要であるという結論に達しました。

https://lwn.net/Articles/542629/

バウンサーにはわずかにパッチが適用されています。

そして、TCP ポートを再利用して複数のバウンサーを立ち上げることができるようにしました。 そして、オペレーティング システムはすでに、受信 TCP 接続をラウンドロビンオムによってそれらの間で自動的に転送します。

これはクライアントに対して透過的です。つまり、バウンサーが XNUMX つあるように見えますが、実行中のバウンサー間でアイドル状態の接続が断片化しています。

そしてある時点で、これら 3 人のバウンサーがそれぞれコアを 100% 食べていることに気づくかもしれません。 かなりの数の用心棒が必要です。 なぜ？

TLSがあるからです。 暗号化された接続があります。 また、TLS を使用した場合と使用しない場合で Postgres のベンチマークを行うと、TLS ハンドシェイクが CPU リソースを消費するため、暗号化を有効にすると確立された接続の数がほぼ XNUMX 桁減少することがわかります。

そして上部には、着信接続の波中に実行されるかなりの数の暗号化関数が表示されます。 プライマリはアベイラビリティ ゾーン間で切り替えることができるため、着信接続の波は非常に一般的な状況です。 つまり、何らかの理由で古いプライマリが利用できなくなり、負荷全体が別のデータ センターに送信されました。 彼らは全員同時に TLS に挨拶に来ます。

そして、大量の TLS ハンドシェイクはすでに用心棒を歓迎せず、喉を圧迫するかもしれません。 タイムアウトにより、受信接続の波が抑制されなくなる可能性があります。 指数バックオフなしでベースへの再試行がある場合、コヒーレントな波で何度も戻ってくることはありません。

以下は、16 コアを 16% でロードする 100 個の PgBouncer の例です。

カスケード PgBouncer に到着しました。 これは、Bouncer ロードで達成できる最良の構成です。 外部接続が大幅に断片化しないように、外部バウンサーは TCP ハンドシェイクに使用され、内部バウンサーは実際のプーリングに使用されます。

この構成では、ソフト再起動が可能です。 これら 18 人のバウンサーをすべて XNUMX つずつ再起動できます。 しかし、そのような構成を維持するのは非常に困難です。 システム管理者、DevOps、およびこのサーバーに実際に責任を負う人々は、このスキームにあまり満足していないでしょう。

すべての改善はオープンソースで推進できるように見えますが、Bouncer はあまり適切にサポートしていません。 たとえば、同じポートで複数の PgBouncer を実行する機能は XNUMX か月前にコミットされました。 この機能に関するプルリクエストは数年前にありました。

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

または、もう XNUMX つの例です。 Postgres では、追加の認証を行わずにシークレットを別の接続に送信することで、実行中のリクエストをキャンセルできます。 しかし、一部のクライアントは単純に TCP リセットを送信します。つまり、ネットワーク接続を切断します。 バウンサーはこれをどうするのでしょうか？ 彼は何もしません。 リクエストの実行は続行されます。 小さなリクエストで基礎を築いた膨大な数の接続を受信した場合、バウンサーから接続を切断するだけでは十分ではなく、データベース内で実行されているリクエストを完了する必要もあります。

これはパッチが適用されましたが、この問題はまだ Bouncer のアップストリームにマージされていません。

そこで私たちは、独自の接続プーラーが必要であるという結論に達しました。これは開発され、パッチが適用され、問題をすぐに修正できるようになり、もちろんマルチスレッドである必要があります。

マルチスレッドをメインタスクとして設定します。 着信 TLS 接続の波を適切に処理できる必要があります。

これを行うには、ネットワーク接続のマシン状態をシリアル コードとして記述するように設計された、Machinarium と呼ばれる別個のライブラリを開発する必要がありました。 libpq ソース コードを見ると、結果を返して「少し後で電話してください。 現時点では IO は実行されていますが、IO が経過するとプロセッサに負荷がかかります。 そして、これはマルチレベルのスキームです。 ネットワークの相互作用は通常、ステート マシンによって記述されます。 「以前にサイズ N のパケット ヘッダーを受信した場合、今度は N バイトを待機する」、「SYNC パケットを送信した場合、今度は結果メタデータを含むパケットを待機する」などの多くのルールがあります。 あたかも迷路をラインスキャンに変換したかのような、かなり困難で直感に反するコードが得られます。 ステート マシンの代わりに、プログラマが通常の命令コードの形式で主要な対話パスを記述するようにしました。 この命令型コードでは、ネットワークからのデータを待機して実行シーケンスを中断し、実行コンテキストを別のコルーチン (グリーン スレッド) に渡す必要がある場所を挿入する必要があります。 このアプローチは、迷路内で最も予想される道を連続して書き留めて、そこに分岐を追加するという事実に似ています。

その結果、TCP に TPC 接続を受け入れさせ、ラウンドロビンで多くのワーカーに TPC 接続を渡す XNUMX つのスレッドができました。

この場合、各クライアント接続は常に XNUMX つのプロセッサ上で実行されます。 これにより、キャッシュフレンドリーにすることができます。

さらに、システムの TCP スタックをオフロードするために、小さなパケットを XNUMX つの大きなパケットに収集する方法が若干改善されました。

さらに、Odyssey が設定されている場合、ネットワーク接続障害が発生した場合に CANCEL と ROLLBACK を送信できるという意味で、トランザクション プーリングも改善されました。つまり、リクエストを待っている人がいない場合、Odyssey はデータベースにリクエストを実行しないように指示します。貴重なリソースを無駄にする可能性のあるリクエスト。

そして可能な限り、同じクライアントへの接続を維持します。 これにより、application_name_add_host を再インストールする必要がなくなります。 可能であれば、診断に必要なパラメータを追加でリセットする必要はありません。

私たちは Yandex.Cloud の利益のために活動します。 また、マネージド PostgreSQL を使用していて、接続プーラーがインストールされている場合は、論理レプリケーションを使用して、外部への論理レプリケーションを作成できます。つまり、必要に応じて任せてください。 論理レプリケーションのフロー外のバウンサーは提供しません。

これは論理レプリケーションの設定例です。

さらに、外部への物理レプリケーションもサポートしています。 クラウドでは、もちろんそれは不可能です。なぜなら、その場合、クラスターがそれ自体に関する情報を過剰に提供してしまうからです。 ただし、インストール環境で、Odyssey の接続プーラーを介した物理レプリケーションが必要な場合は、それが可能です。

Odyssey は PgBouncer と完全な互換性のあるモニタリングを備えています。 ほぼすべての同じコマンドを実行する同じコンソールがあります。 何かが不足している場合は、プル リクエストを送信するか、少なくとも GitHub 上で問題を送信してください。必要なコマンドを完了します。 ただし、PgBouncer コンソールの主要な機能はすでに用意されています。

もちろん、エラー転送もあります。 ベースから報告されたエラーを返します。 あなたが基地にいないということだけでなく、なぜ基地にいないのかという情報も得られます。

PgBouncer との 100% の互換性が必要な場合、この機能は無効になっています。 万が一に備えて、用心棒のように振る舞うこともできます。

開発

Odyssey のソース コードについて少し説明します。

https://github.com/yandex/odyssey/pull/66

たとえば、「一時停止/再開」コマンドがあります。 これらは通常、データベースを更新するために使用されます。 Postgres をアップグレードする必要がある場合は、接続プーラーで Postgres を一時停止し、pg_upgrade を実行してから再開します。 そしてクライアント側から見ると、データベースの速度が低下しているように見えます。 この機能はコミュニティの人々によって提供されました。 彼女はまだ死んでいませんが、間もなくすべてが死ぬでしょう。 （すでに死んで）

https://github.com/yandex/odyssey/pull/73 - すでに死んで

さらに、PgBouncer の新機能の XNUMX つは SCRAM 認証サポートです。これも Yandex.Cloud で働いていない人によって提供されました。 どちらも複雑な機能であり、重要です。

したがって、これからコードを書きたいと思っている人のために、Odyssey が何でできているかを説明したいと思います。

オリジナルの Odyssey ベースがあり、3 つの主要なライブラリに依存しています。 Kiwi ライブラリは、Postgres メッセージ プロトコルの実装です。 つまり、Postgres のネイティブ プロト XNUMX は、フロントエンドとバックエンドが交換できる標準メッセージです。 これらは Kiwi ライブラリに実装されています。

machinarium ライブラリはスレッド実装ライブラリです。 このマシナリウムの小さな断片はアセンブラで書かれています。 ただし、心配しないでください。行数は 15 行だけです。

オデッセイの建築。 コルーチンを実行するメインマシンがあります。 このマシンは、受信 TCP 接続の受け入れとワーカー間での分散を実装します。

XNUMX つのワーカー内で、複数のクライアントのハンドラーが動作できます。 また、メインスレッドでは、コンソールと、プール内で不要になった接続を削除するクローン タスクの処理が回転しています。

Odyssey は、標準の Postgres テスト スイートを使用してテストされます。 Bouncer と Odyssey を通して install-check を実行するだけで、null div が得られます。 日付の書式設定に関連するテストがいくつかあり、Bouncer と Odyssey ではまったく同じように失敗します。

さらに、独自のテストを行っているドライバーも多数います。 そして、私たちは彼らのテストを使用して Odyssey をテストします。

また、カスケード構成のため、Odyssey がカスケード内のいずれかの部分に含まれていても期待どおりに動作することを確認するために、Postgres + Odyssey、PgBouncer + Odyssey、Odyssey + Odyssey などのさまざまなバンドルをテストする必要があります。 。

すくい

本番環境では Odyssey を使用しています。 そして、すべてがうまくいくと言ったら不公平でしょう。 いいえ、つまりはいですが、常にそうとは限りません。 たとえば、運用環境ではすべてが正常に動作していましたが、PostgreSQL Professional の友人がやって来て、メモリ リークが発生していると言いました。 それらは本当にそうでした、私たちはそれらを修正しました。 しかし、それは単純でした。

次に、接続プーラーに受信 TLS 接続と送信 TLS 接続があることがわかりました。 また、接続にはクライアント証明書とサーバー証明書が必要です。

Bouncer と Odyssey のサーバー証明書は pcache によって再読み取りされますが、スケーラブルな Odyssey は最終的にこの証明書の読み取りのシステム パフォーマンスに依存するため、クライアント証明書は pcache から再読み取りされる必要はありません。 彼はすぐには休まなかったので、これは私たちにとって驚きでした。 最初は直線的に拡大していましたが、20 件の同時接続を受信した後、この問題が顕在化しました。

Pluggable Authentication Method は、組み込みの Luunux ツールを使用して認証する機能です。 PgBouncer では、PAM からの応答を待機する別のスレッドが存在し、現在の接続を提供して PAM スレッド内で存続するように要求できるメインの PgBouncer スレッドが存在するように実装されています。

これを実装しなかった理由は XNUMX つあります。 たくさんのストリームがあります。 なぜそれが必要なのでしょうか?

その結果、PAM 認証と非 PAM 認証がある場合、PAM 認証が大規模に発生すると、非 PAM 認証が大幅に遅延する可能性があるという問題が発生する可能性があります。 それは私たちがまだ修正していない問題の XNUMX つです。 しかし、それを修正したい場合は、これを行うことができます。

もう XNUMX つの問題は、すべての受信接続を受け入れる XNUMX つのスレッドがあるという事実です。 その後、それらはワーカー プールに転送され、そこで TLS ハンドシェイクが行われます。

その結果、20 のネットワーク接続のコヒーレントな波がある場合、それらはすべて受け入れられます。 そしてクライアント側では、libpq がタイムアウトの報告を開始します。 デフォルトでは 000 秒程度です。

すべてが同時にベースに入ることができない場合、これらすべては非指数関数的な再試行でカバーできるため、ベースに入ることができません。

最終的に PgBouncer スキームをここにコピーして、受け入れる TCP 接続の数を調整しました。

接続を受け入れているものの、最終的にハンドシェイクする時間がない場合は、CPU リソースを消費しないように接続をキューに入れます。 これにより、到着したすべての接続に対して同時ハンドシェイクが実行されない可能性があります。 しかし、たとえ負荷が十分に強かったとしても、少なくとも誰かがデータベースに侵入するでしょう。

ロードマップ

オデッセイで将来どんなことを見てみたいですか？ 私たちは自分自身を成長させる準備ができていますか、そしてコミュニティに何を期待していますか?

2019年XNUMX月分。

XNUMX 月のオデッセイのロードマップは次のとおりです。

• SCRAM と PAM 認証が必要でした。
• 読み取りリクエストをスタンバイに転送したいと考えていました。
• オンライン再起動をお願いします。
• そしてサーバー上で一時停止する機能。

このロードマップの半分は私たちによって完了したものではありません。 そして、これは良いことです。 それでは、残っているものについて話し合い、さらに追加しましょう。

読み取り専用クエリのスタンバイへの転送について? リクエストに応えずにただ空気を温めるだけのレプリカがあります。 フェイルオーバーとスイッチオーバーを提供するにはそれらが必要です。 データ センターの XNUMX つで問題が発生した場合は、それらのデータ センターで役立つ作業を行いたいと考えています。 同じ中央プロセッサや同じメモリを別の方法で構成することはできません。そうしないとレプリケーションが機能しないからです。

Postgresでは原則10以降、接続時にsession_attrsを指定できるようになりました。 接続内のすべてのデータベース ホストをリストし、データベースにアクセスする理由 (書き込み専用か読み取り専用か) を示すことができます。 そしてドライバー自体は、session_attrs の要件を満たすリストの最初のホストを選択します。

しかし、このアプローチの問題は、レプリケーションの遅延を制御できないことです。 サービスが許容できない時間まで遅延している何らかのレプリカがある可能性があります。 実際、レプリカ上で読み取りリクエストをフル機能で実行するには、読み取りが不可能な場合には動作しない機能を Odyssey でサポートする必要があります。

Odyssey は、時々データベースにアクセスして、プライマリからのレプリケーション距離を問い合わせる必要があります。 また、制限に達した場合は、新しいリクエストをデータベースに入れず、接続を再開始する必要があることをクライアントに伝え、場合によってはリクエストを実行する別のホストを選択します。 これにより、データベースはレプリケーション ラグを迅速に回復し、クエリに応答するために再び戻ることができます。

オープンソースであるため、実装日を特定するのは困難です。 しかし、PgBouncer の同僚のように 2,5 年半も続かないことを願っています。 これはオデッセイに欲しい機能です。

コミュニティでは、準備されたステートメントのサポートについて質問されました。。 準備済みステートメントを XNUMX つの方法で作成できるようになりました。 まず、SQL コマンド、つまり「準備済み」を実行できます。 この SQL コマンドを理解するには、Bouncer 側の SQL を理解する方法を学ぶ必要があります。 パーサー全体が必要なので、これはやりすぎです。 すべての SQL コマンドを解析することはできません。

ただし、proto3 にはメッセージ プロトコル レベルで準備されたステートメントがあります。 そして、これは、準備されたステートメントが作成されているという情報が構造化された形式で提供される場所です。 また、サーバー接続によっては、クライアントがプリペアド ステートメントの作成を要求したという理解をサポートできます。 また、トランザクションが終了した場合でも、サーバーとクライアントの接続を維持する必要があります。

しかし、ここでダイアログに矛盾が生じます。クライアントがどのプリペアドステートメントを作成したかを理解し、このサーバー接続を作成したすべてのクライアント間でサーバー接続を共有する必要がある、つまり誰がそのようなプリペアドステートメントを作成したかを理解する必要があると誰かが言うからです。

Andres Freund 氏は、別のサーバー接続でそのようなプリペアド ステートメントをすでに作成しているクライアントがあなたのところに来た場合は、そのクライアントに代わって作成してくださいと述べました。 しかし、クライアントではなくデータベースでクエリを実行するのは少し間違っているように思えますが、データベースと対話するためのプロトコルを作成する開発者の観点からすると、単純にネットワーク接続が与えられれば便利でしょう。このような準備されたリクエストがあります。

そして実装する必要がある機能がもう XNUMX つあります。 PgBouncer と互換性のあるモニタリングができるようになりました。 平均クエリ実行時間を返すことができます。 しかし、平均時間は病院内の平均気温です。誰かが寒くて、誰かが暖かく、平均して誰もが健康です。 それは本当ではない。

パーセンタイルのサポートを実装する必要があります。これは、リソースを消費する遅いリクエストがあることを示し、監視をより受け入れやすくします。

最も重要なことは、バージョン 1.0 が必要であるということです (バージョン 1.1 はすでにリリースされています)。 実際のところ、Odyssey は現在バージョン 1.0rc、つまりリリース候補版です。 そして、私がリストしたすべての rake は、メモリ リークを除いて、同じバージョンでまったく修正されました。

バージョン 1.0 は私たちにとって何を意味しますか? オデッセイを拠点に展開しています。 すでにデータベース上で実行されていますが、1 秒あたり 000 リクエストのポイントに達すると、これがリリース バージョンであり、000 と呼べるバージョンになると言えます。

コミュニティの何人かの人が、バージョン 1.0 での一時停止と SCRAM の追加を求めています。 ただし、SCRAM も一時停止もまだマージされていないため、次のバージョンを実稼働環境にロールアウトする必要があることを意味します。 しかし、おそらく、この問題はすぐに解決されるでしょう。

プルリクエストをお待ちしています。 また、バウンサーに関してどのような問題があるのか​​も聞きたいです。 それらについて話し合いましょう。 もしかしたら、必要な機能を実装できるかもしれません。

私のほうはこれで終わりますので、よろしくお願いいたします。 ありがとう！

質問

独自の application_name を入力した場合、Odyssey のトランザクション プーリングを含めて、正しくスローされますか?

オデッセイとかバウンサーとか？

オデッセイで。 バウンサーが投げられます。

セットを作ります。

また、実際の接続が他の接続を飛び越えた場合、それは送信されますか?

リストされているすべてのパラメーターのセットを作成します。 application_name がこのリストにあるかどうかはわかりません。 そこで見かけたそうです。 すべて同じパラメータを設定します。 XNUMX 回のリクエストで、セットは起動時にクライアントによってインストールされたすべてのことを実行します。

アンドレイさん、報告してくれてありがとう！ 良い報告です！ Odyssey の開発が刻々と加速していることを嬉しく思います。 これからも同じように続けていきたいと思います。 Odyssey が同時に異なるデータベース (つまりスレーブ マスター) に接続し、フェイルオーバー後に新しいマスターに自動的に接続できるように、マルチ データ ソース接続を行うようにすでにお願いしました。

はい、その議論を思い出したようです。 現在、いくつかのストレージがあります。 ただし、それらの間の切り替えはありません。 私たちの側では、サーバーがまだ生きていることをクエリし、フェイルオーバーが発生したことを理解する必要があります。サーバーは pg_recovery を呼び出します。 私たちはマスターのところに来ていないことを理解する標準的な方法を持っています。 そして、私たちは間違いから何らかの方法で理解する必要がありますか？ つまり、そのアイデアは興味深いものであり、議論されています。 もっとコメントを書いてください。 C言語を知っている実務家であれば、これは一般的に素晴らしいことです。

私たちは、アプリケーション開発者にとってレプリケートされたクラスターの導入をできるだけ簡単にしたいと考えているため、レプリカ間のスケーリングの問題にも関心を持っています。 しかし、ここでは、それをどのように行うか、どのようにうまく行うかという、より多くのコメントが欲しいです。

レプリカについても質問です。 マスターと複数のレプリカがあることがわかりました。 また、違いがある可能性があるため、接続のためにマスターよりもレプリカにアクセスする頻度が低いことは明らかです。 データの違いがあなたのビジネスを満足させないほどであり、それが複製されるまでそこには行かないかもしれないとあなたは言いました。 同時に、長い間そこに行かなかったが、その後通い始めた場合、必要なデータはすぐには利用できなくなります。 つまり、常にマスターにアクセスすると、キャッシュはそこでウォームアップされ、キャッシュはレプリカに少し遅れます。

はい、それは本当だ。 PCキャッシュには必要なデータブロックは存在せず、実際のキャッシュには必要なテーブルに関する情報は存在せず、プランには解析されたクエリは存在せず、まったく存在しません。

そして、ある種のクラスターがあり、そこに新しいレプリカを追加すると、クラスターの起動中にすべてが不良になります。つまり、キャッシュが増大します。

アイデアが分かりました。 正しいアプローチは、最初にレプリカに対して少数のクエリを実行し、キャッシュをウォームアップすることです。 ざっくり言うと、マスターから10秒以上遅れてはいけないという条件があります。 そして、この状態はXNUMXつの波に含まれるべきではなく、一部のクライアントにとってはスムーズに含まれるべきです。

はい、体重を増やします。

これは良いアイデアですね。 ただし、最初にこのシャットダウンを実装する必要があります。 まず電源をオフにする必要があり、次に電源をオンにする方法を考えます。 スムーズに電源を入れることができる優れた機能です。

nginxにはこのオプションがあります slowly start サーバーのクラスター内。 そして徐々に負荷を増やしていきます。

はい、素晴らしいアイデアです。思いついたら試してみます。

出所： habr.com