PostgreSQLのフェールオーバークラスターマスタースレーブ

こんにちは、habrozhitel！

この記事では、PostgreSQL DBMSにマスタースレーブクラスターを展開した経験を共有したいと思います。 フォールトトレランスは、pgpool-IIの機能（フェールオーバー、オンラインリカバリ）を使用して実現されます。

pgpoolはサーバー間のスケーリングと負荷分散のための優れたツールであり、マスターに障害が発生したときにスレーブサーバーにフェールオーバーを自動的に作成する可能性と、クラスター全体をシャットダウンせずに既に実行中のクラスターに新しい電源を追加する方法について知っている人は少ないと思います。

クラスタ図とマシン要件

図は、マスター/スレーブクラスターの一般的な図を示しています。



クラスターには、1つのマスターサーバー（マスター）、少なくとも1つのスレーブ（スレーブ）、1つのスケーリングノード（バランサー）が含まれている必要があります。

Linuxディストリビューションを各サーバーにインストールする必要がある場合（Red Hat 6.1をインストールしています）、gccコンパイラーをスケーリングノードにインストールする必要があります。

PostgreSQLバージョンは9.0.1、pgpool-II 3.0.5です。 DBMSおよびpgpoolの他のバージョンを使用できます。 この場合、ドキュメントを参照してください。

クラスタサーバー間のリモート接続のセットアップ

オンライン回復とフェイルオーバーでは、パスワードなしでSSH経由でリモート接続を設定する必要があります。 これを行うには、 postgres



ユーザーのSSHキーを作成し、それらを各サーバーのpostgres



ユーザーに送信します。

重要なポイント！ オンラインリカバリの場合、リモートセッションを開いたときに、別のリモートセッションに移動できる必要があります（つまり、パスワードなしで次のSSH移行メカニズムを実装できます：スケーリングノード-マスターサーバー-スレーブサーバーおよびスケーリングノード-スレーブサーバー-マスターサーバー）。

フェールオーバーの場合、スケールノードでroot



ユーザーSSHキーを作成し、マスターサーバーとスレーブサーバーをpostgres



ユーザーに転送する必要があります。

この手順は設定時に重要なので、リモートセッションから1つのサーバーを別のサーバーに接続できることを確認してください。

ストリーミングレプリケーションを構成する

まず、iptablesのポート5432（標準のPostgreSQLポート）でデータの受信/送信を開く必要があります。

マスターサーバーの構成ファイル$PGDATA/postgresql.conf



次のように編集します。

 listen_addresses = '*' wal_level = hot_standby max_wal_senders = 2 wal_keep_segments = 32 #hot_standby = on
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の行の重要性に注意します。 実際には、スレーブノードの回復スクリプトで使用されるため、上記のように変更する必要があります。

次に、レプリケーション行を$PGDATA/pg_hba.conf



に追加し$PGDATA/pg_hba.conf



。

 host replication postgres 192.168.100.2/32 trust host replication postgres 192.168.100.3/32 trust
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

postgresは、レプリケーションやその他の管理トリックを行うデータベース管理者です。 これらの行を使用して、スレーブサーバーとマスターサーバーの両方のレプリケーションを許可しました。

次に、主要なサーバーを再起動します。

 # service postgresql restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スレーブサーバーを停止します（以前に起動した場合）：

 # service postgresql stop
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、レプリケーションを開始できます。

マスターサーバーで、 postgres



ユーザーpostgres



バックアップデータベースをpostgres



それをスレーブサーバーに送信します。

 $ psql -c "SELECT pg_start_backup('stream');" $ rsync -a /var/lib/pgsql/data/ 192.168.100.3:/var/lib/pgsql/data/ --exclude postmaster.pid $ psql -c "SELECT pg_stop_backup();"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、 スレーブ上で、レプリケーション構成$PGDATA/recovery.conf



を作成します。

 standby_mode = 'on' primary_conninfo = 'host=192.168.100.2 port=5432 user=postgres' trigger_file = 'failover'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

trigger_file



パラメーターは、PostgreSQLがマスターモードに切り替えるファイルを検索するパスを担当します。 この場合、PostgreSQLはパス$PGDATA/failover



ファイルを検索し$PGDATA/failover



。

次に、スレーブサーバーで「ホットスタンバイ」を有効にする必要があります。

 $ sed -i 's/#hot_standby = on/hot_standby = on/' /var/lib/pgsql/data/postgresql.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、スレーブサーバーを起動する必要があります。

 # service postgresql start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複製アクティビティは次のように確認できます。

マスターサーバーで、次のコマンドを実行します

 $ ps aux | grep sender
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように出力されます：

 2561 ? Ss 0:00 postgres: wal sender process postgres 192.168.100.3(33341) streaming 0/2031D28
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、スレーブサーバー上で：

 $ ps aux | grep receiver
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼女は以下を与えます：

 1524 ? Ss 0:00 postgres: wal reciever process streaming 0/2031D28
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ズームノードの一般的な構成

設定ファイル/etc/pgpool-II/pgpool.conf



変更します。

 #      listen_addresses = '*' #        backend_hostname0 = '192.168.100.3' backend_port0 = 5432 backend_weight0 = 1 backend_data_directory0 = '/var/lib/pgsql/data' #        backend_hostname1 = '192.168.100.2' backend_port1 = 5432 backend_weight1 = 1 backend_data_directory1 = '/var/lib/pgsql/data' #  pool_hba.conf    enable_pool_hba = true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに/etc/pgpool-II/pool_hba.conf



、クライアント認証に関する情報/etc/pgpool-II/pool_hba.conf



追加します。

 host all all 127.0.0.1/32 trust host all all 192.168.100.2/32 trust host all all 192.168.100.3/32 trust
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pgpoolを再起動します。

 # service pgpool restart
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

自動フェールオーバーを構成する

自動フェールオーバーを作成するメカニズムは次のとおりです。

1. 稼働中の（マスターおよびスレーブ）サーバーでは、 pgpool-walrecrunning()
   
   
   
   プロシージャが実行され、どのサーバーがマスターであり、どのスレーブであるかが決定されます。
2. pgpoolは本番サーバーにリモートで接続し、DBMSプロセスのアクティビティをチェックします。 そうでない場合、pgpoolは、マスターサーバーに障害が発生した場合にスレーブでフェールオーバーを作成するスクリプトを呼び出します。
3. その後、pgpoolは落ちたホストから切断し、接続されているすべてのクライアントアプリケーションを再起動します。

そして今、設定：

スケールノードで、 /etc/pgpool-II/pgpool.conf



変更します。

 # ,     failover_command = '/etc/pgpool-II/failover.sh %d %H /var/lib/pgsql/data/failover' # ,    health_check_user = 'postgres' #    "-" master_slave_mode = true #     ,    '' master_slave_sub_mode = 'stream' #   pgpool      ,        replication_mode = false #   ,        load_balance_mode = true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

failover_command



パラメーターについてもう少し説明します。 この行で指定されたスクリプトには、パラメーター%d



落ちたノードの識別子（ backend_hostname



にpgpool.conf



）、 %H



新しいマスターサーバーのIPがbackend_hostname



れます。

実際にfailover.sh



スクリプト自体：

 #! /bin/bash # ID   FAILED_NODE=$1 # IP   NEW_MASTER=$2 #     TRIGGER_FILE=$3 if [ $FAILED_NODE = 1 ]; then echo "    " exit 1 fi echo "    " echo "  : $NEW_MASTER" ssh -T postgres@$NEW_MASTER touch $TRIGGER_FILE exit 0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは、pgpool /etc/pgpool-II/



ディレクトリに作成し、755のアクセス許可を付与する必要があります。

次に、pgpoolプロシージャをコンパイルする必要があります。 sql/pgpool-walrecrunning



パッケージsrcには、必要な手順のソースコードが含まれています。 コンパイルするには、PostgreSQLヘッダーファイルが必要です。その後、 make



コマンドを使用しmake



pgpool-walrecrunning.so



とSQLクエリを取得し、このプロシージャpgpool-walrecrunning.sql



をロードpgpool-walrecrunning.sql



ます。

プロシージャは、各作業サーバー上のディレクトリ/usr/lib64/pgsql/



にコピーする必要があります。このディレクトリは、 $libdir



と呼ばれ、 /usr/share/pgsql/



にあるsqlファイルです。

主要なサーバーのデータベースにロードします。

 psql -f /usr/share/pgsql/pgpool-walrecrunning.sql -d postgres
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この手順をスレーブサーバー上のデータベースにアップロードする必要はありません。以前に設定されたレプリケーションにより利用可能になります。

以上です。



サーバーの状態はクエリで判断できます

 SHOW pool_nodes;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スケールノードでpsql



クライアントにログインした後。

リクエストの出力例：

  hostname | port | status | lb_weight ----------------------------------------------------- 192.168.100.3 | 5432 | 2 | 0.500000 192.168.100.2 | 5432 | 2 | 0.500000 (2 rows)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー2のステータスは、サーバーがアクティブであり、リクエストに使用できることを意味します。 サーバーの1つに障害が発生すると、ステータスは3に変わります。



次のように自動フェールオーバーメカニズムをテストできます。

1. マスターサーバーを無効にする
2. SHOWリクエストpool_nodesを実行します。 ズームノード上
3. スクリプト実行のpgpoolログを見る
4. スクリプトを受信した後、スレーブサーバーが書き込み要求を受け入れることができることを確認してください

オンライン復旧

おそらく、このメカニズムはデバッグの点で最も困難ですが、同時にデータベースを管理するための強力なツールです。 このメカニズムの動作は次のとおりです。動作中のクラスターがあり、以前にスレーブサーバーをオンにしたいが、そこに保存されているデータがクラスター内のデータと一致しません。 このメカニズムにより、クラスターを停止してセットアップ時に追加のアクションを実行することなく、リアルタイムで別のスレーブサーバーを追加できます。

オンライン回復は次のように機能します。

1. 復旧ノードは、スレーブサーバーの復旧プロセスを開始します
2. この手順では、マスターサーバーとスレーブサーバーの間で自動レプリケーションを実行するスクリプトをマスターサーバーで実行します
3. レプリケーションが成功すると、標準のPostgreSQL PGCTL
   
   
   
   を使用してホストサーバーのベースがリモートで起動されPGCTL
   
   
   
   
4. pgpoolが再起動し、スレーブサーバーを検出してクラスターに含めます

セットアップに進みます。

/etc/pgpool-II/pgpool.conf



次の行を追加します。

 # ,   recovery_user = 'postgres' #    recovery_password = '123456' # ,       $PGDATA recovery_1st_stage_command = 'basebackup.sh'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

postgres



パスワードハッシュを追加します。

 # pg_md5 123456 >> /etc/pgpool-II/pcp.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

123456はクリアテキストのpostgres



パスワードです。 さらに、パスワードハッシュの前に、このハッシュが属するユーザー名、つまり ファイルにはpostgres:enrypted_password



という行が含まれている必要があります。

マスターノードbasebackup.sh



次の内容のbasebackup.sh



スクリプトを作成します。

 #!/bin/bash #    $PGDATA    PRIMARY_DATA=$1 # IP-  ,     SLAVE_IP=$2 #    $PGDATA    SLAVE_DATA=$3 #  IP       recovery.conf PRIMARY_IP=$(ifconfig eth0| sed -n '2 {s/^.*inet addr:\([0-9.]*\) .*/\1/;p}') #        TMP_DIR=/var/lib/pgsql/tmp #         (    - ) cd $PRIMARY_DATA rm -f recovery.* failover # ,         cat postgresql.conf | grep '#hot_standby = on' #  ,    if [ $? = 1 ] then sed -i 's/hot_standby = on/#hot_standby = on/' postgresql.conf #    /usr/bin/pg_ctl restart -D $PGDIR fi #    ssh -T postgres@$SLAVE_IP "/usr/bin/pg_ctl stop -D $SLAVE_DATA" #  backup     psql -c "SELECT pg_start_backup('Streaming Replication', true)" postgres #    rsync -a $PRIMARY_DATA/ $SLAVE_IP:$SLAVE_DATA/ --exclude postmaster.pid --exclude postmaster.opts #        mkdir $TMP_DIR cd $TMP_DIR #   postgresql.conf   hot_standby cp $PRIMARY_DATA/postgresql.conf $TMP_DIR/ sed -i 's/#hot_standby = on/hot_standby = on/' postgresql.conf #   recovery.conf echo "standby_mode = 'on'" > recovery.conf echo "primary_conninfo = 'host=$PRIMARY_IP port=5432 user=postgres'" >> recovery.conf echo "trigger_file = 'failover'" >> recovery.conf #        ssh -T postgres@$SLAVE_IP rm -f $SLAVE_DATA/recovery.* #    scp postgresql.conf postgres@$SLAVE_IP:$SLAVE_DATA/postgresql.conf scp recovery.conf postgres@$SLAVE_IP:$SLAVE_DATA/recovery.conf #  backup psql -c "SELECT pg_stop_backup()" postgres #      cd .. rm -fr $TMP_DIR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは$PGDATA



ディレクトリにある必要があることを強調し$PGDATA



。 スクリプト755に権利を割り当てます。

$PGDATA



ディレクトリのスレーブおよびマスターサーバーで、 pgpool_remote_start



スクリプトを作成します（ この名前の下にあります！ ）。次の内容を使用します。

 #! /bin/bash if [ $# -ne 2 ] then echo " ,  " exit 1 fi SLAVE_IP=$1 SLAVE_DIR=$2 PGCTL=/usr/bin/pg_ctl ssh -T $SLAVE_IP $PGCTL -w -D $SLAVE_DIR start 2>/dev/null 1>/dev/null < /dev/null &
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

DBMSプロセスをリモートで開始できます。

次に、スケールノードで、 pgpool-recovery.so



パッケージのsql/pgpool-recovery



pgpool-recovery.so



sql/pgpool-recovery



srcパスにあるpgpool-recovery.so



ストアドプロシージャをコンパイルする必要があります。 同様に、本番サーバーに転送し、データベースにプロシージャをロードします。

 $ psql -f /usr/share/pgsql/pgpool-recovery.sql -d template1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、オンラインリカバリのセットアップが完了しました。



新しいスレーブサーバーをクラスターに含めるには、次の手順を実行する必要があります。

1. 新しいマスターノードでベースを起動します
2. スケーリングノードで、サーバーリカバリコマンドを実行します： pcp_recovery_node 20 192.168.100.4 9898 postgres 123456 1
   
   
   
   

pcp_recovery_node



詳細。 このコマンドは、クラスターへのサーバー回復を実装します。 20



はスレーブサーバーへの接続試行回数、 192.168.100.4



はスケーリングノードのIP、 9898



はスケーリングノードのコマンドの9898



ポート、 postgres



は回復を実行するユーザーの名前、 123456



はそのパスワード、 1



は復元されたノードのIDです。

これで、オンラインリカバリのセットアップが完了しました。



次の計画に従って、これら2つのメカニズムをテストできます。

1. マスターサーバーにテストデータベースを作成します。 彼女がスレーブに複製したことを確認してください
2. 無効にしてホストサーバーの障害をシミュレートする
3. フェイルオーバーが機能し、スレーブサーバーが新しいマスターになったことを確認します
4. スレーブサーバー上のデータベースに変更を加えます
5. 倒れたマスターサーバーを実行し、オンラインリカバリを実行してスレーブにします

したがって、上記のメカニズムにより、マスター/スレーブクラスターを保護し、復元する際のデータベース管理者の作業を簡素化できます。



PSこの投稿が誰かの助けになることを願っています。 コメントや追加は大歓迎です！ ご清聴ありがとうございました。