クリスマスの2日目に、ObjectRocketから次のようなものが提供されました。2つの高可用性PostgresSQLレプリカ

元々は2019年12月12日にObjectRocket.com/blogで公開されました

ホリデーシーズンが近づいており、今シーズンはRackspace ObjectRocketの歴史における重要なマイルストーンの1周年を迎えます。2019年のホリデーシーズンにちょうど間に合うように、高可用性を導入しました。 （HA）ObjectRocketPostgreSQL®サービス。 ObjectRocketで提供するすべてのデータストアは本番ワークロード用に構築されており、すべてのクライアントにHAが必要です。

HAが重要な理由

HAという用語の場合 なじみがないので、HAが重要である理由を簡単に確認しましょう。何よりもまず、HAの3つの主な利点は次のとおりです。

• ダウンタイムをゼロまたは大幅に削減
• データ損失からの保護
• データベースのパフォーマンスの向上

データストア全体にHAを実装する方法はいくつかあり、利用可能なテクノロジーもいくつかあります。ただし、ほとんどすべてのHAソリューションの重要なコンポーネントはデータレプリカです。これは、1つのデータセットまたはデータベースのみが表示されることを意味しますが、舞台裏では、そのデータの1つ以上の正確な複製（コピー）があります。メインデータベースの場合、プライマリ 、ほとんどのレプリケーションスキームでは、ハードウェア障害、ソフトウェア障害、破損などの問題が発生し、レプリカがマスターを置き換える可能性があります。最後のポイントは、ほとんどのHAシステムの2番目の主要コンポーネントである自動フェイルオーバーメカニズム（他のスキームでは昇格または選択）に触れています。レプリケーションにより、データの複数の利用可能な健全なコピーが保証されます。ただし、次の準備も必要です。

1. プライマリで予期しない問題を検出します。
2. プライマリにプロモートする適切なレプリカを選択します。
3. 障害が発生したプライマリを修復し、新しいレプリカを作成します（プロモートしたレプリカを置き換えるため）。

最後のコンポーネントは、2番目のコンポーネントと組み合わされることもあり、リクエストを適切なノードにルーティングするためのデバイスです。データを書き込むためにアプリケーションをプライマリにポイントし（ベストプラクティス）、そのプライマリが失敗した場合、アプリケーションは新しくプロモートされたプライマリをポイントしません。繰り返しになりますが、これを解決するにはさまざまな方法がありますが、最も一般的なのはプロキシまたはロードバランサーを使用することです。アプリケーションをプロキシまたはロードバランサーにポイントすると、アプリケーションをデータベースに直接ポイントせずにトラフィックを送信する適切な場所が決定されます。サーバー。

すべてを結び付けるために、フェイルオーバーが発生すると、自動フェイルオーバーシステムとプロキシ/ロードバランサーが連携して機能します。新しいマスターをプロモートすると、プロキシまたはロードバランサーがトラフィックを新しいマスターに転送します。アプリケーションに変更はなく、プロモーション中の応答が途切れる可能性があることを除けば、アプリケーションはプロモーションが発生したことを知る必要さえありません。これは、基本的なコンポーネントをカバーするプロセスの概要です。それでは、ソリューションのこれらの各コンポーネントに使用しているテクノロジーについて詳しく見ていきましょう。

使用するテクノロジー

主要なコンポーネントを確認したので、前述の各コンポーネントをどのように提供しているかを詳しく見ていきましょう。

レプリケーション

Postgresは多くのレプリケーションスキームをネイティブにサポートしています。現在、1つまたは2つのレプリカを構成できますが、将来的にオプションを拡張する予定です。レプリケーションのもう1つの優れた点は、同期の概念です。 および非同期 レプリケーション。同期レプリケーションでは、プライマリは各レプリカが書き込みが終了したことを確認するのを待ってから、プライマリが書き込みが完了したと見なします。非同期では、プライマリはレプリカへの書き込みを起動しますが、アプリケーションまたはクライアントの書き込みを確認する前に、レプリカの完了を確認しません。私たちが使用するソリューションにより、非同期レプリケーションと同期レプリケーションの両方をサポートできます。デフォルトでは、同期レプリケーションを有効にし、環境でレプリケーションを構成して、プライマリの先行書き込みログ（WAL）と少なくとも1つのレプリカに書き込みが書き込まれたことを確認します。トランザクションまたはセッションごとに設定を変更できます。

フェイルオーバーとプロモーション

フェイルオーバーおよびプロモーション機能を提供するオープンソースおよびサードパーティのツールがいくつかありますが、 Patroniを選択しました。 次の優れた特性のため：

• ネイティブKubernetes®サポート： 新しいプラットフォームはKubernetesに基づいているため、別の状態やコンセンサスメカニズムを必要とせずに、Kubernetesにプラグインするだけのツールを採用できます。このオプションが重要です。
• 活発な開発とコミュニティ： Patroniの周りのコミュニティは非常に活発であり、機能が成長するにつれて、私たち自身の追加機能を共同で作成し、貢献することができます。さらに、会議の講演やドキュメントから、 Zalando のオペレーターの例まで、豊富なリソースがあります。 、テクノロジーの学習に役立てるため。
• シンプルなアーキテクチャ： 他の利用可能なツールの多くは、負荷分散とプライマリプロモーションを処理するために、Postgresインスタンスの外部に専用のリソースを必要とします。 PatroniはPostgresをラップアラウンドし、ネイティブのKubernetesコンポーネントを使用して他の機能を処理するため、HAに追加のリソースを割り当てませんでした。

マイレージは異なる場合がありますが、Patroniは、構成と環境への適合性を維持するのに非常に簡単であることがわかりました。基本的に、ノードがどのHAグループに属しているかをPatroniに伝え、残りはそれが行います。レプリケーションを構成し、失敗したプライマリを検出し、レプリカをプロモートし、新しいレプリカを作成し、プロセスの最後の部分でKubernetesと連携します。

リクエストルーティング

最後に、PatroniとネイティブのKubernetesコンストラクト（サービス） 、パズルの最後のピースを表します。 Kubernetesのサービスは、コンテナのグループ（ポッド）のラベルに基づいてトラフィックをルーティングするプロキシのように動作します。パトロニはアクティブプライマリにマスターのラベルを付けます ラベルを付けます。Kubernetesは、マスターラベルが付いたポッドにのみデータベーストラフィックをルーティングします。これは高レベルの説明ですが、実際にはそのように機能します。このプロセスを拡張して、データベースの読み取り要求をレプリカにルーティングするセカンダリポートを提供することもできます（プライマリの負荷を軽減するため）。

これは、導入されているテクノロジーの概要ですが、詳細をお聞きになりたい場合はお知らせください。私たちはお客様とお店で話すのが大好きです。

今すぐお試しください！

インスタンスの作成 ミッションコントロールの画面 ステップ2の下にインスタンスのカスタマイズというセクションがあります 。そこで、ボックスをクリックして矢印を緑色に変えることができます。これにより、PostgreSQLインスタンスのHAレプリカが追加されます。右上の省略記号（…）をクリックして、レプリカの数（1つまたは2つ）を選択することもできます。

デフォルトでは、2つのレプリカをお勧めします。これにより、停止中でも冗長性がありますが、1つを選択できます。

コメントや質問をするには、[フィードバック]タブを使用します。 セールスチャットをクリックすることもできます 今すぐチャットして会話を始めましょう。