PostgreSQLとPipelineDB間のレプリケーションを構成する

この記事は、PostgreSQLクラスター内のレプリケーションのタイプと問題を表面的に理解している人、およびそのようなクラスターでレプリカとしてPipelineDBストリーミングDBMSを使用することを決定した人にとって興味深いものです。



PipelineDBは、人気が高まっているストリーミングDBMSの実装の1つです。 現在、さまざまなリソースに関するさまざまなケースでのストリーミングDBMSの利点について読むことができます。 非常に簡単に、彼らの仕事の原理は、ウェブサイトwww.pipelinedb.comの「仕組み」セクションで視覚化されています。



具体的には、PipelineDBは追加機能を備えたPostgreSQLのフォークであり、集約されたデータのみを格納し、着信ストリーム（このタイプのDBMSの名前）からその場でデルタを計算できます。 このデータは、連続ビューと呼ばれる特別なPipelineDBオブジェクトに保存されます。 最も単純な場合のストリーム自体は、同じデータベースに格納されている通常のテーブルから形成されます。 このツールを使用すると、レポートシステムのデータを準備する際にETLレイヤーを作成および維持する必要がなくなり、多くの時間と神経を節約できます。 しかし、私はあなたがこれを読んでいるので、あなたはすでにこのことについて何かを知っていると信じています。



PostgreSQL DBMSバージョン9.4以降が既に製品環境で実行されているケースを見てみましょう。複数の重いSELECTクエリからメインデータベースを解放するために、そのリアルタイム（またはほぼリアルタイム）レプリカを取得する必要があります。たとえば、レポートシステム、DWH、またはデータマートなどです。 また、問題を調査した後、ストリーミングDBMSがまさにそのようなタスクに非常に適しているものを決定できます。



しかし、ここに問題があります-どのレプリケーションメカニズムを使用する必要がありますか？ この問題をさらに調査した結果、PostgreSQLバージョン9.0で登場し、絶えず進化している素晴らしい組み込みPostgreSQL非同期（物理）レプリケーションメカニズムは、その制限のために適切ではないという結論に達しました。



a）マスターとレプリカはPostgreSQLの同じメジャーバージョンを持ち、可能であれば同一のハードウェアでスピンする必要があります

b）レプリカは読み取り専用である「ホットスタンバイ」モードで動作します

c）物理レプリケーションを使用する場合、完全な「1対1」のマスターレプリカしか持てません。



私の場合、最初の制限により、PipelineDBでPostgre 9.6を実行しているマスターサーバーのレプリカを作成できません。 私が使用したPipelineDBの最新バージョンが使用されていたPostgreのバージョンは、「スピンオフ」された9.5のみでした。 マスターがPostgre 9.5を実行している場合、このようなトリックを試すことができますが、マスターサーバーがPipelineDBを本格的な同等のPostgreSQLとして認識しない可能性が高くなります-物理レプリケーションメカニズムはこの点で非常に気まぐれです。



2番目の制限はより重要です。 すでにわかったように、PipelineDBはそのデータをデータベースに書き込みます。 少なくとも、これらは連続的なビューであり、私たちは彼を混乱させました。 しかし、2番目の制限により、レプリカはマスターデータベースの完全なコピー（1対1）にしか書き込みできません。 まったく私たちに合わないもの。



したがって、物理的な複製は私たちに合わないので、論理的な複製に目を向ける必要があることを理解しています。 その欠陥がないわけではありませんが、これらの2つの制限を完全に排除します。



a）論理複製により、マスターとスレーブでさまざまなバージョンのDBMSを操作できます

b）論理レプリケーションにより、マスターのすべてのデータではなく、必要なデータのみのレプリカを1対1で作成でき、書き込みスレーブをブロックしません



そして、私たちの前に可能性の海が広がります。



論理複製を作成するためのさまざまなツールのリストと、複製自体のさまざまな方法に初めて慣れると、最初に生じる欲求は、アクティビティの種類を変更する欲求です。 しかし、最初の衝撃は過ぎ去り、私たちはこの海からの夢の道具のポストにふさわしい候補者を見つけ始めます。

postgresql.leopard.in.ua/html/#replicationを含む、問題とレプリケーションおよびそのユーティリティが十分に検討されている優れた記事

これに使用される最も人気のあるツールの1つは、slony（トリガーベース）とpgpool / pgpool-II（ミドルウェア）です。



非常に有名で人気のあるSlonyユーティリティバージョン2.2.5を使用してこの問題を解決しようとすると、2週間で成功しませんでした-概念実証とマスターとレプリカの目的で同じバージョンのPostgreSQLを実行していても。 slonyデーモンは、セグメンテーションフォールトのために、起動時にすぐに起動し、すぐに再起動することを望みませんでした。その原因は見つかりませんでした。 そして、サードパーティ製ソフトウェアのセグメンテーション違反の原因を探すことは恩知らずです。 さらに、ソースコードからこのユーティリティをコンパイルするとき、およびネイティブのAlpine Linuxリポジトリからインストールするときに、同じ状況が観察されました。



この実験は、次の入力データを使用して実施されました。

-ドッカーコンテナ

-マスターとスレーブの両方： Alpine Linuxのpostgre 9.6



初期条件自体が失敗を引き起こした可能性があります-DockerまたはこのLinuxディストリビューションの使用-私の場合、これらはゲームのルールでした。 また、私が使用した最新バージョンのSlony自体の不安定性に問題が隠れている可能性があることも認めています。 いずれにせよ、このソリューションは機能せず、Slonyは廃止されました。 おそらく、異なるシステム構成または異なるバージョンのSlonyで成功するでしょう。



ただし、この記事をさらに読んだ後は、この古代のユーティリティに突入したくないかもしれません。 それを忘れないでください： howfuckedismydatabase.com/postgres/slony.php



途中で2番目のpgpoolユーティリティにたどり着きませんでした。 なぜなら 、最終的に私のソリューションになったものを見つけたからです： 2ndQuadrantのpglogicalユーティリティ。



ユーティリティのドキュメントを読んで、2ndQuadrantが誰であるかを知って、すぐにこの決定を下しました。 将来的には、明らかに、このソリューションは論理レプリケーションの標準ソリューションとして、PostgreSQLの今後のバージョン10に入ることができると思われます。 そこで、pgpoolを調査のために並べて動かすことで彼と遊ぶことにしました。



概念実証段階をバイパスして、後で実稼働に送信されることになっているコンポーネント上でシステムをすぐに構築することにしました。

マスター：最初のケースと同じイメージのdockerコンテナー

備考： 別の画像の PipelineDB Dockerコンテナ。このプロジェクトの公式画像のようですが、奇妙な方法で装飾されています。 イメージは、AlpineではなくDebianディストリビューションに基づいています。



それで、pglogicalを掘り始めました。 ほぼすぐに、私はひどく失望しました。APTリポジトリでは、このユーティリティはPostgreSQLバージョン9.4、9.5、および9.6にのみ存在し、PipelineDBの臭いはしません。 ユーティリティは、PipelineDBのあるホストへのインストールを完全に拒否し、依存関係が満たされていないpostgresql-9.5を報告しました。 T.O. 素晴らしい実験は本質的に開始することなく終了しました。



しかし、PipelineDBが同じPostgreSQLであるという認識（データベースディレクトリ、構成ファイル、組み込みコマンド、およびサービスユーティリティの構造）がこのことを明確に証明しました。 そして、ちょっとしたトリックを決めました。



pglogicalユーティリティは、次のようにPipelineDBを使用してホストにインストールされます（すべてがルートの下のdockerコンテナで行われました）。



リポジトリを追加し、ユーティリティパッケージをダウンロードします。

echo "deb [arch=amd64] http://packages.2ndquadrant.com/pglogical/apt/ jessie-2ndquadrant main" > /etc/apt/sources.list.d/2ndquadrant.list wget --quiet -O - http://packages.2ndquadrant.com/pglogical/apt/AA7A6805.asc | apt-key add - apt-get update && apt-get download libpq5 postgresql-9.5-pglogical
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存関係を無視して必要なライブラリとパッケージ自体をインストールします（！）。Postgre以外にインストールするユーティリティの不本意の問題を解決します。

 dpkg -i --ignore-depends=postgresql-9.5 libpq5_9.4.10-0+deb8u1_amd64.deb dpkg -i --ignore-depends=postgresql-9.5 postgresql-9.5-pglogical_1.2.2-1jessie_amd64.deb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイル/ var / lib / dpkg / statusから依存関係エントリを削除します。これにより、さらなるapt-get操作中に、検出されない依存関係を誓わず、pglogicalの削除を提供しません。

 sed 's/, postgresql-9.5//g' /var/lib/dpkg/status > /var/lib/dpkg/status-new && \ mv /var/lib/dpkg/status /var/lib/dpkg/status.bkp && \ mv /var/lib/dpkg/status-new /var/lib/dpkg/status
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以上です！ ユーティリティは、PipelineDBとともにホストにインストールされます。 しかし、ここでも不運です-ユーティリティはpostgresqlという名前のフォルダーにインストールされ、PipelineDBは同様のフォルダー構造を持ちますが、名前はpipelinedbです。 さて、これについて気にせずに、ユーティリティファイルを既にPipelineDBの適切なフォルダーに移動してみましょう。

 mv /usr/lib/postgresql/9.5/lib/* /usr/lib/pipelinedb/lib/pipelinedb/ mv /usr/lib/postgresql/9.5/bin/* /usr/lib/pipelinedb/bin/ mv /usr/share/postgresql/9.5/extension/* /usr/lib/pipelinedb/share/pipelinedb/extension/
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以上です。 pglogicalユーティリティがインストールされたPipelineDBを備えた稼働中のサーバーがあり、使用を開始できます。



マスタースレーブクラスターの短いセットアップ（通常のPostgreSQLと同様にPipelineDBレプリカを構成します）の説明は、Postgreのドキュメントを含む百万のリソースで説明されており、ユーティリティ自体を構成する簡単な手順を実行した後、レプリケーションが機能することを確認できます。



UPD：Dockerの構成および初期化スクリプトのソースは、 https ： //github.com/akrymets/pg-replicationにあります。



ストーリーの本質と提案についてのコメントをお待ちしております。 最高のオファーは、記事の編集として実装されます。