🆘 🚄 🥣 Kubernetesクラスター内のUnkillable Postgresqlクラスター 👩🏼‍🌾 😨 🛵

信頼と希望について考えたことがあるなら、おそらくデータベース管理システムで行ったほどの経験はなかったでしょう。まあ、本当に、それはデータベースです！名前には完全な意味が含まれます-データが保存される場所、メインタスクはSTORAGEです。そして、最も悲しいことは、いつものように、これらの信念は、「製品」上のそのような1つの死んだDBの残骸に分かれています。

そして何をすべきか？ -あなたが尋ねます。サーバーには何もデプロイしないでください、返信します。少なくとも一時的に、しかし確実かつ迅速に、それ自体を修復できるものはありません！

この記事では、チューニングの経験についてお話します。ほぼ Googleの別のフェールオーバーソリューション内の不滅のPostgresqlクラスター-Kubernetes（別名k8s）

内容

この記事は予想以上に掲載されたため、コードには多くのリンクがあり、主に私たちが話しているコンテキストのコードへのリンクがあります。

さらに、すぐに結果にジャンプするために、せっかちな人を含む目次を同封します。

挑戦する

ほとんどすべてのアプリケーションにデータストレージが必要です。また、ネットワークまたは物理サーバー上の逆境に耐えるこのストレージを持つことは、有能なアーキテクトにとって良い口調です。別の側面は、競合する大規模なサービス要求であってもサービスの高可用性です。これは、必要に応じて簡単にスケーリングできることを意味します。

解決すべき問題が発生する合計：

物理的に分散されたサービス
バランス調整
新しいノードの追加による無制限のスケーリング
通信ノードの障害、破壊、損失からの自動回復
単一障害点の欠如

著者の宗教的信念の特異性による追加のポイント：

Postgres （無料で利用可能な最も学術的で一貫性のあるRDBMSソリューション）
Dockerパッケージ
Kubernetesインフラストラクチャの説明

図では、次のようになります。

master (primary node1) --\ |- slave1 (node2) ---\ / balancer \ | |- slave2 (node3) ----|---| |----client |- slave3 (node4) ---/ \ balancer / |- slave4 (node5) --/

入力の対象：

より多くの読み取り要求（書き込みに対して）
平均から最大2倍のピークでの線形負荷増加

グーグルソリューション

ITの問題を解決する専門家である私は、集合的な考えを求めることにしました。「postgres cluster kubernetes」はごみの束、「postgres cluster Docker」はごみの束、「postgres cluster」は私たちが戦わなければならなかったいくつかの選択肢です。

気分を害したのは、正気なDockerアセンブリの欠如とクラスタリングのオプションの説明でした。 Kubernetesは言うまでもありません。ところで、Mysqlには多くのオプションはありませんでしたが、まだありました。少なくともGaleraの公式k8sリポジトリ（ Mysql クラスター）の例が気に入った

グーグルは、問題は自分で手動モードで解決しなければならないことを明らかにしました...「しかし、少なくとも散らばったヒントと記事の助けを借りて」私は息を吐きました。

悪い決定と受け入れられない決定

この段落のすべてのポイントは主観的であり、かなり均一であり、実行可能であることにすぐに注意します。しかし、私の経験と本能に頼って、それらを断つ必要がありました。

Pgpool。 なぜPgpoolは必ずしも良いとは限らないのですか？

誰かが（何らかの理由で）普遍的な解決策を作成するとき、そのようなものはかさばり、遅く、維持するのが難しいように思えます。同じことがPgpoolでも起こりました。Pgpoolはほとんどすべてを実行できます。

バランス調整
接続のパックを保存して、データベースへの接続とアクセス速度を最適化する
さまざまなレプリケーションオプション （ストリーム、スロー）のサポート
記録用のプライマリサーバーの自動検出 。これはクラスター内のロールを再編成するときに重要です。
フェールオーバー/フェールバックをサポート
マスターマスター複製
単一障害点を根絶するための複数のPgpoolノードの調整された作業。

私は最初の4つのポイントが有用であると思い、他の人の問題を理解し、検討した上でそれを決めました。

Pgpool2のリカバリでは、次のウィザードを決定するためのシステムは提供されません。すべてのロジックは、フェイルオーバー/フェイルバックコマンドで説明する必要があります
マスタマスタレプリケーションを使用した記録時間は、ノードの数に関係なく、オプションなしで2倍に短縮されます...まあ、少なくとも直線的には増加しません
カスケードクラスタの構築方法（1つのスレーブが前のスレーブから読み取る場合）-まったく明確ではありません
もちろん、Pgpoolがその兄弟について知っており、隣接ノードで問題が発生した場合にすぐにアクティブリンクになることができるのは良いことですが、Kubernetesはこの問題を解決します。これにより、一般的に、インストールされているすべてのサービスに対して同じ動作が保証されます

スロニー 象が私たちを去った方法

実際に、すでに慣れ親しんでいてすぐに使用できるStreaming Replicationの結果も読んで比較したので、Elephantsについてさえ考えないことを決めるのは簡単でした。

そして、他のすべてについて、プロジェクトのサイトの最初のページで、具体的なシステム要件がない限り、postgres 9.0+では、Slonyは必要ないと書いています。

部分複製
他のソリューションとの統合（「ロンディステとブカルド」）
追加のレプリケーション動作

一般的に、Slonyはケーキではないように思えます...少なくともこれら3つの特定のタスクを持っていなければ。

マスター-マスター複製。 すべてのレプリカが同じように役立つわけではありません。

理想的な双方向レプリケーションアプローチのオプションを検討し、検討した結果、被害者は一部のアプリケーションの寿命と互換性がないことが判明しました。速度は言うまでもなく、トランザクションと複雑なクエリ（ SELECT FOR UPDATE

など）の操作には制限があります。

私はこの問題に関してそれほど洗練されていない可能性がありますが、私が見たものはこの考えを残すのに十分でした。そして、頭を悩ますと、書き込み操作が強化されたシステムでは、リレーショナルデータベースではなく、まったく異なるテクノロジーが必要であるように思えました。

統合およびアセンブリソリューション

例では、ソリューションが基本的にどのように見えるべきか、コードではどのようになっているかについて説明します。クラスターを作成するために、原則としてKubernetes（docker-composeの例があります）やDockerを用意する必要はありません。そのとき、CPM（コピー-貼り付け-変更）ソリューションとしてではなく、スニペットをインストールするためのガイドとして、説明されているすべてのものが役立ちます。

マスターとスレーブの代わりにプライマリとスタンバイ

Postgresqlの同僚が「マスター」と「スレーブ」という用語を拒否したのはなぜですか？..うーん、間違っている可能性がありますが、骨抜きの正しさのために奴隷制度が悪いと言われています。そうですね。

最初に行うことは、プライマリサーバーをオンにし、次に最初のスタンバイレイヤーをオンにし、その後2番目のレイヤーをオンにすることです-タスクに応じたすべて。ここから、ストリーミングレプリケーションを有効にするための構成を使用して、プライマリ/スタンバイモードで通常のPostgresqlサーバーを有効にする簡単な手順を取得します。

構成ファイルで注意すべきこと

 wal_level = hot_standby max_wal_senders = 5 wal_keep_segments = 5001 hot_standby = on

コメント内のすべてのパラメーターには簡単な説明がありますが、簡単に言うと、この構成はサーバーがクラスターの一部であることをサーバーに認識させるため、他のクライアントにWALログの読み取りを許可する必要があります。さらに、リカバリ中にリクエストを許可します。この種のレプリケーションを微調整する方法の優れた説明は、 Postgresql Wikiにあります。

クラスターの最初のサーバーを受け取ったらすぐに、プライマリがどこにあるかを知っているスタンビーをオンにすることができます。

ここでの私のタスクは、モードに応じて、作品に含まれるユニバーサルDocker Imageイメージを組み立てることになりました。これは次のようなものです。

プライマリの場合：
- Repmgrを構成します（それについては少し後で）
- アプリケーションのデータベースとユーザーを作成します
- レプリケーションを監視およびサポートするデータベースとユーザーを作成します
- 構成（ postgresql.conf
  
  ）を更新し、外部（ pg_hba.conf
  
  ）からユーザーへのアクセスを開きます
- バックグラウンドでPostgresqlサービスを開始します
- Repmgrにマスターとして登録
- repmgrd
  
  起動しrepmgrd
  
  -レプリケーションを監視するためのRepmgrからのデーモン（詳細は後ほど）
スタンバイの場合：
- Repmgrを使用してプライマリサーバーを複製します（すべての構成で、 $PGDATA
  
  ディレクトリをコピーするだけです）
- Repmgrを構成します
- バックグラウンドでPostgresqlサービスを開始します-クローン作成後、サービスはスタンバイであり、プライマリに忠実に従うことを正常に認識します
- Repmgrにスレーブとして登録
- repmgrd
  
  開始しrepmgrd

シーケンスはこれらすべての操作にとって重要であるため、 sleep

コードに詰め込まれます。私は知っています-良くはありませんが、すべてのコンテナを一度に起動する必要がある場合（例えば、 docker-compose up

）にENV変数を使用して遅延を設定すると便利です

このイメージのすべての変数は、 docker-compose

ファイルで説明されています。

スタンバイサービスの第1層と第2層の完全な違いは、2番目のマスターの場合、プライマリではなく、第1層のサービスであるということです。 2番目のエシュロンは、最初のエシェロンの後に遅れて開始する必要があることを忘れないでください。

スプリットブレインとクラスター内の新しいリーダーの選出

スプリットブレイン -クラスターの異なるセグメントが新しいマスターを作成/選択し、問題が解決したと考えることができる状況。

これは1つですが、 Repmgrが解決に役立った唯一の問題からはほど遠いものです。

本質的に、これは次のことができるマネージャーです。

マスター （マスター-Repmgrの観点から）を複製し、生まれ変わったスレーブに自動的に注入します。
マスターの死でクラスターを蘇らせるのを手伝ってください。
自動モードまたは手動モードでは、Repmgrは新しいマスターを選択し、すべてのスレーブサービスを再構成して新しいリーダーに従うことができます。
クラスターからノードを削除する
クラスターの状態を監視する
クラスター内のイベントの コマンドを実行する

この場合、 repmgrd

は、コンテナ内のメインプロセスによって起動され、クラスターの整合性を監視します。マスターサーバーへのアクセスが失われた状況では、Repmgrは現在のクラスター構造を分析し、次のマスターになるユーザーを決定しようとします。当然、Repmgrは、スプリットブレイン状態を作成せず、唯一の正しいマスターを選択するのに十分なほど賢いです。

Pgpool-II- 泳ぐ接続のプール

システムの最後の部分はPgpoolです。悪い判断に関するセクションで書いたように、サービスはまだその仕事をしています：

クラスターのすべてのブライドル間で負荷を分散します
接続記述子を保存して、データベースのアクセス速度を最適化します
私たちの場合、ストリーミングレプリケーション-マスターを自動的に検出し、書き込み要求に使用します。

結果として、かなりシンプルなDocker Imageを取得しました。これは、起動時に、Pgpoolを介してmd5承認を渡すことができるノードとユーザーのセットで動作するように構成されます（これは簡単ではありません）

単一障害点を取り除くためにタスクが頻繁に発生します。この場合、このポイントはpgpoolサービスであり、すべての要求をプロキシし、データにアクセスする方法で最も弱いリンクになる可能性があります。

幸いなことに、この場合、k8sは問題を解決し、必要な数のサービスレプリケーションを作成できるようにします。

Kubernetesの例では、残念ながらそうではありませんが、 Replication ControllerやDeploymentの仕組みに精通している場合は、上記を簡単に行うことができます。

結果

この記事は、問題を解決するためのスクリプトの改定ではなく、この問題を解決するための構造の説明です。つまり、ソリューションをより深く理解して最適化するには、少なくともgithubのREADME.mdのコードを読む必要があります。このコードは、ステップバイステップで、 docker -composeおよびKubernetesのクラスターを開始する方法を細かく指示します。すべてのことに加えて、これに取り組みたいと思っている人のために、私は仮想の援助の手を貸す準備ができています。

使用するドキュメントと資料

PS：

発表された資料が有用であり、夏が始まる前に少しポジティブになることを願っています！幸運と気分、同僚;）

Kubernetesクラスター内のUnkillable Postgresqlクラスター

内容