PostgreSQLでデータを失わない方法

PostgreSQLには、データバックアップのためのいくつかのオプションがあります。 それらのすべては、Habrを含めて、すでに複数回話されています。 しかし、基本的にはメソッドの技術的特徴について語っています。 すべてのデータを保存し、危機的な状況で死んだ神経細胞の数を減らすのに役立つ効果的なシステムですべての方法を組み合わせて、一般的なバックアップ戦略についてお話したいと思います。

入力:PostgreSQL 9.2サーバー、ベースサイズ> 100Gb。



バックアップオプション


マニュアルから次のように、データのバックアップには3つの方法があります。



それらはすべて独自の特性を持っているため、これらすべての方法を使用します。



ストリーミング複製


ストリーミングレプリケーションの構成については、 こちらこちらの記事で詳しく説明しています 。 この複製の意味は、メインサーバーがクラッシュした場合、スレーブをすぐにウィザードにして作業することができるということです。 データベースの完全なコピーはスレーブ上にあります。

ストリーミングレプリケーションでは、WALファイルは非常に重要です。 これらは、ウィザードにこれ以上残っていない場合に、スレーブが欠落データをプルアップするファイルです。 したがって、これらのWALファイルをより長く保存する必要があります。 これらのファイルは8日間保存されます。

WALファイルを含むディレクトリは、マスター(書き込み用)とスレーブ(読み取り用)の両方にアクセスできる必要があります。 これを確実にするために、両方のサーバーにマウントされたglusterFSに基づいて共通のリポジトリを作成しました。 したがって、第一に、より高い信頼性が達成されます(ウィザードがクラッシュした場合、スレーブがwalファイルを使用できるようになります)。

結論:ストリーミングレプリケーションは、メインサーバーの障害から保護しますが、データはほとんど失われません。



データベースファイルをコピーする


サーバーのクラッシュを見つけました。今度は、何らかの理由でテーブル内のデータ、テーブル自体、またはバスのデータベースが削除された場合のヒューマンファクターに対処します。 この場合、バックアップからデータを復元する必要があります。 アプリケーションをテストするには、データベースの別のコピーが必要になる場合があります。 このようなコピーは2つの方法で作成できます-データベースをダンプするか、データディレクトリ全体をコピーします。 長い間、最初のオプション-ファイルへのデータベースダンプを使用していました。 しかし、ダンプには大きなマイナスがあります- プロセスはテーブルをブロックし、他のプロセスはそれらを使用できなくなりますUPD :pg_dumpはテーブルをブロックしません。ただし、データベースに大きな負荷をかけます)。 大規模なデータベースの場合、これは重要です。

ここで、データベースをバックアップするために、pg_basebackupユーティリティを使用します。これは基本的にすべてのデータベースファイルを1つの大きなアーカイブにコピーします。

週に4回、月に6回のコピーを保持しています。 コピーは同じGlusterFSストレージに保存されます。 自給自足の方法でコピーを作成します。つまり、追加のWALファイルをダウンロードする必要なく、展開後すぐに動作します。 そのため、たとえば3か月前など、ベースを簡単に展開できます。

pg_basebackupユーティリティはスレーブサーバーで(特定の条件下で)実行できるため、バックアップを作成してもウィザードがまったくロードされないことは注目に値します。

pg_basebackupがスレーブで機能するためには、WALファイルの保存を有効にする必要があります。これを行うには、postgresql.confでオプションを設定します:

wal_level = hot_standby wal_keep_segments = 1000
      
      





1000は、postgreSQLがディスクに保存するwalファイルの数です。 このパラメーターを増減する必要がある場合があります。 実際、pg_basebackupはデータベースの内容を単にアーカイブするだけですが、アーカイブ中に一部のデータはすでに変更されており、PostgreSQLは復元中にWALファイルからそれを引き出します。 これを行うために、pg_basebackupはすべての既存のWALファイルをアーカイブにアーカイブします。 したがって、すべてが成功するためには、pg_basebackupが動作を開始してから完了するまですべてのWALファイルが利用可能であることが必要です。 目的のWALファイルが削除されると、pg_basebackupは失敗します。 必要なwal_keep_segmentsの数は、経験的に決定できます。

データベースのバックアップコピーを作成するには、次のパラメーターを指定してpg_basebackupを実行します。

 /usr/bin/pg_basebackup -U postgres -D /tmp/pg_backup -Ft -z -Xf
      
      





-Fは、すべてを1つのファイルに保存する必要があることを示し、-z-アーカイブする必要があるもの、-Xf-アーカイブにWALファイルを含めます。 WALファイルを含めなくてもバックアップは機能しますが、Postgresを復元する場合は、欠落しているWALファイルを提供する必要があります。



次のスクリプトを使用して、土曜日に冠をバックアップします。

 #!/bin/bash mkdir /tmp/pg_backup /usr/bin/pg_basebackup -U postgres -D /tmp/pg_backup -Ft -z -Xf WEEK=$(date +"%V") MONTH=$(date +"%b") let "INDEX = WEEK % 5" test -e /collector/db-backup/base.${INDEX}.tar.gz && rm /collector/db-backup/base.${INDEX}.tar.gz cp /tmp/pg_backup/base.tar.gz /collector/db-backup/base.${INDEX}.tar.gz test -e /collector/db-backup/base.${MONTH}.tar.gz && rm /collector/db-backup/base.${MONTH}.tar.gz ln /collector/db-backup/base.${INDEX}.tar.gz /collector/db-backup/base.${MONTH}.tar.gz test -e /collector/db-backup/base.last.tar.gz && rm /collector/db-backup/base.last.tar.gz ln /collector/db-backup/base.${INDEX}.tar.gz /collector/db-backup/base.last.tar.gz rm -r /tmp/pg_backup
      
      





したがって、サフィックスが3つ付いたファイルが作成されます。週番号、月の名前、最後のサービスが含まれます。

コピーからデータベースを復元するには、PostgreSQLを停止し、データディレクトリから古いデータを削除(または転送)し、そこでアーカイブの内容を解凍してサーバーを起動する必要があります。 興味深い点が1つあります。 スレーブでpg_basebackupを実行したため、recovery.confファイルはデータとともに解凍されます。 したがって、データを可能な限り最後の状態に復元したい場合は、このファイルを残す必要があります。この場合、サーバーの起動後、Postgresはrecovery.confで指定された場所からWALファイルのプルを開始します。 最後の週単位のバックアップを取得すると、必要なすべてのWALファイルがあり(8日間保存するため)、データベースを最後の通常の状態に復元できます。

バックアップの作成時にデータが必要な場合は、データベースを起動する前に、recovery.confファイルを削除する必要があります。



また、テスト目的でバックアップコピーを使用します; 1つには、バックアップコピーの作成の正確性もチェックされます。

base.last.tar.gzという名前は、テストデータベースに最後のコピーを復元するために使用されます。 次のスクリプトを使用して、テストデータベースが毎晩復元されます。

 #!/bin/bash /etc/init.d/postgresql stop rm -r /data/* tar -zxf /collector/db-backup/base.last.tar.gz -C /data/ rm /data/recovery.conf /etc/init.d/postgresql start
      
      







結論:ファイルレベルでデータベースをコピーすると、ソフトウェアのクラッシュや人的エラーから保護されます。 バックアップからデータベースを復元すると、最新のデータが失われます。



SQLダンプ


長い間、大規模なデータベースの完全なSQLダンプを行っていませんが、変更されたテーブル、1テーブル-1ファイルをダンプしています。 これにより、1つのテーブルのみが破損している場合に非常に迅速にデータを復元できます。バックアップからデータベース全体を解凍する必要はありません。

PostgreSQLはテーブルの変更数に関する統計を提供し、毎晩どのテーブルが変更されたかを調べてダンプします。 次のような統計情報を確認します。

select schemaname,relname,n_tup_ins+n_tup_upd+n_tup_del from pg_stat_user_tables ;





結論:SQLダンプは、軽微なエラーの回復に役立ちます。 この場合、データはダンプ時に関連します。



結論として


ご覧のように、データ損失から可能な限り自分自身を守るために、PostgreSQLのすべての機能を使用することができます。特に難しくありません。



All Articles