Patroni の失敗談または PostgreSQL クラスターをクラッシュさせる方法。 アレクセイ・レソフスキー

Patroni の主な目標は、PostgreSQL に高可用性を提供することです。 しかし、Patroni は単なるテンプレートであり、既製のツールではありません (一般に、ドキュメントにそう記載されています)。 テスト ラボで Patroni をセットアップすると、これがいかに優れたツールであるか、そしてクラスターを破壊する試みをいかに簡単に処理できるかが一目でわかります。 ただし、実際には、運用環境では、すべてがテスト ラボのように美しくエレガントに行われるとは限りません。

私自身について少しお話します。 私はシステム管理者としてスタートしました。 Web開発で働いていました。 私は 2014 年から Data Egret で働いています。 同社はPostgres分野のコンサルティングを行っている。 そして、私たちはまさに Postgres を提供しており、毎日 Postgres を使用して作業しているため、操作に関連するさまざまな専門知識を持っています。

そして2018年末から少しずつパトローニを使い始めました。 そしてある程度の経験も蓄積されてきました。 私たちは何らかの方法でそれを診断し、調整し、ベストプラクティスに到達しました。 このレポートではそれらについてお話します。

Postgres は別として、私は Linux が大好きです。 私はそこをつついて探索するのが好きで、コアを集めるのが好きです。 私は仮想化、コンテナ、Docker、Kubernetes が大好きです。 管理者の古い習慣が影響しているため、これらすべてに興味があります。 私はモニタリングを扱うのが好きです。 そして、私はレプリケーションやバックアップなど、管理に関連する postgres のものが大好きです。 暇なときは Go で書いています。 私はソフトウェア エンジニアではありません。Go で自分のために書いているだけです。 そしてそれは私に喜びを与えます。

• Postgres にはそのままでは HA (高可用性) が備わっていないことをご存知の方も多いと思います。 HA を取得するには、何かをインストールし、設定し、努力して取得する必要があります。
• いくつかのツールがありますが、Patroni は HA を非常に優れた方法で解決するツールの XNUMX つです。 しかし、すべてをテストラボに入れて実行すると、すべてが機能することがわかり、いくつかの問題を再現でき、Patroni がそれらにどのように対応するかを確認できます。 そして、それがすべてうまく機能することがわかります。
• しかし実際には、さまざまな問題に直面しました。 そして、これらの問題についてお話します。
• 私たちがそれをどのように診断し、何を調整したか、それが役に立ったかどうかについてお話しします。

• Patroni のインストール方法については説明しません。インターネットで Google することができ、構成ファイルを参照して、すべてがどのように開始され、どのように構成されているかを理解することができます。 スキームやアーキテクチャについては、インターネットで情報を検索することで理解できます。
• 他人の経験について話すつもりはありません。 私たちが直面した問題についてのみ話します。
• また、Patroni と PostgreSQL 以外の問題については話しません。 たとえば、クラスターが崩壊したときにバランス調整に関連する問題があったとしても、私はそれについて話しません。

レポートを始める前にちょっとした免責事項があります。

私たちが遭遇したこれらすべての問題は、運用開始から最初の 6 ～ 7 ～ 8 か月の間に発生しました。 時間が経つにつれて、私たちは社内のベスト プラクティスにたどり着きました。 そして私たちの問題は消えました。 したがって、この報告書が発表されたのは約半年前で、当時はすべてが新鮮で、すべて完璧に覚えていました。

レポートを作成する過程で、私はすでに古い事後分析を行い、ログを調べました。 また、詳細の一部が忘れられたり、問題の分析中に完全に調査できなかったりする可能性があるため、ある時点で問題が十分に考慮されていない、または情報が不足しているように見える場合があります。 それでは、今しばらくお許しをいただきたいと思います。

パトローニとは何ですか？

• HAを構築するためのテンプレートです。 ドキュメントにはそう書いてあります。 私の観点からすると、これは非常に正しい説明です。 パトローニはすべての問題を解決する特効薬ではありません。つまり、それを機能させて利益をもたらすために努力する必要があります。
• これは、すべてのデータベース サービスにインストールされるエージェント サービスであり、Postgres の初期化システムの一種です。 Postgres を起動、停止、再起動、再構成し、クラスターのトポロジを変更します。
• したがって、クラスターの状態 (見た目どおりの現在の表現) を保管するには、ある種のストレージが必要です。 この観点から、パトローニは外部システムに状態を​​保存するという道を選びました。 これは、分散構成ストレージ システムです。 Etcd、Consul、ZooKeeper、または kubernetes Etcd、つまりこれらのオプションのいずれかになります。
• Patroni の特徴の XNUMX つは、セットアップするだけですぐにオートファイラーを入手できることです。 比較のために Repmgr を取り上げると、そこにはファイラーが含まれています。 Repmgr を使用するとスイッチオーバーが可能ですが、オートファイラーが必要な場合は追加で設定する必要があります。 Patroni には、すぐに使えるオートファイラーがすでに備わっています。
• 他にもたくさんあります。 たとえば、構成のメンテナンス、新しいレプリカの作成、バックアップなどです。ただし、これについてはレポートの範囲を超えているため、説明しません。

そして、小さな結果としては、Patroni の主なタスクは、クラスターが動作し続け、アプリケーションがクラスター トポロジの変更に気付かないように、自動ファイルを適切かつ確実に実行することです。

しかし、Patroni を使い始めると、システムはもう少し複雑になります。 以前に Postgres があった場合、Patroni を使用すると、Patroni 自体が取得され、状態が保存される DCS が取得されます。 そしてそれはすべて何らかの方法で機能する必要があります。 では、何が問題になるのでしょうか?

壊れる可能性があります:

• Postgres が壊れる可能性があります。 マスターまたはレプリカのいずれかが失敗する可能性があります。
• パトローニ自体が壊れる可能性があります。
• 状態が保存されている DCS が壊れる可能性があります。
• そしてネットワークが壊れる可能性もあります。

これらすべての点をレポートで検討します。

事件に多くの要素が含まれているという観点からではなく、事件がより複雑になるにつれて事件を検討していきます。 そして、主観的な感覚の観点から、このケースは私にとっては難しく、分解するのが困難でした...そしてその逆もあり、いくつかのケースは軽くて分解するのが簡単でした。

そして最初のケースが最も簡単です。 これは、データベース クラスターを取得し、同じクラスター上に DCS ストレージを展開した場合に当てはまります。 これは最も一般的な間違いです。 これは、アーキテクチャを構築する際の間違い、つまり、異なるコンポーネントを XNUMX か所に組み合わせる際の間違いです。

それで、ファイラーがいたので、何が起こったのか対処しましょう。

ここで、ファイラーがいつ発生したかに興味があります。 つまり、クラスターの状態が変化したこの瞬間に興味があります。

ただし、ファイラーは常に即時であるとは限りません。つまり、単位時間はかかりませんが、遅延する可能性があります。 それは長続きする可能性があります。

したがって、開始時間と終了時間がある、つまり連続イベントです。 そして、すべてのイベントを XNUMX つの間隔に分割します。ファイラーの前、ファイラー中、ファイラーの後に時間があります。 つまり、すべてのイベントをこのタイムラインで考慮します。

そして、まず、ファイラーが発生したときに、何が起こったのか、ファイラーに至った原因は何だったのかを探します。

丸太を見てみると、古典的なパトローニの丸太になります。 彼はその中で、サーバーがマスターになり、マスターの役割がこのノードに移ったことを伝えています。 ここではそれが強調表示されています。

次に、ファイラーが発生した理由、つまり、マスターの役割をあるノードから別のノードに移動させる原因となったどのようなイベントが発生したかを理解する必要があります。 そしてこの場合、すべてがシンプルです。 ストレージ システムとの通信中にエラーが発生しました。 マスターは、DCS では動作できない、つまり相互作用に何らかの問題があることに気づきました。 そして、もう師匠にはなれない、と言って辞める。 この「降格した自分」というセリフはまさにそれを物語っている。

ファイラーに先立つイベントを見ると、ウィザードの続行にとって問題となったまさにその理由がそこにあることがわかります。

Patroni ログを見ると、多数のエラーやタイムアウトがあることがわかります。つまり、Patroni エージェントが DCS と連携できません。 この場合、これは Consul エージェントであり、ポート 8500 で通信しています。

ここでの問題は、Patroni とデータベースが同じホスト上で実行されていることです。 そして、Consul サーバーは同じノード上で起動されました。 サーバーに負荷をかけることで、Consul サーバーにも問題が発生しました。 彼らは適切にコミュニケーションをとることができませんでした。

しばらくして負荷が軽減されると、パトローニは再びエージェントと通信できるようになりました。 通常の作業が再開されました。 そして、同じ Pgdb-2 サーバーが再びマスターになりました。 つまり、小さな反転があり、そのためにノードがマスターの権限を放棄し、その後再びそれらを引き継ぎました。つまり、すべてが元の状態に戻りました。

そして、これは誤報と見なすこともできるし、パトローニがすべて正しいことをしたと見なすこともできる。 つまり、クラスターの状態を維持できないことに気づき、権限を削除しました。

そしてここで、Consul サーバーがベースと同じハードウェア上にあるという事実により問題が発生しました。 したがって、ディスクやプロセッサの負荷を問わず、Consul クラスタとの対話にも影響を及ぼします。

そして、一緒に住むべきではないと判断し、Consul 用に別のクラスターを割り当てました。 そして、Patroni はすでに別の Consul と連携していました。つまり、別の Postgres クラスター、別の Consul クラスターがありました。 これは、これらすべてのものを一緒に住まわせないように運ぶ方法と保管方法に関する基本的な説明です。

オプションとして、ttl、loop_wait、retry_timeout パラメータを変更することができます。つまり、これらのパラメータを増やすことで、短期間の負荷ピークを乗り切ることができます。 ただし、この負荷には時間がかかる可能性があるため、これは最適なオプションではありません。 そして、これらのパラメータの制限を単純に超えていきます。 そして、それは実際には役に立たないかもしれません。

ご理解のとおり、最初の問題は単純です。 DCSをベースと一緒に取り付けたところ、問題が発生しました。

XNUMX 番目の問題は最初の問題と似ています。 DCS システムとの相互運用性の問題が再び発生するという点でも同様です。

ログを見ると、再び通信エラーが発生していることがわかります。 そして、Patroni は、DCS と対話できないため、現在のマスターがレプリカ モードになると言いました。

古いマスターはレプリカとなり、ここではパトローニが当然のように機能します。 pg_rewind を実行してトランザクション ログを巻き戻し、新しいマスターに接続して新しいマスターに追いつきます。 ここでパトローニは当然のように仕事をする。

ここで、ファイラーの前の場所、つまりファイラーの原因となったエラーを見つける必要があります。 この点で、Patroni ログは非常に使いやすいです。 彼は一定の間隔で同じメッセージを書きます。 これらのログをすばやくスクロールし始めると、ログが変更されたことがわかります。これは、何らかの問題が始まっていることを意味します。 私たちはすぐにこの場所に戻り、何が起こるかを見てみましょう。

通常の状況では、ログは次のようになります。 ロックの所有者がチェックされます。 そして、たとえば所有者が変わった場合、パトローニが対応しなければならないいくつかのイベントが発生する可能性があります。 しかし、この場合は大丈夫です。 エラーが発生した場所を探しています。

エラーが表示され始めた位置までスクロールすると、自動ファイルオーバーが行われたことがわかります。 そして、私たちのエラーは DCS とのやり取りに関連しており、私たちの場合は Consul を使用したため、そこで何が起こったのか Consul のログも調べます。

ファイラーの時刻と Consul ログの時刻を大まかに比較すると、Consul クラスタ内の隣人が Consul クラスタの他のメンバーの存在を疑い始めていることがわかります。

また、他の Consul エージェントのログも確認すると、そこで何らかのネットワーク崩壊が発生していることがわかります。 そして執政クラスタのメンバー全員が互いの存在を疑う。 そしてこれがファイラーにとっての原動力となった。

これらのエラーの前に何が起こったかを見ると、締め切り、RPC の失敗など、あらゆる種類のエラーがあることがわかります。つまり、Consul クラスターのメンバー間の相互作用に明らかに何らかの問題があります。 。

最も簡単な答えは、ネットワークを修復することです。 しかし、表彰台に立っている私にとって、これを言うのは簡単です。 しかし、状況によっては、顧客がネットワークを修復する余裕があるとは限りません。 彼は DC に住んでいて、ネットワークを修復できず、機器に影響を与える可能性があります。 したがって、他のオプションも必要になります。

オプションがあります:

• 私の意見では、ドキュメントにも書かれている最も単純なオプションは、Consul チェックを無効にする、つまり、単純に空の配列を渡すことです。 そして私たちは領事代理人に小切手を使わないように伝えます。 これらのチェックを行うことで、ネットワーク ストームを無視し、ファイラーを開始する必要がなくなります。
• 別のオプションは、raft_multiplier を再確認することです。 これは Consul サーバー自体のパラメータです。 デフォルトでは、5 に設定されています。この値は、ステージング環境のドキュメントで推奨されています。 実際、これは Consul ネットワークのメンバー間のメッセージングの頻度に影響します。 実際、このパラメータは、Consul クラスタのメンバー間のサービス通信の速度に影響します。 また、運用環境では、ノードがより頻繁にメッセージを交換できるように、この値を減らすことがすでに推奨されています。
• 私たちが思いついたもう XNUMX つのオプションは、オペレーティング システムのプロセス スケジューラの他のプロセスの中で Consul プロセスの優先順位を高めることです。 このような「便利な」パラメータがあります。これは、スケジューリング時に OS スケジューラによって考慮されるプロセスの優先順位を決定するだけです。 また、Consul エージェントの Nice Value も削減しました。 優先順位を上げて、オペレーティング システムが Consul プロセスにコードを実行して作業するための時間をより多く与えるようにしました。 私たちの場合、これで問題は解決しました。
• Consul を使用しないという選択肢もあります。 私には etcd の大ファンである友人がいます。 そして私たちは定期的に彼と Etcd と Consul のどちらが優れているか議論します。 しかし、どちらが優れているかという点では、通常、Consul にはデータベースを備えた各ノードで実行されるエージェントがあるという点で彼の意見に同意します。 つまり、Patroni と Consul クラスターとのやり取りは、このエージェントを介して行われます。 そして、このエージェントがボトルネックになります。 エージェントに何かが発生すると、Patroni は Consul クラスターを操作できなくなります。 そしてこれが問題なのです。 etcd プランにはエージェントはありません。 Patroni は Etcd サーバーのリストを直接操作でき、すでにそれらのサーバーと通信しています。 この点で、社内で Etcd を使用している場合は、おそらく Consul よりも Etcd の方が良い選択となるでしょう。 しかし、私たち顧客は、クライアントが何を選択して使用するかによって常に制限されます。 そして、ほとんどすべてのクライアントに対して領事が対応します。
• そして最後のポイントはパラメータ値の見直しです。 短期的なネットワークの問題が短くなり、これらのパラメータの範囲を超えないことを期待して、これらのパラメータを上げることができます。 こうすることで、ネットワークに問題が発生した場合に Patroni が自動ファイル化する攻撃性を軽減できます。

Patroni を使用している人の多くはこのコマンドに精通していると思います。

このコマンドは、クラスターの現在の状態を表示します。 そして、一見すると、この写真は普通のように見えるかもしれません。 マスターとレプリカがあり、レプリケーションの遅延はありません。 ただし、このクラスターには XNUMX つではなく XNUMX つのノードが必要であることがわかるまでは、この状況はまったく正常です。

したがって、自動ファイルがありました。 そして、この自動ファイルの後、レプリカは消えてしまいました。 私たちは彼女が失踪した理由を突き止め、彼女を連れ戻し、復元する必要があります。 そして再びログにアクセスして、自動ファイルオーバーが行われた理由を確認します。

この場合、XNUMX 番目のレプリカがマスターになりました。 ここは大丈夫です。

そして、落ちた、クラスター内にないレプリカを確認する必要があります。 Patroni ログを開くと、pg_rewind ステージでクラスターに接続するプロセス中に問題が発生したことがわかります。 クラスターに接続するには、トランザクション ログを巻き戻し、マスターから必要なトランザクション ログを要求し、それを使用してマスターに追いつく必要があります。

この場合、トランザクション ログがないため、レプリカを起動できません。 したがって、Postgres はエラーで停止します。 したがって、クラスターには含まれていません。

なぜクラスターに存在しないのか、そしてなぜログが存在しなかったのかを理解する必要があります。 私たちは新しいマスターのところに行き、彼のログに何が残っているかを調べます。 pg_rewind を実行するとチェックポイントが発生したことがわかりました。 また、古いトランザクション ログの一部は単に名前が変更されただけです。 古いマスターが新しいマスターに接続してこれらのログをクエリしようとしたとき、ログはすでに名前が変更されており、単に存在していませんでした。

これらのイベントが発生したときのタイムスタンプを比較しました。 そして、その差は文字通り 150 ミリ秒です。つまり、チェックポイントは 369 ミリ秒で完了し、WAL セグメントの名前が変更されました。 そして文字通り、517 ミリ秒後の 150 年に、古いレプリカで巻き戻しが開始されました。 つまり、文字通り 150 ミリ秒あればレプリカが接続して受信するのに十分でした。

オプションは何ですか？

最初はレプリケーション スロットを使用しました。 私たちはそれが良いと思いました。 ただし、運用の最初の段階ではスロットをオフにしました。 スロットに多くの WAL セグメントが蓄積されれば、マスターを削除できるように思えました。 彼は倒れるだろう。 スロットが無くてしばらく苦しみました。 そして、スロットが必要であることに気づき、スロットを返却しました。

しかし、ここで問題が発生します。マスターがレプリカに移動すると、スロットが削除され、スロットとともに WAL セグメントも削除されるということです。 そして、この問題を解決するために、wal_keep_segments パラメーターを増やすことにしました。 デフォルトは 8 セグメントです。 それを 1 に増やして、どれだけの空き領域があるかを調べました。 そして、wal_keep_segments に 000 ギガバイトを寄付しました。 つまり、切り替え時には、すべてのノードで常に 16 GB のトランザクション ログが確保されます。

さらに、長期的なメンテナンス作業にも依然として関連しています。 レプリカの XNUMX つを更新する必要があるとします。 そしてそれをオフにしたいと考えています。 ソフトウェア、おそらくオペレーティング システム、その他何かを更新する必要があります。 また、レプリカをオフにすると、そのレプリカのスロットも削除されます。 また、小さい wal_keep_segments を使用すると、レプリカが長期間存在しないと、トランザクション ログが失われます。 レプリカを作成し、停止したトランザクション ログを要求しますが、それらはマスター上にない可能性があります。 また、レプリカも接続できなくなります。 そのため雑誌も大量に在庫しております。

弊社には生産拠点がございます。 すでに進行中のプロジェクトもあります。

ファイラーがありました。 私たちは中に入って調べました。すべてが順調で、レプリカが適切に配置されており、レプリケーションの遅延はありません。 ログにもエラーはなく、すべて順調です。

製品チームは、何らかのデータがあるはずだと言いますが、私たちはそれを XNUMX つのソースから確認していますが、データベースには表示されていません。 そして私たちは彼らに何が起こったのかを理解する必要があります。

pg_rewind がそれらを見逃していたことは明らかです。 私たちはこれをすぐに理解しましたが、何が起こっているのかを見に行きました。

ログでは、ファイラーがいつ発生したか、誰がマスターになったかを常に見つけることができ、誰が古いマスターであったか、いつレプリカになりたかったかを判断できます。つまり、これらのログは、トランザクション ログの量を調べるために必要です。失われました。

私たちの古いマスターが再起動しました。 そしてパトローニはオートランに登録されました。 パトローニを発売。 その後、Postgres を開始しました。 より正確には、Postgres を開始する前、およびレプリカにする前に、Patroni は pg_rewind プロセスを起動しました。 そこで、取引ログの一部を消去し、新たにダウンロードして接続した。 ここでパトローニは、つまり予想通り、賢明に働きました。 クラスターが復元されました。 ファイラー 3 ノードの後、3 つのノードがありました - すべてがクールです。

一部のデータが失われてしまいました。 そして私たちはどれだけの損失を被ったのかを理解する必要があります。 私たちは巻き戻された瞬間を探しています。 それはそのような日記のエントリーで見つけることができます。 巻き戻しが開始され、そこで何かを行って終了しました。

古いマスターが中断したトランザクション ログ内の位置を見つける必要があります。 この場合はこれが目印です。 そして、XNUMX 番目のマーク、つまり古いマスターと新しいマスターの違いの距離が必要です。

通常の pg_wal_lsn_diff を使用して、これら 17 つのマークを比較します。 この場合、17 メガバイトが得られます。 多かれ少なかれ、誰もが自分で決めます。 なぜなら、ある人にとって XNUMX メガバイトは大したことではありませんが、ある人にとっては多すぎて受け入れられないからです。 ここでは、各個人がビジネスのニーズに応じて自分で決定します。

しかし、私たちは自分自身で何を見つけたのでしょうか？

まず、システムの再起動後に常に Patroni を自動起動する必要があるかどうかを自分自身で決定する必要があります。 私たちが老師のところに行って、彼がどこまで進んだかを確認しなければならないことがよくあります。 おそらく、トランザクション ログのセグメントを調べて、そこに何があるかを確認してください。 そして、このデータを失う可能性があるのか​​、それともこのデータを取り出すために古いマスターをスタンドアロン モードで実行する必要があるのか​​を理解する必要があります。

その後初めて、このデータを破棄できるか、復元してこのノードをレプリカとしてクラスターに接続できるかを判断する必要があります。

さらに、「maximum_lag_on_failover」パラメーターがあります。 私の記憶によれば、デフォルトでは、このパラメータの値は 1 MB です。

彼はどのように働いていますか? レプリカのレプリケーション ラグでデータが 1 MB 遅れている場合、このレプリカは選択に参加しません。 そして、突然ファイルオーバーが発生した場合、Patroni はどのレプリカが遅れているかを調べます。 大量のトランザクション ログが遅れている場合、マスターになることはできません。 これは、大量のデータの損失を防ぐ非常に優れたセキュリティ機能です。

しかし、Patroni クラスタと DCS のレプリケーションラグが一定の間隔で更新されるという問題があります。 30秒がデフォルトのttl値だと思います。

したがって、DCS のレプリカに対して XNUMX つのレプリケーション ラグがある状況が存在する可能性がありますが、実際にはまったく異なるラグがあるか、まったくラグがない可能性があります。つまり、これはリアルタイムではありません。 そして、それは必ずしも現実の姿を反映しているとは限りません。 そして、それに対して派手なロジックを実行する価値はありません。

そして損失のリスクは常に残ります。 そして、最悪の場合には XNUMX つの式が、平均的な場合には別の式が使用されます。 つまり、Patroni の実装を計画し、どれだけのデータが失われる可能性があるかを評価する場合、これらの公式に依存して、どれだけのデータが失われる可能性があるかを大まかに想像する必要があります。

そして良いニュースがあります。 古いマスターが先に進んでいる場合、いくつかのバックグラウンド プロセスにより、古いマスターは先に進むことができます。 つまり、ある種の自動バキュームがあり、彼はデータを書き込み、トランザクション ログに保存しました。 そして、このデータは簡単に無視され、失われる可能性があります。 これで問題ありません。

これは、maximum_lag_on_failover が設定されており、ファイラーが発生し、新しいマスターを選択する必要がある場合のログがどのように見えるかです。 レプリカは自分自身を選挙に参加できないと判断します。 そして彼女はリーダー争いへの参加を拒否する。 そして、新しいマスターが選択されるのを待って、それに接続できるようにします。 これはデータ損失に対する追加の対策です。

ここに、自社の製品に Postgres で問題があると書いた製品チームがいます。 同時に、マスター自体には SSH 経由で利用できないため、アクセスできません。 また、自動ファイルも発生しません。

このホストは強制的に再起動されました。 今理解したように、手動で自動ファイルを実行することは可能でしたが、再起動により自動ファイルが発生しました。 再起動後は、現在のマスターでの内容がすでに表示されています。

同時に、ディスクに問題があることは事前にわかっていました。つまり、どこを掘って何を探すべきかを監視していたことから、すでにわかっていました。

私たちは postgres ログにアクセスし、そこで何が起こっているのかを確認し始めました。 そこでは XNUMX 秒、XNUMX 秒、XNUMX 秒間持続するコミットが確認されましたが、これはまったく正常ではありません。 自動バキュームの起動が非常に遅く、奇妙なことに気づきました。 そして、ディスク上に一時ファイルが存在することがわかりました。 つまり、これらはすべてディスクの問題を示しています。

システムの dmesg (カーネル ログ) を調べました。 そして、ディスクの 8 つに問題があることがわかりました。 ディスク サブシステムはソフトウェア RAID でした。 /proc/mdstat を確認したところ、XNUMX つのドライブが不足していることがわかりました。 つまり、XNUMX つのディスクの Raid があり、XNUMX つが不足しています。 スライドを注意深く見ると、出力には sde がないことがわかります。 私たちでは、条件付きで言えば、ディスクが脱落しました。 これによりディスクの問題が発生し、アプリケーションでも Postgres クラスターを操作するときに問題が発生しました。

そしてこの場合、Patroni にはサーバーの状態やディスクの状態を監視するタスクがないため、Patroni は何の役にも立ちません。 そして、そのような状況を外部監視によって監視する必要があります。 私たちはすぐにディスク監視を外部監視に追加しました。

そして、そのような考えがありました - フェンシングまたはウォッチドッグソフトウェアが私たちを助けてくれるだろうか？ 問題が発生している間、Patroni は DCS クラスターとの対話を続け、問題を検出しなかったため、このケースでは彼が私たちを助けることはほとんどないだろうと私たちは考えていました。 つまり、DCS と Patroni の観点からは、クラスターにはすべて問題がありませんでしたが、実際にはディスクに問題があり、データベースの可用性に問題がありました。

私の意見では、これは私が非常に長い間研究してきた中で最も奇妙な問題の XNUMX つであり、多くのログを読み、再選択してこれをクラスター シミュレーターと呼びました。

問題は、古いマスターが通常のレプリカになれないことでした。つまり、Patroni がそれを開始し、Patroni はこのノードがレプリカとして存在することを示しましたが、同時に通常のレプリカではありませんでした。 今ならその理由がわかります。 これは私がその問題の分析から得たものです。

そして、それはどのように始まったのでしょうか? 前の問題と同様に、それはディスク ブレーキから始まりました。 コミットは XNUMX 秒、XNUMX 秒ありました。

接続が切断されました。つまり、クライアントが切断されました。

さまざまな程度の閉塞が発生しました。

したがって、ディスク サブシステムの応答性はあまり高くありません。

そして私にとって最も不思議だったのは、届いた即時シャットダウン要求です。 Postgres には XNUMX つのシャットダウン モードがあります。

• すべてのクライアントが自動的に切断するのを待つのは優雅です。
• シャットダウンするため、クライアントを強制的に切断すると、高速になります。
• そして即時。 この場合、immediate はクライアントにシャットダウンするように指示することさえせず、警告なしにシャットダウンするだけです。 そして、すべてのクライアントに対して、オペレーティング システムはすでに RST メッセージ (接続が中断され、クライアントがキャッチできるものがないことを示す TCP メッセージ) を送信しています。

誰がこの信号を送ったのでしょうか? Postgres のバックグラウンド プロセスは、そのようなシグナルを相互に送信しません。つまり、これは kill-9 です。 これらは相互にそのようなものを送信するのではなく、そのようなものにのみ反応します。つまり、これは Postgres の緊急再起動です。 誰が送ったのか、分かりません。

「最後の」コマンドを見ると、同じようにこのサーバーにログインしている人が 9 人いましたが、恥ずかしくて質問することができませんでした。 おそらくキル-9だったでしょう。 ログには kill -9 が表示されます。 Postgres では kill -XNUMX かかったと言っていますが、ログには表示されませんでした。

さらに見てみると、Patroni が 54 秒というかなり長い時間ログに書き込んでいないことがわかりました。 54 つのタイムスタンプを比較すると、約 XNUMX 秒間メッセージがありませんでした。

そしてこの間にオートファイルがありました。 パトローニはここでも素晴らしい仕事をしてくれました。 私たちの古い主人は不在で、彼に何かが起こりました。 そして新たなマスターの選出が始まった。 ここではすべてがうまくいきました。 私たちの pgsql01 が新しいリーダーになりました。

マスターになったレプリカがあります。 そして、10番目の応答があります。 そして、XNUMX 番目のレプリカにも問題がありました。 彼女は再構成しようとしました。 私の理解では、彼女はrecovery.confを変更し、Postgresを再起動して新しいマスターに接続しようとしました。 彼女は XNUMX 秒ごとに、挑戦しているが成功していないというメッセージを書きます。

これらの試行中に、即時シャットダウン信号が古いマスターに到着します。 マスターが再起動されます。 また、古いマスターが再起動するため、リカバリも停止します。 つまり、レプリカはシャットダウン モードであるため、レプリカに接続できません。

ある時点では機能しましたが、レプリケーションが開始されませんでした。

私の唯一の推測は、recovery.conf に古いマスター アドレスがあったということです。 そして、新しいマスターが出現しても、XNUMX 番目のレプリカは依然として古いマスターへの接続を試みました。

Patroni が XNUMX 番目のレプリカで起動すると、ノードは起動しましたが、複製できませんでした。 そして、次のようなレプリケーションラグが形成されました。 つまり、XNUMX つのノードはすべて所定の位置にありましたが、XNUMX 番目のノードが遅れていました。

同時に、書き込まれたログを見ると、トランザクション ログが異なるためにレプリケーションを開始できなかったことがわかります。 そして、マスターが提供するトランザクション ログ (recovery.conf で指定されているもの) は、現在のノードにまったく適合しません。

そしてここで私は間違いを犯しました。 間違ったマスターに接続しているという仮説を検証するには、recovery.conf の内容を確認する必要がありました。 しかし、私はこれに対処しているだけで、そのことを思いつかなかった、またはレプリカが遅れていて補充する必要があることに気づきました。つまり、どういうわけか不注意に作業しました。 ここが私のジョイントでした。

30 分後、管理者はすでに来ていました。つまり、レプリカで Patroni を再起動しました。 もうやめてしまったので、補充する必要があると思いました。 そして私は思った - パトローニを再起動して、もしかしたら何か良いことが起こるかもしれない。 回復が始まりました。 そして基地も開設され、接続を受け入れる準備が整いました。

レプリケーションが開始されました。 しかし、その XNUMX 分後、トランザクション ログが自分に適していないというエラーが表示され、彼女は落ちてしまいました。

また再開しようと思いました。 Patroni を再度再起動しました。Postgres を再起動したのではなく、魔法のようにデータベースが起動することを期待して Patroni を再起動しました。

レプリケーションが再び開始されましたが、トランザクション ログ内のマークは異なっており、前回の開始試行と同じではありませんでした。 レプリケーションが再び停止しました。 そして、メッセージはすでに少し異なっていました。 そして、それは私にとってあまり有益ではありませんでした。

そして、次のことが頭に浮かびました。Postgres を再起動したら、この時点で現在のマスターにチェックポイントを作成して、トランザクション ログ内のポイントを少し前に移動して、別の瞬間から回復が開始されるとしたらどうなるでしょうか? さらに、WALの在庫もまだありました。

Patroni を再起動し、マスターでいくつかのチェックポイントを実行し、レプリカが開いたときにいくつかの再起動ポイントを実行しました。 そしてそれは役に立ちました。 なぜそれが役立つのか、そしてそれがどのように機能するのかを長い間考えました。 そしてレプリカが起動しました。 そしてレプリケーションは壊れなくなりました。

私にとって、このような問題は最も謎に満ちた問題の一つであり、そこで実際に何が起こったのか、未だに困惑しています。

ここでの影響は何でしょうか? Patroni は意図したとおりにエラーなく動作します。 しかし同時に、これですべてがうまくいくという 100% の保証はありません。 レプリカは起動する可能性がありますが、半動作状態である可能性があり、古いデータが存在するため、アプリケーションはそのようなレプリカを操作できません。

ファイラーの後は、クラスター内ですべてが正常であること、つまり、必要な数のレプリカが存在し、レプリケーションの遅延がないことを常に確認する必要があります。

これらの問題を検討していく中で、私は提案をしていきます。 それらを XNUMX つのスライドに結合してみました。 おそらく、すべてのストーリーを XNUMX つのスライドにまとめて話すだけで済むでしょう。

Patroni を使用する場合は、監視が必要です。 自動ファイルオーバーがいつ発生したかを常に知っておく必要があります。自動ファイルオーバーが発生したことを知らないと、クラスターを制御できないためです。 そしてそれは悪いことです。

各ファイラーの後は、常にクラスターを手動でチェックする必要があります。 Patroni や DCS システムを使用して、レプリカの数が常に最新であること、レプリケーションの遅延がないこと、ストリーミング レプリケーションに関連するログにエラーがないことを確認する必要があります。

自動化は正常に機能し、Patroni は非常に優れたツールです。 これは機能しますが、クラスターを望ましい状態にすることはできません。 そして、それを知らなければ、私たちは困ってしまいます。

そしてパトローニは特効薬ではない。 Postgres がどのように機能するか、レプリケーションがどのように機能するか、Patroni が Postgres とどのように連携するか、ノード間の通信がどのように提供されるかを理解する必要があります。 これは、手の問題を解決するために必要です。

診断の問題にどのようにアプローチすればよいでしょうか? たまたま、私たちはさまざまなクライアントを使用しており、誰も ELK スタックを持っていないため、6 つのコンソールと 2 つのタブを開いてログを整理する必要がありました。 一方のタブでは各ノードの Patroni ログが表示され、もう一方のタブでは Consul ログが表示され、必要に応じて Postgres のログが表示されます。 これを診断するのは非常に困難です。

私はどのようなアプローチをとってきたのでしょうか? まず、ファイラーが到着したときにいつも見ます。 そして私にとって、これは分水嶺です。 私は申告者の前、申告中、申告後に何が起こったのかを見ていきます。 ファイルオーバーには XNUMX つのマークがあります。これは開始時間と終了時間です。

次に、ファイラーより前のイベントのログを調べます。つまり、ファイラーが発生した理由を探します。

そして、これにより、そのような状況が起こらないように（そしてその結果、ファイラーが存在しなくなる）、何が起こったのか、そして将来何ができるのかを理解するための全体像が得られます。

そして私たちは普段どこを見ているのでしょうか？ 私はこう見ています：

• まずはパトローニのログへ。
• 次に、Patroni ログで見つかった内容に応じて、Postgres ログまたは DCS ログを調べます。
• また、システム ログから、ファイラーの原因がわかることもあります。

パトローニについてどう思いますか？ パトローニとはとても良い関係を築いています。 私の意見では、これが今日の最高のものです。 他にもたくさんの製品を知っています。 これらは、Stolon、Repmgr、Pg_auto_failover、PAF です。 4つのツール。 全部試してみました。 パトローニが一番好きです。

「パトローニをお勧めしますか？」と聞かれたら。 私はパトローニが好きなので、そう答えます。 そしてそれを料理する方法を学んだように思います。

私が述べた問題以外に Patroni にどのような問題があるのか​​知りたい場合は、いつでもこのページをチェックしてください。 問題 GitHub 上で。 そこではさまざまな物語があり、多くの興味深い問題が議論されています。 その結果、いくつかのバグが導入され、解決されました。つまり、これは興味深い読み物です。

人々が足を撃って自殺したという興味深い話がいくつかあります。 とても有益です。 あなたはこれを読んで、そうする必要がないことを理解しています。 私は自分自身をカチカチ言いました。

そして、このプロジェクトを開発してくれた Zalando 、つまり Alexander Kukushkin と Alexey Klyukin に多大な感謝を申し上げたいと思います。 Aleksey Klyukin は共著者の XNUMX 人で、現在は Zalando で働いていませんが、この製品に取り組み始めたのは XNUMX 人です。

そしてパトローニはとてもクールなものだと思います。 彼女が存在するのは嬉しいし、彼女にとっては興味深いことだ。 そして、Patroni にパッチを書いてくださったすべての貢献者に深く感謝します。 パトローニが年齢を重ねるごとに、より成熟し、クールで効率的になることを願っています。 すでに機能していますが、さらに改良されることを期待しています。 したがって、Patroni を使用する予定がある場合は、心配する必要はありません。 これは優れたソリューションであり、実装して使用できます。

それで全部です。 質問がある場合は、質問してください。

質問

ご報告ありがとうございます！ ファイラーの後でも注意深く確認する必要がある場合、なぜ自動ファイラーが必要なのでしょうか?

新しいものだから。 私たちは彼女と一緒にXNUMX年しか経っていません。 安全な方が良いです。 私たちは実際に現場に入って、すべてが本当にうまくいくかどうかを確認したいと考えています。 これは大人の不信感のレベルです。再確認して確認したほうがよいでしょう。

例えば、朝行って見ましたよね？

朝ではなく、通常はほぼすぐに自動ファイルについて学びます。 通知を受け取ると、自動ファイルが発生したことがわかります。 私たちはすぐに見に行きます。 ただし、これらのチェックはすべて監視レベルに引き上げる必要があります。 REST API経由でPatroniにアクセスすると履歴が残ります。 履歴によって、ファイラーが発生したときのタイムスタンプを確認できます。 これに基づいて監視を行うことができます。 履歴、イベントの数を確認できます。 さらにイベントがある場合は、自動ファイルが発生しています。 行って見ることができます。 または、監視自動化により、すべてのレプリカが適切に配置されており、遅延がなく、すべてが正常であることが確認されました。

ありがとうございます！

素晴らしいお話をありがとうございました！ DCS クラスターを Postgres クラスターから遠く離れた場所に移動した場合、このクラスターも定期的にサービスを受ける必要がありますか? DCS クラスターの一部をオフにする必要がある、またはそれらに対して何かを行う必要があるなどのベスト プラクティスは何ですか? この構造全体はどのようにして存続するのでしょうか? そして、これらのことはどうやって行うのでしょうか？

ある企業では、コンポーネントの XNUMX つまたは複数が故障した場合に何が起こるかという問題のマトリックスを作成する必要がありました。 このマトリックスに従って、すべてのコンポーネントを順番に検討し、これらのコンポーネントに障害が発生した場合のシナリオを構築します。 したがって、障害シナリオごとに、回復のためのアクション プランを立てることができます。 DCS の場合、それは標準インフラストラクチャの一部として提供されます。 そして管理者がそれを管理しており、私たちはすでにそれを管理する管理者と、事故が発生した場合にそれを修正する管理者の能力に依存しています。 DCS がまったくない場合は、それを導入しますが、同時に、インフラストラクチャの責任を負わないため、特に監視はしませんが、何を監視する方法と推奨事項を提供します。

つまり、ホストで何かを行う前に、Patroni を無効にし、ファイラーを無効にし、すべてを無効にする必要があることを正しく理解しましたか?

それは、DCS クラスター内のノードの数によって異なります。 多数のノードがあり、そのうちの XNUMX つのノード (レプリカ) だけを無効にすると、クラスターはクォーラムを維持します。 そしてパトローニは引き続き営業を続けている。 そして何も誘発されません。 より多くのノードに影響を与える複雑な操作があり、それが存在しないとクォーラムが破壊される可能性がある場合は、Patroni を一時停止するのが合理的かもしれません。 これには、対応するコマンド (patronictl 一時停止、patronictl 再開) があります。 ただ一時停止するだけですが、その時点ではオートファイラーは機能しません。 DCS クラスターのメンテナンスを行った後、一時停止を解除して稼働を継続します。

どうもありがとうございました！

ご報告いただきまして誠にありがとうございます！ 製品チームはデータの損失についてどう感じていますか?

製品チームは気にしていませんが、チームリーダーは心配しています。

どのような保証がありますか?

保証は非常に難しいです。 Alexander Kukushkin は、「RPO と RTO の計算方法」、つまり回復時間と失われる可能性のあるデータの量に関するレポートを作成しています。 これらのスライドを見つけて研究する必要があると思います。 私が覚えている限り、これらを計算する方法については具体的な手順があります。 どれだけのトランザクションが失われる可能性があるか、どれだけのデータが失われる可能性があるか。 オプションとして、Patroni レベルで同期レプリケーションを使用できますが、これは両刃の剣です。データの信頼性を確保できるか、速度が低下するかのどちらかです。 同期レプリケーションもありますが、これもデータ損失に対する 100% の保護を保証するものではありません。

アレクセイ、素晴らしいレポートをありがとう！ ゼロレベルの保護に Patroni を使用した経験はありますか? つまり、同期スタンバイと併用するということでしょうか。 これが最初の質問です。 そしてXNUMXつ目の質問。 さまざまなソリューションを使用しました。 私たちは Repmgr を使用しましたが、オートファイラーは使用しませんでしたが、現在はオートファイラーを含めることを計画しています。 そして、代替ソリューションとして Patroni を検討します。 Repmgrと比較した利点は何だと思いますか?

最初の質問は同期レプリカに関するものでした。 誰もが怖がっているので、ここでは誰も同期レプリケーションを使用しません（いくつかのクライアントはすでに同期レプリケーションを使用していますが、原則としてパフォーマンスの問題に気づいていません - 講演者のメモ）。 ただし、同期レプリケーション クラスターには少なくとも XNUMX つのノードが必要であるというルールを独自に開発しました。これは、XNUMX つのノードがあり、マスターまたはレプリカに障害が発生した場合、Patroni がこのノードをスタンドアロン モードに切り替えて、アプリケーションが継続して動作するようにするためです。仕事。 この場合、データが失われる危険性があります。

XNUMX 番目の質問に関しては、歴史的な理由から、私たちは Repmgr を使用しており、一部のクライアントでは現在も使用しています。 何が言えるでしょうか？ Patroni にはすぐに使えるオートファイラーが付属しており、Repmgr には有効にする必要がある追加機能としてオートファイラーが付属しています。 各ノードで Repmgr デーモンを実行する必要があります。その後、オートファイラーを構成できます。

Repmgr は、Postgres ノードが生きているかどうかを確認します。 Repmgr プロセスは相互に存在を確認しますが、これはあまり効率的なアプローチではありません。 ネットワーク分離の複雑なケースでは、大規模な Repmgr クラスターがいくつかの小さなクラスターに分解されても動作を続ける可能性があります。 私は長い間 Repmgr をフォローしていませんでした。修正されたかもしれません...あるいは修正されていないかもしれません。 しかし、Stolon 氏や Patroni 氏が行っているように、DCS 内のクラスターの状態に関する情報を削除することが最も現実的な選択肢です。

アレクセイ、質問があるのですが、もしかしたらもっとつまらない質問かもしれません。 最初の例の XNUMX つでは、DCS をローカル マシンからリモート ホストに移動しました。 私たちは、ネットワークが独自の特性を持ち、それ自体で生きているものであることを理解しています。 また、何らかの理由で DCS クラスターが使用できなくなった場合はどうなるのでしょうか? 理由は言いませんが、ネットワーカーの邪悪な手によるものから実際の問題まで、たくさんの理由が考えられます。

大きな声では言いませんでしたが、クォーラムを満たすためには、DCS クラスターもフェイルオーバーする必要があります。つまり、奇数のノードでなければなりません。 DCS クラスターが使用できなくなったり、クォーラムが満たされなくなったりした場合 (つまり、何らかのネットワークの分割やノードの障害など) はどうなりますか? この場合、Patroni クラスターは読み取り専用モードになります。 Patroni クラスターはクラスターの状態と何をすべきかを判断できません。 DCS に接続して新しいクラスター状態をそこに保存することはできないため、クラスター全体が読み取り専用になります。 そして、オペレーターによる手動介入または DCS が回復するまで待ちます。

ざっくり言うと、DCS は私たちにとって基地そのものと同じくらい重要なサービスになるのでしょうか？

はいはい。 非常に多くの現代企業において、Service Discovery はインフラストラクチャの不可欠な部分です。 インフラストラクチャにデータベースが存在する前から実装されています。 相対的に言えば、インフラストラクチャが立ち上げられ、DC にデプロイされ、すぐに Service Discovery が利用できるようになりました。 Consul であれば、その上に DNS を構築できます。 これが Etcd の場合、Kubernetes クラスターの一部が存在する可能性があり、そこに他のすべてがデプロイされます。 Service Discovery はすでに現代のインフラストラクチャに不可欠な部分になっているように思えます。 そして、彼らはデータベースについて考えるよりもはるかに早い段階でそれについて考えます。

ありがとうございます！

出所： habr.com