Patroni 上で信頼性の高い PostgreSQL クラスターを構築した方法

今日、大規模な高価なプロジェクトだけでなく、いつでもどこでもサービスの高可用性が求められています。 「申し訳ありませんが、メンテナンス中です」というメッセージが表示され、一時的に利用できないサイトは依然として存在しますが、通常は見下したような笑みを浮かべます。 このクラウドでの生活にさらに加えてみましょう。追加のサーバーを起動するときは、API を XNUMX 回呼び出すだけで済み、「ハードウェア」の操作について考える必要はありません。 そして、重要なシステムがクラスター テクノロジーと冗長性を使用して確実に構築されなかった理由は、もはや弁解の余地がありません。

当社のサービスにおけるデータベースの信頼性を確保するためにどのようなソリューションを検討し、どのような結論に至ったのかについて説明します。 さらに、広範囲にわたる結論を示すデモも含まれます。

高可用性アーキテクチャのレガシー

これは、さまざまなオープンソース システムの開発のコンテキストでさらによくわかります。 従来のソリューションでは、需要の増加に応じて高可用性テクノロジを追加する必要がありました。 そしてその質も様々でした。 次世代ソリューションは、高可用性をアーキテクチャの中核に据えます。 たとえば、MongoDB はクラスタリングを主要なユースケースとして位置付けています。 クラスターは水平方向に拡張され、これがこの DBMS の強力な競争上の利点となります。

PostgreSQL に戻りましょう。 これは最も古い人気のあるオープンソース プロジェクトの 95 つで、最初のリリースは前世紀の 8.2 年に行われました。 長い間、プロジェクト チームは高可用性がシステムによって対処される必要がある問題であるとは考えていませんでした。 したがって、データのコピーを作成するレプリケーション テクノロジは 2006 年のバージョン 2010 にのみ組み込まれましたが、それはファイル ベース (ログ シッピング) でした。 9.0 年のバージョン XNUMX ではストリーミング レプリケーションが導入され、これがさまざまなクラスターを作成するための基礎となっています。 実際、これは、Enterprise SQL や最新の NoSQL の後に PostgreSQL に慣れ親しんだ人にとっては非常に驚くべきことです。コミュニティの標準ソリューションは、単純に同期または非同期レプリケーションを備えたマスターとレプリカのペアです。 同時に、在庫ではマスターの切り替えが手動で行われ、クライアントの切り替えの問題も独自に解決されることが提案されています。

信頼性の高い PostgreSQL を作成することをどのように決定したか、そしてそのために何を選択したか

しかし、継続的な注意を必要としないフォールト トレラント ソリューションの構築に役立つ膨大な数のプロジェクトやツールがなければ、PostgreSQL はこれほど普及しなかったでしょう。 クラウドの中で Mail.ru クラウド ソリューション (MCS) DBaaS の開始以来、非同期レプリケーションを備えた単一の PostgreSQL サーバーとマスターとレプリカのペアが利用可能になりました。

当然のことながら、私たちはすべての人にとって作業を楽にし、切り替えのために常に監視したり夜中に起きたりする必要がなく、高可用性サービスの基盤として機能する PostgreSQL インストールを利用できるようにしたいと考えていました。 このセグメントには、古くから実績のあるソリューションと、最新の開発を使用した新しい世代のユーティリティの両方があります。

今日、高可用性の問題は冗長性 (これは言うまでもありません) に依存しているのではなく、コンセンサス、つまりリーダー選出アルゴリズムに依存しています。 ほとんどの場合、重大な事故はサーバーの不足が原因ではなく、コンセンサスの問題が原因で発生します。つまり、新しいリーダーが選ばれていない、XNUMX 人のリーダーが異なるデータセンターに現れているなどです。 例 - Github MySQL クラスターでの事故 - 彼らはこう書きました 詳細な事後分析.

この問題の数学的根拠は非常に深刻です。 一方で、 CAP定理、これは HA ソリューションを構築する可能性に理論的な制限を課しますが、一方で、合意を決定するための数学的に証明されたアルゴリズムは次のとおりです。 パクシ и Raft。 これに基づいて、非常に人気のある DCS (分散型コンセンサス システム)、Zookeeper、etcd、Consul があります。 したがって、意思決定システムが独自に作成されたある種のアルゴリズムで動作する場合は、細心の注意を払って扱う必要があります。 膨大な数のシステムを分析した結果、主に Zalando が開発したオープンソース システムである Patroni に落ち着きました。

余談になりますが、私たちはマルチマスター ソリューション、つまり録音用に水平方向にスケーリングできるクラスターも検討したと言います。 ただし、XNUMX つの主な理由により、そのようなクラスターを作成しないことにしました。 まず、このようなソリューションは複雑さが高く、したがって脆弱性も多くなります。 すべてのケースに対して安定した解決策を講じることは困難です。 第二に、この場合、PostgreSQL は純粋 (ネイティブ) ではなくなり、一部の機能が使用できなくなり、一部のアプリケーションには動作中に隠れたバグが存在する可能性があります。

パトローニ

では、パトローニはどのように機能するのでしょうか? 開発者は車輪の再発明を行わず、実績のある DCS ソリューションの XNUMX つを基礎として使用することを提案しました。 構成の同期、リーダーと定足数の選出に関するすべての問題は彼に任されています。 このために etcd を選択しました。

次に、Patroni は、PostgreSQL のすべての設定とレプリケーション設定の正しい適用、およびスイッチオーバーとフェイルオーバー (つまり、マスターの定期的および緊急切り替え) でのコマンドの実行を処理します。 特に MCS クラウドでは、マスター、同期レプリカ、および 2 つ以上の非同期レプリカのクラスターを作成できます。 同期レプリカの存在により、少なくとも XNUMX 台のサーバー上のデータの安全性が確保され、このレプリカが主な「マスター候補」になります。

etcd は同じサーバーにデプロイされるため、最適なクォーラムを実現するには、サーバーの推奨数は 3 または 5 です。 このようなクラスターは読み取り用に水平方向にスケーリングします (書き込み用のスケーリングについては上で書きました)。 ただし、非同期レプリカは、特に高負荷時に遅延が発生する傾向があることに注意してください。

このようなリードレプリカ (ホットスタンバイ) の使用は、レポートタスクや分析タスクに正当化され、マスターサーバーの負荷を軽減します。

このようなクラスターを自分で作成したい場合は、以下が必要になります。

• 3 つ以上のサーバーを準備し、サーバー間の IP アドレス指定とファイアウォール ルールを構成します。
• etcd、Patroni、PostgreSQL サービスのパッケージをインストールします。
• etcd クラスターを構成します。
• PostgreSQL で動作するように patroni サービスを構成します。

つまり、合計で XNUMX 個の構成ファイルを正しく作成し、どこにもミスをしない必要があります。 このためには、たとえば Ansible などの構成管理ツールを必ず使用する必要があります。 ただし、可用性の高い TCP バランサーはまだありません。 作るのは別作業です。

既製のクラスターが必要だが、あれこれいじくり回したくはないという人のために、私たちは作業を簡素化するために、クラウド内の Patroni 上に既製のクラスターを作成しました。無料でテストできます。 クラスター自体に加えて、次のことを行いました。

• TCPバランサ。 異なるポートでは、常に現在のマスター、同期レプリカ、または非同期レプリカをそれぞれ指します。
• アクティブなPatroniマスターを切り替えるためのAPI。

これらには、MCS クラウド API および Web コンソール経由でアクセスできます。

Демо

MCS クラウドで PostgreSQL クラスターの機能をテストするために、DBMS に問題が発生した場合にライブ アプリケーションがどのように動作するかを見てみましょう。

以下は、人為的なイベントをログに記録し、それを画面に報告するアプリケーションのコードです。 エラーが発生した場合、これが報告され、Ctrl + C の組み合わせで停止するまでループで作業が続行されます。

from __future__ import print_function

from datetime import datetime
from random import randint
from time import sleep
import psycopg2


def main():
    try:
        connection = psycopg2.connect(user = "admin",
                                      password = "P@ssw0rd",
                                      host = "89.208.87.38",
                                      port = "5432",
                                      database = "myproddb")

        cursor = connection.cursor()
        cursor.execute("SELECT version();")
        record = cursor.fetchone()
        print("Connection opened to", record[0])

        cursor.execute(
            "INSERT INTO log VALUES ({});".format(randint(1, 10000)))
        connection.commit()
        cursor.execute("SELECT COUNT(event_id) from log;")
        record = cursor.fetchone()
        print("Logged a value, overall count: {}".format(record[0]))
    except Exception as error:
        print ("Error while connecting to PostgreSQL", error)
    finally:
        if connection:
            cursor.close()
            connection.close()
            print("Connection closed")


if __name__ == '__main__':
    try:
        while True:
            try:
                print(datetime.now())
                main()
                sleep(3)
            except Exception as e:
                print("Caught error:n", e)
                sleep(1)
    except KeyboardInterrupt:
        print("exit")

アプリケーションが動作するには PostgreSQL が必要です。 API を使用して MCS クラウドにクラスターを作成しましょう。 通常のターミナルでは、OS_TOKEN 変数に API にアクセスするためのトークン (openstack token issue コマンドで取得できます) が含まれており、次のコマンドを入力します。

クラスターを作成します。

cat <<EОF > pgc10.json
{"cluster":{"name":"postgres10","allow_remote_access":true,"datastore":{"type":"postgresql","version":"10"},"databases":[{"name":"myproddb"}],"users":[{"databases":[{"name":"myproddb"}],"name":"admin","password":"P@ssw0rd"}],"instances":[{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}},{"key_name":"shared","availability_zone":"DP1","flavorRef":"d659fa16-c7fb-42cf-8a5e-9bcbe80a7538","nics":[{"net-id":"b91eafed-12b1-4a46-b000-3984c7e01599"}],"volume":{"size":50,"type":"DP1"}}]}}
EOF

curl -s -H "X-Auth-Token: $OS_TOKEN" 
-H 'Accept: application/json' 
-H 'Content-Type: application/json' 
-d @pgc10.json https://infra.mail.ru:8779/v1.0/ce2a41bbd1434013b85bdf0ba07c770f/clusters

クラスターが ACTIVE ステータスに切り替わると、すべてのフィールドが現在の値を受け取ります。クラスターの準備は完了です。

GUI の場合:

接続してテーブルを作成してみましょう。

psql -h 89.208.87.38 -U admin -d myproddb
Password for user admin:
psql (11.1, server 10.7)
Type "help" for help.

myproddb=> CREATE TABLE log (event_id integer NOT NULL);
CREATE TABLE
myproddb=> INSERT INTO log VALUES (1),(2),(3);
INSERT 0 3
myproddb=> SELECT * FROM log;
 event_id
----------
        1
        2
        3
(3 rows)

myproddb=>

アプリケーションでは、PostgreSQL に接続するための現在の設定を示します。 TCP バランサーのアドレスを指定することで、マスター アドレスに手動で切り替える必要がなくなります。 起動しましょう。 ご覧のとおり、イベントはデータベースに正常に記録されています。

スケジュールされたマスター切り替え

次に、スケジュールされたマスター切り替え中のアプリケーションの動作をテストしてみましょう。

私たちはアプリケーションを監視しています。 アプリケーションが確かに中断されていることがわかりますが、それにかかる時間はわずか数秒、この特定のケースでは最大 9 秒です。

自動車事故

次に、現在のマスターである仮想マシンのクラッシュをシミュレートしてみましょう。 Horizo​​n インターフェイスを介して仮想マシンを単純にオフにすることもできますが、これは通常のシャットダウンになります。 このような切り替えは、Patroni を含むすべてのサービスによって処理されます。

予測できないシャットダウンが必要です。 したがって、私は管理者に、テスト目的で仮想マシン (現在のマスター) を非標準的な方法でシャットダウンするように依頼しました。

同時に、アプリケーションは引き続き動作しました。 当然のことながら、このようなマスターの緊急切り替えが無視されるはずはありません。

2019-03-29 10:45:56.071234
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 453
Connection closed
2019-03-29 10:45:59.205463
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 454

Connection closed
2019-03-29 10:46:02.661440
Error while connecting to PostgreSQL server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Caught error:
 local variable 'connection' referenced before assignment
……………………………………………………….. - здесь какое-то количество ошибок
2019-03-29 10:46:30.930445
Error while connecting to PostgreSQL server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Caught error:
 local variable 'connection' referenced before assignment
2019-03-29 10:46:31.954399
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 455
Connection closed
2019-03-29 10:46:35.409800
Connection opened to PostgreSQL 10.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit
Logged a value, overall count: 456
Connection closed
^Cexit

ご覧のとおり、アプリケーションは 30 秒以内に作業を続行できました。 はい、一定数のサービス ユーザーは問題に気づく時間があります。 ただし、これは深刻なサーバー障害であり、頻繁に発生するものではありません。 この場合、人 (管理者) は、コンソールに座って切り替えスクリプトの準備ができていない限り、これほど迅速に対応する時間はほとんどありませんでした。

出力

このようなクラスターは管理者にとって非常にメリットがあるように思えます。 実際、データベース サーバーの重大な故障や障害は、アプリケーション、ひいてはユーザーには気付かれません。 急いで何かを修正したり、一時的な構成やサーバーなどに切り替える必要はありません。 また、そのようなソリューションがクラウド内の既製のサービスとして使用されれば、準備に時間を無駄にする必要はありません。 もっと面白いことができるようになるでしょう。

出所： habr.com