PostgreSQL機能のハイライト：pg_rewindを使用して古いマスターをすぐにスタンバイに変更します

PostgreSQLでストリーミングレプリケーションを操作するときにフェールオーバー手順を処理しなければならなかった人は誰でも、「どうすれば再びコピーできず、古いウィザードをスタンバイとしてすぐに起動できますか？」という質問に戸惑うでしょう。 そのため、残念ながらPostgreSQLにはそのような組み込み機能はありません。 はい、古いマスターを新しいマスターに接続して接続することはできません。 これを行うには、ストリーミングレプリケーションを再度セットアップするプロセスを繰り返します。 クラスタ全体をコピーし、ホットスタンバイモードでpostgresを実行します。

幸いなことに、この方向での作業は進行中であり、結果は十分悪くはありません。 プロジェクトはpg_rewindと呼ばれます 。

私はすぐに、これはまだ生産準備が整っておらず、投稿はハウツー+テクノロジープレビューの性質であることを警告します。



既知の制限：

• 現在、pg_rewindはバージョン9.4および部分的に9.3でのみ動作します。 理由の一部は、クラスターをチェックサムサポート（ initdb -k ）で初期化する必要があるためです。 バージョン9.4ではよりシンプルになり、チェックサムサポートまたはwal_log_hintsパラメーターがオンに設定されている必要があります。
• もう1つの重要な制限は、マスターを通常にオフにする必要があることです。 つまり、マスターが誤ってオフにされた場合、巻き戻しは実行されません。 しかし、開発者はこの方向に取り組んでいます。
• テーブルスペースはサポートされておらず、WALアーカイブでの作業は実装されていません（欠落しているアーカイブは手動でコピーする必要があります）。

もう少し理論と実践に移ります...巻き戻しのプロセスは何ですか：

• WAL分岐の瞬間から古いノードのディレクトリをスキャンし、分岐後に変更されたブロックを記録します。
• 変更されたブロックを新しいウィザードから古いウィザードにコピーします。
• 残りのファイル（詰まり、構成ファイルなど）のコピー。
• recovery.confを編集し、新しい設定で古いウィザードを起動します。
• フェールオーバー後のコントロールポイントの瞬間からのWALの複製。

以下のプラクティスでは、完全に再初期化せずに古いマスターを「巻き戻し」、新しいマスターに接続する方法のプロセスを説明します。

計画は簡単です。

• PostgreSQL 9.4をビルドしてインストールします（現在はdevelのみ）。
• pg_rewindをビルドします。
• ストリーミングレプリケーションを設定する
• フェイルオーバーを実行します。
• 古いマスターを巻き戻し、新しいマスターに接続します。

すべての操作はCentOS 6.5で実行されます。 一般に、プロセスは非常に単純で、pg_rewindのアセンブリ段階で最も困難だったので、プロセスを完全に説明します。

さあ、行こう！ 最初に、postgresqlをビルドするときに依存関係として必要ないくつかのパッケージをインストールする必要があります。 インストール後、リポジトリのクローンを作成し、PostgreSQLのインストールを実行します。

# yum install git gcc zlib-devel flex bison readline-devel pam-devel openssl-devel libxslt-devel # git clone --branch master http://git.postgresql.org/git/postgresql.git # git clone https://github.com/vmware/pg_rewind # cd postgresql # ./configure && make && make install
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、PostgreSQLは/ usr / localにインストールされ、すべてのユーティリティは/ usr / local / pgsql / binにあるため、このパスをPATH環境変数に追加する必要があることに注意してください。 あなたはさまざまな方法でこれを行うことができます、私は次のように、CentOSのために多かれ少なかれまともな（そしておそらくそれほどではない）方法で行動しました：

 # vi /etc/profile.d/pgsql-9.4.sh PGSQL94_BINDIR=/usr/local/pgsql/bin pathmunge $PGSQL94_BINDIR export PGSQL94_BINDIR # source /etc/profile
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pg_rewindコードがあるディレクトリに移動して、ユーティリティをビルドします。 結果のユーティリティは、単にpostgresユーティリティにコピーされます。

 # cd ../pg_rewind # make USE_PGXS=1 top_srcdir=../postgresql/ # cp pg_rewind /usr/local/pgsql/bin/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、ストリーミングレプリケーションを構成します。 最初に書いたように、pg_rewindを正常に動作させるには、次の2つの条件のいずれかを満たす必要があります。

1）クラスターはチェックサムサポート（initdb -k）で初期化する必要があります。

または

2）postgresql.confのwal_log_hints = onオプションでpostgresサービスを開始する必要があります

2番目のオプションを選択しました。

セットアッププロセスは既に何 度も説明されているので、ここでやめません。

そのため、レプリケーションが構成されて機能しているときに、フェールオーバーを実行します。 この操作を実行するには、trigger_fileオプションのrecovery.confで指定されたトリガーファイルを作成します。 トリガーファイルを作成すると、スタンバイはウィザードモードに切り替わり、独自のライフを開始します。 したがって、古いマスターをオフにする必要があります。

そして今、pg_rewindが登場します。 パラメーターは、古いマスターのクラスター（ -D ）が配置されているディレクトリと、新しいマスターサーバーに接続するためのオプション（ --source-server ）です。 注意、操作は、データベースクラスターを所有するユーザー（デフォルトではpostgres）の下で実行する必要があります。

 $ pg_rewind -D /var/lib/pgsql/9.4/data/ --source-server="host=192.168.122.12 port=5432 user=postgres" The servers diverged at WAL position 0/48D9580 on timeline 1. Rewinding from Last common checkpoint at 0/3000860 on timeline 1 error reading xlog record: record with zero length at 0/48D9620 Done!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、巻き戻しが行われます（エラーという単語に驚かないでください。これは定期的なチェックです）。 次に、postrgesql.confファイルとrecovery.doneファイルに注意する必要があります。これらは新しいウィザードからコピーされ、サーバー固有の設定（listen_addresses、ポートなどのIPアドレスまたはポート番号など）が含まれている可能性があることに注意してください。 doneの名前をrecovery.confに変更し、新しいウィザードに接続するように構成する必要があります。

 $ mv /var/lib/pgsql/9.4/data/recovery.done /var/lib/pgsql/9.4/data/recovery.conf $ vi /var/lib/pgsql/9.4/data/recovery.conf standby_mode = 'on' primary_conninfo = 'user=postgres host=192.168.122.12 port=5432' trigger_file = '/var/lib/pgsql/9.4/data/failover'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成が修正されたら、postgresを実行してサーバーログを確認します

 $ cat /var/lib/pgsql/9.4/data/pg_log/postgresql-Mon.log LOG: entering standby mode LOG: redo starts at 0/48D95B0 LOG: record with zero length at 0/61D9EE8 LOG: consistent recovery state reached at 0/61D9EE8 LOG: database system is ready to accept read only connections LOG: started streaming WAL from primary at 0/6000000 on timeline 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベースシステムが読み取り専用接続を受け入れる準備ができていることに注意してください 。これはここで最も重要な行であり、すべてがスムーズに進み、postgresが正常に起動し、接続を受け入れる準備ができていることを示します pg_stat_replicationを介して通常のツールを使用してストリーミングレプリケーションを確認するか、ウィザードでテストテーブルを作成し、スタンバイでそれらの可用性を確認できます。



以上です。 結論として、私は追加します...最初に、新しいマスターの宣言と巻き戻しの間のプロセスで、新しいマスターを記録に使用できるので、巻き戻すときにマスターをアプリケーションからの接続から分離する必要はありません。 第二に、プロジェクトはまだ若く、活発に開発中であり、私の意見では生産の準備ができていません。 だから、試してみてください...



すべてを実行する準備ができていない、または単に怠であるが、視聴したい人は、8分間の短いビデオがあり、切り替えアクションは4:20から始まります（postgresに不慣れな人は何も理解しません）。



ご清聴ありがとうございました。