Clever Geek Handbook

Barmanおよび同期トランザクションログ転送を使用したPostgreSQL多層バックアップ







Yandex.Moneyは、ユーザーの快適な仕事に重要な多くの情報を保存します。 プロファイル設定と罰金のペナルティもバックアップする必要があります。これは、Barman Backup＆Recovery for PostgreSQLとpg_receivexlogの束が私たちのために行うことです。







この記事では、なぜアーキテクチャがアーキテクチャになったのかについて説明し、PostgreSQLデータベースに同様のスクリプトを実装する方法についても説明します。







どうだったのか



この記事に記載されている変更の前に、データセンター（DC）のいずれかのマスターベースから支払いシステムのバックアップが削除されました。 一般的に、支払いシステムは多くの個別のサービス、ベース、およびアプリケーションで構成されています。 このすべては、データの重要性に応じて予約されています。 この記事はより実用的であるため、セキュリティ要件が高くない多くのDBMSの1つを例として考えます。ユーザープロファイル設定、翻訳履歴、認証設定などを保存します。







バックアップツールとして、柔軟で安定した製品であるBarmanを使用します。 さらに、私たちの最愛のPostgreSQLの開発に携わる人々によって作成されています。

アクティブノードからのみバックアップする場合の問題は、マスターが2番目のDCに切り替えた場合（バックアップがない場合）、最初のDCのバックアップサーバーがゆっくりと長時間ネットワークを介して新しいマスターからコピーを収集したことです。 また、ユーザー数の増加に伴い、回復中の最新のトランザクションが失われる可能性がますます懸念されています。







私たちは正しくやる



合計で、次の問題を解決します。







  1. データセンターまたはバックアップサーバーに障害が発生した場合にバックアップの可用性を確保します。







  2. マスターサーバーに障害が発生した場合のトランザクションの損失の防止。


タスクの範囲は20個のPostgreSQL 9.5サーバー（10個のマスターと10個のスレーブ）で、合計ボリュームが約3 TBの36個のデータベースにサービスを提供しました。 ただし、説明したシナリオは、重要なデータベースを持つサーバーのペアにも適しています。







バージョン2.1以降、Barman Backup＆Recoveryには、マスターだけでなくスレーブサーバー（レプリカ）からのトランザクションのフローを記録する機能があります。

新しいソリューションの一般的な概要を以下に示しますが、かなり簡単です。







各データセンターに1つのバックアップサーバーがあり、その構成は一般的です（Barmanの利点の1つ）。







設定プロセスは次のとおりです。







1.データベースサーバーに接続し、パッケージマネージャーを使用してpostgresql-9.5-pgespressoをインストールします。これは、Barman Backup＆RecoveryとPostgreSQLを統合するための拡張機能です。 Ubuntuにはすべてのコマンドが提供されていますが、他のディストリビューションでは違いがある場合があります。 







apt-get install postgresql-9.5-pgespresso


2. PostgreSQLにpg_espresso拡張機能をインストールします。 







 postgres@db1:5432 (postgres) # CREATE EXTENSION pgespresso


3.次に、Barmanがインストールされたサーバーで、db1サーバーのバックアップ設定を記述するファイルを作成する必要があります。db1.confは、 / etc / barman.d /ディレクトリーにあり、次の内容を含んでいます。 







 [db1] ssh_command = ssh postgres@db1 conninfo = host=pgdb1 user=postgres port=5432 backup_options = concurrent_backup ;         pg_espresso archiver = off ;     archive_command streaming_archiver = on ;       slot_name = barman ;


4.次に、複製スロットを作成して、ウィザードがレプリカがまだ受信していないトランザクションログを削除しないようにする必要があります。 







 $ barman receive-wal --create-slot db1


5.そして、Barmanがサーバーを認識し、そこからトランザクションログを取得することを確認します。 







 $ barman check db1


すべてのコマンドが正しく実行されると、検証コマンドの結果は次のようになります。 







 Server db1: PostgreSQL: OK superuser: OK PostgreSQL streaming: OK wal_level: OK replication slot: OK directories: OK retention policy settings: OK backup maximum age: OK (no last_backup_maximum_age provided) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 7 backups, expected at least 7) ssh: OK (PostgreSQL server) pgespresso extension: OK pg_receivexlog: OK pg_receivexlog compatible: OK receive-wal running: OK archiver errors: OK


これで、Barmanは雑誌をピックアップし、レプリカからバックアップを作成します。 ユーザープロファイル、支払い履歴、罰金の登録、認証設定などを含むすべてのPostgreSQLデータベースがバックアップに入ります。







分隊は戦闘機の損失に気づかなかった



リカバリー中にRPOをゼロにすることは非常に重要であるため、追加のメカニズム-pg_receivexlogで Barmanを保護することにしました 。 このプロセスは、データベースを備えたサーバーではなく、別のサーバーに配置され、マスターノードから別のレプリカトランザクションログリポジトリにトランザクションログのコピーを継続的に転送します。 したがって、各DCについて個別に。







このメカニズムの特徴は、トランザクションのコピーの成功に関する確認をpg_receivexlogから受信するまで、DBMSはアプリケーションがデータベースにデータを書き込むことを確認しないことです。







これがないと、次のシナリオの可能性が残ります。







  1. Innocentがセルラー通信に対して100ルーブルを支払うと仮定すると、操作は支払いシステム（PS）によって正常に実行されます。







  2. バックエンドでクラッシュが発生した直後に、トランザクションログを含むバックアップをロールバックします。







  3. しかし、転送は事故の直前に行われたため、このトランザクションはバックアップされず、イノセントのウォレット操作の履歴に反映されなくなります。


PSは支払いについて知っており、お金は失われませんが、操作自体は履歴に表示されません。 もちろん、これは不快で落胆させます。 操作は、サポートサービスを通じて手動で入力する必要があります。







次に、奇跡の同期ログ転送メカニズムを構成する方法：







1.ログコレクター用のスロットを作成します。 







 pg_receivexlog --create-slot -S pgreceiver --if-not-exists -h db1


2. PostgreSQLサーバーからログ収集サービスを実行します。 







 pg_receivexlog -S pgreceiver -d "host=db1 user=postgres application_name=logreceiver" -D /var/lib/postgresql/log/db1/ --verbose --synchronous
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 *-S:   .      ;* *-d:    ;* *-D: ,    ;* *—synchronous:     ;*


3. pg_receivexlogの起動後、トランザクションログを同期モードでディレクトリに保存しようとします。 このようなコレクターは、PostreSQLサーバーごとに1つずつ存在できます。 ただし、同期モードが機能するには、マスターノードのDBMS設定でPostgreSQL構成のパラメーターを指定する必要があります。 







 synchronous_standby_names = 'logreceiver, standby'


4.ただし、ログコレクターを備えたサーバーで障害が発生した場合、マスターノードはユーザートランザクションの処理を継続できるため、2番目のサーバーでレプリカを指定することをお勧めします。 recovery.confのレプリカで、マスターノードにアクセスできない場合にトランザクションログを取得する場所を指定する必要があります。 







 restore_command = 'scp postgres@logreceiver:/var/lib/postgresql/log/db1/%f* %p'


もちろん、ログ収集サーバーに障害が発生した場合、システム全体の速度がわずかに低下します。これは、ログをマスターと同じDCのログコレクターに送信する代わりに、確認とともに別のDCに送信する必要があるためです。 それにもかかわらず、安定性がより重要です。







要約として、この記事で説明されているスキームに従って、バックアップの時間と量について少し詳しく説明します。 上記のサーバーの完全バックアップは、Yandex.Moneyで毎日削除され、約2 TBの重量があります。バックアップサーバーの処理には5〜10時間かかります。 また、トランザクションログの永続的なバックアップは、ファイルをリポジトリに移動することにより実行されます。







More articles:


All Articles