pg_probackupに精通していること。第二部

pg_probackup ツールについては引き続き理解していきます。



では最初の部分、我々は、インスタンスを作成および設定、pg_probackupを設置し、2つのバックアップ取った- DELTAモードでフルと増分を、インスタンスの設定を表示および変更する方法を説明しました。バックアップのリストを取得し、クラスターをバックアップして最後のバックアップ操作の結果を監視システムに送信するスクリプト（bkp_base.sh）を作成しました。今日は、同様に興味深いタスクに取り組みます。

問題2

与えられたもの： 2つのサーバーがあり、最初のサーバーにはデータベース（hostname srv_db1、user postgres）があり、2番目のサーバーにはバックアップ（hostname srv_bkp、user backup_user）が格納されます。ただし、同じサーバーへのバックアップに加えて、過去3日以内に任意の時点（ポイントインタイムリカバリ）に復元できるように、事前記録ログのコピーを保存します。



解決策：



選択した時点（復元ポイント）に復元できるようにするには、復元ポイントの前にバックアップを作成し、バックアップが開始された瞬間から復元ポイントまでのすべてのWALファイルを作成する必要があります。



すでにバックアップがありますが、srv_bkpでWALアーカイブを構成する必要があります。

postgresユーザーを使用してsrv_db1に接続し、次のコマンドを実行します。

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

〜/ .ssh / autorized_keysファイルをsrv_bkpに変更してみましょう。

command="pg_probackup-12 agent" ssh-rsa AAAA....

srv_db1に戻り、アーカイブモード（archive_mode）を有効にして、archive_commandパラメーターを構成する必要があります。これには、完全なWALセグメントをバックアップするコマンドが含まれています。

psql -c 'show archive_mode'

オフに戻った場合は、オンに変更します

psql -c 'alter system set archive_mode = on'

変更を適用するには、PostgreSQLを再起動する必要がありますが、今のところ、このアクションを延期し、もう1つのパラメーターを構成します。



WALファイルのストリームが十分に大きい場合、バックアップサーバーのスペースがすぐに不足する可能性があるため、archive_command行に--compressオプションを挿入すると、ログファイルが圧縮されてからsrv_bkpに送信されます。また、リカバリ中にこれらのファイルを個別に解凍する必要があるという事実を心配する必要はありません。pg_probackupは圧縮ファイルで機能します。

alter system set archive_command = 'pg_probackup-12 archive-push -B /home/backup_user/backup_db --instance=db1 --wal-file-path=%p --wal-file-name=%f --remote-host=srv_bkp --remote-user=backup_user --compress';

これで再起動できます。



最初のタスクで行ったことは、オフラインバックアップと呼ばれます。このようなコピーには、復元に必要なすべてのWALファイルが含まれているため、このように呼ばれます。現在のタスクでは、オフラインコピーからアーカイブコピーに移行しています。このようなコピーには必要なログが含まれていませんが、必要なすべてのWALファイルをアーカイブに保存するため、これは問題ではありません。バックアップコピーから復元する場合、WALファイルはアーカイブからコピーされます。



検討中の状況では、オフラインバックアップ（ストリームモードで作成）からアーカイブ（アーカイブモード）に切り替えているため、アーカイブモードがまだ有効になっていないときにコピーを作成し、その後、一部のWALセグメントがすでに表示されている場合があります。削除されました。これは、アーカイブモードに切り替えた後の最初のバックアップをPAGEモードで作成できないことを意味します。過去と現在のコピーの間のアーカイブ内のWALのセグメントが完全でない可能性があります。



最初のタスクで作成したスクリプトを使用してこれを実行しましょう。

./bkp_base.sh DELTA

次に、PAGEモードで最初のバックアップを作成します

./bkp_base.sh PAGE

PAGE、DELTA、PTRACKの3つのインクリメンタルモードが利用可能であることを思い出してください。それらは、変更されたページに関する必要な情報を取得する方法が互いに異なります。

• DELTA — ,
• PAGE — WAL , ,
• PTRACK — - Block Change Tracking Oracle — , . ( ..). , .

そして今、バックアップコピーがそれから回復できるようにするために、バックアップ作成中に作成されたWALファイルが必要であると考えてみましょう。それら。 30分間の増分バックアップを作成し、この30分間に10 GBのWALが作成された場合、これらの10 GBのみが必要であるため、一貫して回復できます。他のすべてのWALファイルは、ポイントインタイムリカバリの目的でのみ必要です。



タスクは、過去3日間の任意の時点で回復できるようにしたいことを示しました。つまり、この期間のすべてのWALを保存する必要があります。さらに、以前のバックアップから復元するために必要なすべてのWALを保存する必要がありますが、他のすべてのWALファイルを保存する必要はありません。



また、findコマンドを使用して廃止されたWALを削除し、それにmtimeと-exec rm {}を追加できる場合、特定のバックアップを一貫して復元するために必要なWALセグメントを決定することは簡単な作業ではありません。開発者がこれについて考え、バックアップで計算されたWALストレージの深さを設定できる--wal-depthパラメーターを追加したのは良いことです。



これは、次のように概略的に説明できます。







現在は土曜日の真ん中のどこかにあることに注意してください。つまり、3日より古いバックアップを復元するために必要のないすべてのWALファイルを削除できます（グラフの茶色）。まだ必要なWALは、黄色で強調表示されています。ここで論理的な疑問が生じる可能性がありますが、結局のところ、すでに土曜日の真ん中です。つまり、水曜日に作成された朝のログの一部は不要になり、削除できます。はい、そうです。少なくとも1分ごとに余分なWALの削除を構成できますが、この記事では、バックアップの作成とともにログを削除するため、ログは保持ポリシーに該当しなくなりましたが、次のバックアップを作成するときに削除されます。 ..。



db1インスタンスの設定を変更します-WALファイルの有効期間を追加します

pg_probackup set-config --instance db1 --wal-depth=3

設定が適用されていることを確認しましょう。

pg_probackup show-config --instance=db1 | grep wal-depth

オフラインバックアップからアーカイブバックアップに移行しているため 、bkp_base.shスクリプトのバックアップコマンドに--delete-walフラグを追加し、-streamキーも削除します。

pg_probackup backup --instance=db1 -j 2 --progress -b $1 --compress --delete-expired --delete-wal

現時点では、別のサーバーでのアーカイブバックアップの作成を構成しています。また、ログファイルがここに追加されます。これにより、特定のバックアップにリカバリを使用するだけでなく、ポイントインタイムリカバリ（特定の時点へのリカバリ）を実行する機会が得られます。



WALファイルのアーカイブができたので、PAGEモードを使用して増分バックアップを作成できます。このモードでは、前のバックアップに対する変更は、データファイルではなく、前のバックアップ以降に累積されたWALによって計算されます。



PS教育目的のみ！srv_db1サーバーのデータベースにテーブルを作成しましょう。

psql -c 'create table timing(time_now timestamp with time zone)'

次に、次の行をcrontabに書き込みます。

* * * * * psql -c 'insert into timing(select now())'

毎分、現在の時刻に関する情報がデータベースに記録されます。この情報は、ある時点に復元するときに役立ちます。

問題3

与えられたもの：



2つのサーバーがあり、最初のサーバーにはデータベース（hostname srv_db1、user postgres）があり、2番目のサーバーにはアーカイブされたバックアップとWALファイル（hostname srv_bkp、user backup_user）が格納されています。別のサーバーsrv_db2が環境（ユーザーpostgres）に表示され、クラスターのレプリカをデプロイし、レプリカからバックアップを取得するようにpg_probackupを再構成する必要があります。



決定：



インターネットには、PostgreSQLでレプリカを作成する方法の説明がたくさんあります。検索エンジンに「PostgreSQLでレプリカを作成する」をドライブするだけです。選択してください。ドキュメント、記事、さらにはビデオチュートリアルもあります。そして、これらの方法はすべて優れていますが、通常、すでにバックアップがあることを考慮していません。バックアップを使用してレプリカを作成したいので、マスターから読み取り負荷を取り除きます。つまり、本番サーバーは、その隣にレプリカが作成されていることを認識しません（もちろん、これには予約が必要です。ここでは、レプリケーションスロットを作成してアクセス権を設定する必要がありますが、レプリカを作成している間、マスターに追加の負荷はかかりません。ならないだろう）。



srv_bkpサーバーとsrv_db2サーバー間のキーによるアクセスを設定し、PostgreSQLとpg_probackupをsrv_db2にインストールします（最初のタスクでPostgreSQLのインストール以外のすべてを実行しましたが、DBMSのインストールについて質問がある場合は、こちらをご覧ください）。



srv_db2に移動します

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

srv_bkpに移動します

ssh-copy-id postgres@srv_db2

内部パラノイドをオンにして、〜/ .ssh / autorized_keysを編集しましょう-挿入

command="pg_probackup-12 agent"

新しいキーの前。



WALファイルの使用は、バックアップからの復元よりもはるかに遅いため、別の増分バックアップを作成しましょう。backup_userを使用してsrv_bkpサーバーに接続し、次のコマンドを実行します。

pg_probackup backup --instance=db1 -j 2 --progress -b PAGE --compress

作成したスクリプトを使用しなかったのはなぜですか？実際、以前にスクリプトに--delete-walオプションを追加しました。つまり、このバックアップを作成した後、3日前の時点に復元することはできません。ただし、このバックアップを残した場合、スクリプトの実行によって作成された次のバックアップは、過去2日間だけWALを残します。つまり、このバックアップから回復した後、削除するのが理にかなっています。



私たちは回復します：

time pg_probackup restore --instance=db1 -D /var/lib/pgsql/12/data -j 2 --restore-as-replica --progress --remote-proto=ssh --remote-host=srv_db2 --archive-host=srv_bkp --archive-user=backup_user --log-level-console=log --log-level-file=verbose --log-filename=restore_rep.log

/ var / lib / pgsql / 12 / dataディレクトリは空である必要があります。さらに、srv_db1サーバーでは、pg_hba.confに変更を加える必要があります。レプリケーションプロトコルを使用してsrv_db2サーバーからのアクセスを許可します。

host    replication     all             srv_db2                 md5

構成を読み直します。

psql -c 'select pg_reload_conf()'

タイプミスの確認：

psql -c 'select * from pg_hba_file_rules'

srv_db2にファイル〜/ .pgpassを作成します。このファイルでは、srv_db1で接続権限を指定しますが、今回はレプリケーションベースを使用してPostgreSQLを起動します。

srv_db1:5432:replication:backup:Strong_PWD

そして、その権利を600に変更しましょう。

chmod 600 ~/.pgpass

srv_db2でクラスターを開始します。



すべてがうまく機能することを確認しましょう。これには、次の可能性を使用します。



その中のレプリカログファイルを調べます。最後のどこかに、次の行が表示されます。

Database system is ready to accept read only connections

psql -c 'select pg_is_in_recovery()' 

tを返す必要があり



ます次に、ウィザードでプレートt1を作成しましょう。

srv_db1: psql -c 'create table t1()'

レプリカに表示されているか確認してみましょう。

srv_db2: psql -c '\d'

プレートが所定の位置にあり、複製が機能しています。マスターのプレートを取り外します。

srv_db1: psql -c 'drop table t1'

もちろん、実際のデータベースでは、マスターにレプリケーションスロットを作成し、このスロットを介してマスターに送信されるようにレプリカを構成する必要がありますが、この記事のトピックはレプリカではなくバックアップなので、続けましょう。



したがって、レプリカは機能します。必要に応じて、レプリカに切り替えることができますが、自分自身に質問してみましょう。もっとうまくできるでしょうか。

もちろんできます。マスターから読み取り負荷を取り除き、それをレプリカに転送できるのに、なぜマスターからバックアップを取る必要があるのですか？



注意！REPLIC LACK MONITORINGは監視する必要があります。そうしないと、REPLICAが遅れていることを知らず、REPLICALAGからのバックアップを続行する可能性があります。



そうしよう！



srv_db1サーバーとsrv_db2サーバーのクラスター設定を変更します。

alter system set archive_timeout=180;
select pg_reload_conf();

srv_bkpに移動し、remote-hostパラメーターの値を変更します。

pg_probackup set-config --instance db1 --remote-host=srv_db2

srv_bkpサーバーの.pgpassに変更を加えます-srv_db2サーバーに接続文字列を追加します。

srv_db2:5432:replication:backup:Strong_PWD
srv_db2:5432:backupdb:backup:Strong_PWD

そして、別のバックアップを取ってみましょう。

srv_bkp: ./bkp_base.sh PAGE

バックアップが機能していることがわかります。



問題は解決しました！



次のパートでは、バックアップからの復元について説明します。さまざまな回復オプションを検討し、特定のバックアップに復元する方法を学び、ある時点で、部分的および増分的な復元について理解します。