高可用性Postgresクラスターのドッキング

数か月前に、Amazonから専用サーバー（Hetzner）に移行しました。この理由の1つは、RDSのコストが高いことです。 専用サーバーでマスタースレーブクラスターを構成して起動するタスクがありました。 グーグルで公式ドキュメントを読んだ後、高可用性Postgres非同期クラスター用の独自のソリューションを構築することにしました。



目標

• できるだけ少ないツールと依存関係を使用してください。
• 透明性を目指して、魔法はありません！
• pg-pool、stolonなどのすべてを含むコンバインを使用しないでください。
• ドッカーと彼のパンを使用してください。

それでは始めましょう。 実際には、Postgres自体と、レプリケーション管理とクラスター監視を扱うrepmgrなどのすばらしいツールが必要です。



このプロジェクトはpg-dockと呼ばれ、3つの部分で構成されます。各部分はgithub上にあり、それらを自由に変更できます。

• pg-dock-configは準備完了です-構成ファイルのセットで、2つのノードがマスタースレーブに登録されています。
• pg-dockは、構成をパックし、それらを適切な形式で適切な場所にあるノードに配信します。
• pg-dock-baseは、ノードで実行される基本的なdockerイメージです。

各部分を詳細に分析しましょう：



pg-dock-config

クラスター構成の構造は次のとおりです

さらにノードがある場合は、2つのノード（n1、n2）がリポジトリに既に登録されているため、新しいノードの名前で別のフォルダーを作成するだけです。 各ノードには独自の構成ファイルがあります。 すべてが非常に単純であるように思えます。たとえば、envフォルダーは、docker-compose、postgresフォルダー、postgres configsなどによって取得される環境変数です。 たとえば、ファイルpg-dock-conf / n1 / env / main POSTGRES_USER=postgres POSTGRES_PASSWORD=postgres POSTGRES_DB=testdb PGDATA=/var/lib/postgresql/data HETZNER_USER=**** HETZNER_PASS=**** HETZNER_FAILOVER_IP=1.2.3.4 HETZNER_ACTIVE_SERVER_IP=5.6.7.8 postgresの初期初期化中に、ユーザーpostgresとtestdbデータベースが作成されることを教えてくれます。 また、古いマスターノードが使用できなくなった場合に新しいマスターノードにipを変更するfailover-ipスクリプトの登録済み変数もあります。 pg-dock-conf / n1 / env / backup s3上のデータベースのインターバルバックアップの環境変数は、サービスの開始時にdocker-composeによって取得されます。

共通の構成ファイルがある場合、ノードごとにそれらを複製しないように、共有フォルダーに配置します。



その構造を見ていきましょう。

• フェイルオーバー
  
  私の場合、Hetzner failover-ipのスクリプトがあります。これは、ipを新しいマスターに変更します。 あなたの場合、それはkeepalivedスクリプトまたは類似のものである可能性があります。
• initdb
  
  すべてのSQL初期化クエリは、このフォルダーに配置する必要があります。
• ssh
  
  別のノードに接続するためのキーを次に示します。この例では、すべてのノードのキーは同じであるため、共有フォルダーにあります。 ּּSshでは、スイッチオーバーなどの操作を行うためにrepmgrが必要です。
• sshd
  
  sshサーバーの構成ファイルsshはポート2222で機能するため、ホストのデフォルトポートと重複しません（22）

pg-dock

ここでは、構成は各ノードに実際にパッケージ化されています。



一番下の行は、ドッカーイメージにノードの構成をパックし、ハブまたはレジストリにプッシュしてから、ノードで更新を行うことです。

作業には基本的な操作があり、構成ビルド（build.sh）を作成し、ノードの構成を更新します （update.sh）およびクラスター自体（docker-compose.yml）を開始します ヘルパー クラスターのサポートファイル 管理する たとえば、ウィザードからデータを複製してスレーブを起動するなど、生活を簡素化する既製のスクリプト。 S3からのバックアップの復元。

起動時：

 PG_DOCK_NODE=n1 PG_DOCK_CONF_IMAGE=n1v1 ./build.sh docker images REPOSITORY TAG IMAGE ID CREATED SIZE n1v1 latest 712e6b2ace1a 6 minutes ago 1.17MB
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成pg-dock-conf / n1がフォルダーpg-dock / pg-dock-conf-n1にコピーされ、すべての依存関係でdockerビルドが開始されます。出力は、n1v1という名前のイメージで、ノードn1の構成が保存されます。



起動時：

 PG_DOCK_CONF_IMAGE=n1v1 ./update.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、ホスト上のすべての構成ファイルを更新するコンテナが起動します。 したがって、複数の構成イメージを作成したり、異なるバージョンにロールバックしたりできます。



pg-docker-base

クラスターのすべてのパッケージがインストールされている基本的なdockerイメージ：repmgr、rsync、openssh-server、supervisor（ Dockerfile ）。 イメージ自体は最新バージョンのpostgres 9.6.3に基づいていますが、他のビルドも使用できます。 コンポーネントは、postgresユーザーの下からスーパーバイザーによって起動されます。 サーバーでこのイメージを実行します（repmgrを機能させるには、rsync、openssh-serverが必要です）。



クラスターを開始しましょう！

便宜上、この記事ではすべての操作はdocker-machineを使用して行われます。



pg-dockおよびpg-dock-confプロジェクトを作業フォルダー（labなど）に複製します。

 mkdir ~/lab && cd ~/lab git clone https://github.com/xcrezd/pg-dock git clone https://github.com/xcrezd/pg-dock-conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ノード、グループ、postgresユーザーを作成します（uid、gidはホスト上とコンテナ内で5432でなければなりません）

 docker-machine create n1 docker-machine ssh n1 sudo addgroup postgres --gid 5432 docker-machine ssh n1 sudo adduser -u 5432 -h /home/postgres --shell /bin/sh -D -G postgres postgres # debian/ubuntu #sudo adduser --uid 5432 --home /home/postgres --shell /bin/bash --ingroup postgres --disabled-password postgres docker-machine create n2 docker-machine ssh n2 sudo addgroup postgres -g 5432 docker-machine ssh n2 sudo adduser -u 5432 -h /home/postgres --shell /bin/sh -D -G postgres postgres
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/ etc / hostsにipノードを追加します

 docker-machine ip n1 #192.168.99.100 docker-machine ip n2 #192.168.99.101 #   n1 docker-machine ssh n1 "sudo sh -c 'echo 192.168.99.100 n1 >> /etc/hosts'" docker-machine ssh n1 "sudo sh -c 'echo 192.168.99.101 n2 >> /etc/hosts'" #   n2 docker-machine ssh n2 "sudo sh -c 'echo 192.168.99.100 n1 >> /etc/hosts'" docker-machine ssh n2 "sudo sh -c 'echo 192.168.99.101 n2 >> /etc/hosts'"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マシンのIPが記事のIPと異なる場合、それらを追加する必要があります

• pg-dock-config / n1 / postgres / pg_hba.conf
• pg-dock-config / n2 / postgres / pg_hba.conf

構成のイメージを作成し、すぐにノードで更新します

 cd pg-dock docker-machine use n1 PG_DOCK_NODE=n1 PG_DOCK_CONF_IMAGE=n1v1 ./build.sh PG_DOCK_CONF_IMAGE=n1v1 ./update.sh docker-machine use n2 PG_DOCK_NODE=n2 PG_DOCK_CONF_IMAGE=n2v1 ./build.sh PG_DOCK_CONF_IMAGE=n2v1 ./update.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

docker-machine useコマンド（実行方法 ）に注意してください。使用するたびに、dockerクライアントのコンテキストを変更します。つまり、最初のケースでは、dockerでのすべての操作はノードn1で、次にn2で行われます。



コンテナーを起動する

 docker-machine use n1 PG_DOCK_NODE=n1 docker-compose up -d docker-machine use n2 PG_DOCK_NODE=n2 docker-compose up -d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

docker-composeは、s3への定期的なバックアップを行うpg-dock-backupコンテナーも起動します。

次に、必要なファイルが保存されている場所を見てみましょう。

ファイル	ホスト	コンテナ
Db	/ opt / pg-dock /データ	/ var / lib / postgresql /データ
ログ	/ opt / pg-dock /ログ	/ var / log /スーパーバイザー
構成とスクリプト	/ opt / pg-dock /スクリプト	** docker-compose.ymlを学ぶ

クラスターを構成します

 docker-machine use n1 #    docker exec -it -u postgres pg-dock repmgr master register docker-machine use n2 #    n1 docker exec -it -u postgres -e PG_DOCK_FROM=n1 pg-dock manage/repmgr_clone_standby.sh #    docker exec -it -u postgres pg-dock repmgr standby register
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以上で、クラスターの準備は完了です

 docker exec -it -u postgres pg-dock repmgr cluster show Role | Name | Upstream | Connection String ----------+------|----------|-------------------------------------------- * master | n1 | | host=n1 port=5432 user=repmgr dbname=repmgr standby | n2 | n1 | host=n2 port=5432 user=repmgr dbname=repmgr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼のロボット性を確認しましょう。 pg-dock-config / shared / testsフォルダーには、クラスターをテストするための準備があります。

 #   cat tests/prepare.sh CREATE TABLE IF NOT EXISTS testtable (id serial, data text); GRANT ALL PRIVILEGES ON TABLE testtable TO postgres; # 100000  cat tests/insert.sh insert into testtable select nextval('testtable_id_seq'::regclass), md5(generate_series(1,1000000)::text); #     cat tests/select.sh select count(*) from testtable;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストテーブルを作成し、データを入力して、スレーブ上にあるかどうかを確認します。

 docker-machine use n1 #      docker exec -it -u postgres pg-dock config/tests/prepare.sh #    docker exec -it -u postgres pg-dock config/tests/insert.sh INSERT 0 1000000 docker-machine use n2 #     n2 () docker exec -it -u postgres pg-dock config/tests/select.sh count --------- 1000000 (1 row)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利益！



それでは、ウィザードのクラッシュシナリオを見てみましょう。

 #   docker-machine use n1 docker stop pg-dock #  repmgr   docker-machine use n2 docker exec -it pg-dock tailf /var/log/supervisor/repmgr-stderr.log #NOTICE: STANDBY PROMOTE successful
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスターの状態を確認します。

 docker exec -it -u postgres pg-dock repmgr cluster show Role | Name | Upstream | Connection String ---------+------|----------|-------------------------------------------- FAILED | n1 | | host=n1 port=5432 user=repmgr dbname=repmgr * master | n2 | | host=n2 port=5432 user=repmgr dbname=repmgr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、新しいマスターはn2になり、フェイルオーバーipもそれを指します。

今、古いマスターを新しいスレーブとして返しましょう

 docker-machine use n1 #  PG_DOCK_NODE=n1 docker-compose up -d #  #    n2 docker exec -it -u postgres -e PG_DOCK_FROM=n2 pg-dock manage/repmgr_clone_standby.sh #    docker exec -it -u postgres pg-dock repmgr standby register -F
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスターの状態を確認します。

 docker exec -it -u postgres pg-dock repmgr cluster show Role | Name | Upstream | Connection String ---------+------|-----------|-------------------------------------------- * master | n2 | | host=n2 port=5432 user=repmgr dbname=repmgr standby| n1 | n2 | host=n1 port=5432 user=repmgr dbname=repmgr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

できた！ そして、これが私たちが何とかできることです。 マスターを削除し、新しいマスターによるスレーブの自動割り当てが機能し、フェールオーバーIPが変更されました。 システムは機能し続けます。 次に、ノードn1を復活させて、新しいスレーブにしました。 興味を引くために、先ほどと同様に、n1をマスターに、n2をスレーブに手動で切り替えます。 これがrepmgrの目的であり、sshが必要です。スレーブはsshを介してマスターに接続し、スクリプトを使用して必要な操作を行います。



切り替え：

 docker-machine use n1 docker exec -it -u postgres pg-dock repmgr standby switchover #NOTICE: switchover was successful
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスターの状態を確認します。

 docker exec -it -u postgres pg-dock repmgr cluster show Role | Name | Upstream | Connection String ----------+------|----------|-------------------------------------------- standby | n2 | | host=n2 port=5432 user=repmgr dbname=repmgr * master | n1 | | host=n1 port=5432 user=repmgr dbname=repmgr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それがすべて、次にノードの構成を更新する必要があるとき、それがpostgres、repmgr、またはスーパバイザ構成であろうと、それをパックして更新するだけです：

 PG_DOCK_NODE=n1 PG_DOCK_CONF_IMAGE=n1v1 ./build.sh PG_DOCK_CONF_IMAGE=n1v1 ./update.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい構成を更新した後：

 #  postgres docker exec -it -u postgres pg-dock psql -c "SELECT pg_reload_conf();" #  supervisor docker exec -it -u postgres pg-dock supervisorctl reread #   docker exec -it -u postgres pg-dock supervisorctl restart foo:sshd
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

* すばらしいボーナスです。スーパーバイザーにはログローテーションの機能があるため、それについても心配する必要はありません。

* コンテナはホストネットワークを介して直接動作するため、ネットワーク仮想化の遅延を回避できます。

* 既存の実稼働ノードをdocker-machineに追加することをお勧めします。これにより、作業が大幅に簡素化されます。



次に、クエリバランシングのトピックに触れます。 複雑にしたくありませんでした（つまり、pg-pool、haproxy、stolonを使用しました）ので、アプリケーション側でバランスを取り、それにより、バランサー自身の高可用性を編成する責任から解放されます。 バックエンドは摩擦で記述されているため、gem makaraを選択しました。 gemは、データの選択と変更（挿入/更新/削除/変更）のリクエストを分離できます。選択のリクエストは、複数のノード（スレーブ）間で分散できます。 ノードの1つに障害が発生した場合、ヘムは一時的にそれをプールから除外できます。



database.yml設定ファイルの例：

 production: adapter: 'postgresql_makara' makara: # the following are default values blacklist_duration: 5 master_ttl: 5 master_strategy: failover sticky: true connections: - role: master database: mydb host: 123.123.123.123 port: 6543 weight: 3 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %> - role: slave database: mydb host: 123.123.123.124 port: 6543 weight: 7 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他の言語/フレームワークのライブラリ：

→ ララベル

→ Yii2

→ Node.js

おわりに

したがって、結果として得られたもの：

• 自己完結型のマスター/スタンバイクラスターは、戦闘に備えています。
• すべてのコンポーネントの透明性、簡単な互換性。
• マスターに障害が発生した場合の自動フェイルオーバー（repmgr）
• クライアントの負荷分散により、バランサーの可用性に対する責任が除去されます。
• 単一障害点がないため、repmgrはIPアドレスを新しいノードに転送するスクリプトを実行します。新しいノードは、障害が発生した場合にマスターにアップグレードされました。 テンプレートにはhetzner用のスクリプトがありますが、keepalived、aws elasticIp、drdb、pacemaker、corosyncの追加を妨げるものはありません。
• バージョン管理、問題/ abテストの場合にロールバックを行う機能。
• システムを自分用にカスタマイズしたり、ノードを追加したり、repmgr witness、たとえば構成の柔軟性や変更を確認する機能。
• S3への定期的なバックアップ

次回の記事では、高可用性を失わずにpg-dockとPgBouncerを同じノードに配置する方法を説明します。ご清聴ありがとうございました！



習熟のための推奨事項：

• Postgresでのストリーミングレプリケーション
• Repmgr
• スーパーバイザー