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

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

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

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

内容

この記事は予想以上に掲載されたため、コードには多くのリンクがあり、主に私たちが話しているコンテキストのコードへのリンクがあります。
さらに、すぐに結果にジャンプするために、せっかちな人を含む目次を同封します。

• 挑戦する
• グーグルソリューション
  
  • 悪い決定と受け入れられない決定
• 統合およびアセンブリソリューション
  
  • マスターとスレーブの代わりにプライマリとスタンバイ
  • スプリットブレインとクラスター内の新しいリーダーの選出
  • Pgpool-II- 泳ぐ 接続のプール
• 結果
• 使用されるドキュメントと資料

挑戦する

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

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

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

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

• 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 クラスター）の例が気に入った

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

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

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

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

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

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

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

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

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

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

ここでの私のタスクは、モードに応じて、作品に含まれるユニバーサル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のクラスターを開始する方法を細かく指示します。 すべてのことに加えて、これに取り組みたいと思っている人のために、私は仮想の援助の手を貸す準備ができています。

• GitHubのソースとドキュメント
• サンプルのクラスター対応PostgresqlのDockerイメージ
• ENV変数を介した構成を持つPgpoolのDockerイメージ

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

• Postgresでのストリーミングレプリケーション
• Repmgr
• Pgpool2
• クベルネテス

PS：

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