序章
PostgreSQL は、ACIDトランザクションをサポートする広く使用されているリレーショナルデータベースです。 頭字語ACIDは、原子性、一貫性、分離、および耐久性を表します。 これらは、データベース内のデータの永続性と有効性を確保するためにPostgreSQLがサポートするデータベーストランザクションの4つの主要なプロパティです。
PostgreSQLがACIDプロパティを維持するために使用する1つの方法は、先行書き込みログ(WAL)です。 PostgreSQLは、データベースクラスタのデータファイルに変更を書き込む前に、まずデータベース上のすべてのトランザクションをWALログファイルに記録します。
継続的なアーカイブでは、WALファイルがセカンダリストレージにコピーされます。これにはいくつかの利点があります。 たとえば、セカンダリデータベースクラスタは、レプリケーションの目的でアーカイブされたWALファイルを使用できますが、ファイルを使用してポイントインタイムリカバリ(PITR)を実行することもできます。 つまり、事故が発生した場合に、ファイルを使用してデータベースクラスターを望ましいポイントにロールバックできます。
このチュートリアルでは、Ubuntu20.04でPostgreSQL12クラスターを使用して継続的なアーカイブを設定し、クラスターでPITRを実行します。
前提条件
このチュートリアルを完了するには、次のものが必要です。
-
Ubuntu20.04を実行している単一のマシン。 初期サーバーセットアップガイドでは、適切な権限を持つ非ルートユーザーを含むサーバーのセットアップについて説明します。
-
マシン上で実行されているPostgreSQL12。 Ubuntu20.04にPostgreSQLをインストールして使用する方法チュートリアルのステップ1は、Ubuntu20.04へのPostgreSQL12のインストールについて説明しています。
ステップ1—データベースクラスターでの継続的なアーカイブの構成
この最初のステップでは、クラスターのデータディレクトリとは別のディレクトリにクラスターのWALファイルをアーカイブするようにPostgreSQL12クラスターを構成する必要があります。 これを行うには、最初にWALファイルをアーカイブするための新しいディレクトリをどこかに作成する必要があります。
次のように新しいディレクトリを作成します。
- mkdir database_archive
次に、デフォルトのPostgreSQLユーザーを指定する必要があります。 postgres
、このディレクトリへの書き込み権限。 これは、を使用してディレクトリの所有権を変更することで実現できます。 chown
指図:
- sudo chown postgres:postgres database_archive
クラスタがWALファイルをアーカイブするためのディレクトリを設定したので、アーカイブを有効にする必要があります。 postgresql.conf
構成ファイルは、 /etc/postgresql/12/main/
デフォルトではディレクトリ。
テキストエディタで設定ファイルを開きます。
- sudo nano /etc/postgresql/12/main/postgresql.conf
ファイルを開いたら、次の行のコメントを解除します archive_mode
を削除することにより、その変数 #
行頭から。 また、の値を変更します archive_mode
に on
次のように:
. . .
archive_mode = on
. . .
また、クラスターがファイルをアーカイブするために使用するコマンドも指定します。 PostgreSQLは、このチュートリアルで機能するアーカイブコマンドを提供します。これについては、公式のPostgreSQLドキュメントで読むことができます。 コメントを外す archive_command
変数を追加し、次のコマンドを追加します。
. . .
archive_command = 'test ! -f /path/to/database_archive/%f && cp %p /path/to/database_archive/%f'
. . .
ここでのarchiveコマンドは、最初にWALファイルがアーカイブにすでに存在するかどうかを確認し、存在しない場合はWALファイルをアーカイブにコピーします。
交換してください /path/to/database_archive
へのパスで database_archive
以前に作成したディレクトリ。 たとえば、これをホームディレクトリに作成した場合: ~/database_archive
.
最後に、を構成する必要があります wal_level
変数。 wal_level
PostgreSQLがログに書き込む情報の量を指示します。 継続的なアーカイブの場合、これは少なくともレプリカに設定する必要があります。
. . .
#wal_level = replica
. . .
これはすでにPostgreSQL12のデフォルト値であるため、変更する必要はありませんが、この変数を変更する場合は覚えておく必要があります。
これで、ファイルを保存して終了できます。
データベースクラスター構成ファイルへの変更を実装するには、次のようにクラスターを再起動する必要があります。
- sudo systemctl restart postgresql@12-main
PostgreSQLが正常に再起動すると、クラスターはすべてのWALファイルがいっぱいになるとアーカイブします。 デフォルトでは、各WALファイルは16MBです。
トランザクションをすぐにアーカイブする必要がある場合は、クラスターで次のコマンドを実行することにより、データベースクラスターに現在のWALファイルを変更してアーカイブさせることができます。
- sudo -u postgres psql -c "SELECT pg_switch_wal();"
データベースクラスタがWALファイルをアーカイブに正常にコピーすると、データベースクラスタのデータファイルの物理バックアップを実行できるようになります。
ステップ2—PostgreSQLクラスターの物理バックアップを実行する
最悪の事態が発生した場合にデータ損失を軽減するために、データベースの定期的なバックアップを取ることが重要です。 PostgreSQLでは、データベースクラスターの論理バックアップと物理バックアップの両方を作成できます。 ただし、PITRの場合は、データベースクラスターの物理バックアップを作成する必要があります。 つまり、PostgreSQLのデータディレクトリにあるすべてのデータベースのファイルのコピーを作成する必要があります。 デフォルトでは、PostgreSQL12のデータディレクトリは /var/lib/postgresql/12/main/
.
注:クラスターで次のコマンドを実行して、データディレクトリの場所を見つけることもできます。
- sudo -u postgres psql -c "SHOW data_directory;"
前の手順で、ディレクトリを作成しました。 database_archive
、アーカイブされたすべてのWALファイルを保存します。 このステップでは、という別のディレクトリを作成する必要があります。 database_backup
、取得する物理バックアップを保存します。
もう一度、ディレクトリを作成します。
- mkdir database_backup
ここで、 postgres
ユーザーには、所有権を変更してディレクトリに書き込む権限があります。
- sudo chown postgres:postgres database_backup
バックアップ用のディレクトリができたので、データベースクラスタのデータファイルの物理バックアップを実行する必要があります。 幸い、PostgreSQLには組み込みがあります pg_basebackup
すべてを実行するコマンド。 次のようにコマンドを実行します postgres
ユーザー:
- sudo -u postgres pg_basebackup -D /path/to/database_backup
交換 /path/to/
ディレクトリへのパスを指定します。
このデータベースクラスターの物理バックアップを使用すると、クラスターでポイントインタイムリカバリを実行できるようになります。
ステップ3—データベースクラスタでポイントインタイムリカバリを実行する
データベースの物理バックアップが少なくとも1つあり、WALファイルをアーカイブしているので、データベースを以前の状態にロールバックする必要がある場合は、PITRを実行できます。
まず、データベースがまだ実行中の場合は、データベースをシャットダウンする必要があります。 これを行うには、 systemctl stop
指図:
- sudo systemctl stop postgresql@12-main
データベースが実行されなくなったら、PostgreSQLのデータディレクトリにあるすべてのファイルを削除する必要があります。 しかし、最初に、あなたは移動する必要があります pg_wal
ディレクトリを別の場所に移動します。これには、リカバリに重要なアーカイブされていないWALファイルが含まれている可能性があります。 使用 mv
移動するコマンド pg_wal
次のようなディレクトリ:
- sudo mv /var/lib/postgresql/12/main/pg_wal ~/
今、あなたは削除することができます /var/lib/postgresql/12/main
ディレクトリを完全に作成し、次のように再作成します。
- sudo rm -rf /var/lib/postgresql/12/main
に続く:
- sudo mkdir /var/lib/postgresql/12/main
ここで、前の手順で作成した物理バックアップから新しい空のデータディレクトリにすべてのファイルをコピーする必要があります。 あなたはこれを行うことができます cp
:
- sudo cp -a /path/to/database_backup/. /var/lib/postgresql/12/main/
また、データディレクトリに postgres
所有者としてのユーザーと適切な権限。 次のコマンドを実行して、所有者を変更します。
- sudo chown postgres:postgres /var/lib/postgresql/12/main
そして、権限を更新します。
- sudo chmod 700 /var/lib/postgresql/12/main
のWALファイル pg_wal
物理バックアップからコピーされたディレクトリは古く、役に立たない。 それらをWALファイルに置き換える必要があります pg_wal
一部のファイルはサーバーを停止する前にアーカイブされていない可能性があるため、PostgreSQLのデータディレクトリを空にする前にコピーしたディレクトリ。
を削除します pg_wal
のファイル /var/lib/postgresql/12/main
次のようなディレクトリ:
- sudo rm -rf /var/lib/postgresql/12/main/pg_wal
次に、からファイルをコピーします pg_wal
データディレクトリをクリアする前に保存したディレクトリ:
- sudo cp -a ~/pg_wal /var/lib/postgresql/12/main/pg_wal
データディレクトリが正しく復元されたら、データベースサーバーがアーカイブされたWALファイルを正しく回復するように回復設定を構成する必要があります。 リカバリ設定は、 postgresql.conf
の構成ファイル /etc/postgresql/12/main/
ディレクトリ。
構成ファイルを開きます。
- sudo nano /etc/postgresql/12/main/postgresql.conf
ファイルを開いたら、 restore_command
変数を削除し、 #
行頭からの文字。 あなたがしたように archive_command
最初のステップでは、PostgreSQLがWALファイルを回復する方法を指定する必要があります。 以来 archive
コマンドはファイルをアーカイブにコピーするだけです。 restore
コマンドはファイルをコピーして戻します。 The restore_command
変数は次のようになります。
. . .
restore_command = 'cp /path/to/database_archive/%f %p'
. . .
交換することを忘れないでください /path/to/database_archive/
アーカイブディレクトリへのパスを指定します。
次に、リカバリターゲットを指定するオプションがあります。 これは、データベースクラスタがリカバリモードを終了する前にリカバリを試みるポイントです。 リカバリターゲットには、タイムスタンプ、トランザクションID、ログシーケンス番号、で作成された復元ポイントの名前を指定できます。 pg_create_restore_point()
コマンド、またはデータベースが一貫性のある状態に達したときはいつでも。 リカバリターゲットが指定されていない場合、データベースクラスタはアーカイブ内のWALファイルのログ全体を読み取ります。
のオプションの完全なリストについては recovery_target
変数については、PostgreSQLの公式ドキュメントを参照してください。
注:リカバリターゲットは、使用している物理バックアップが作成された後の時点である必要があります。 以前のポイントに戻る必要がある場合は、データベースの以前のバックアップを使用する必要があります。
設定したら restore_command
と recovery_target
、ファイルを保存して終了します。
データベースクラスタを再起動する前に、リカバリモードで起動する必要があることをPostgreSQLに通知する必要があります。 これを実現するには、クラスターのデータディレクトリに空のファイルを作成します。 recovery.signal
. ディレクトリに空のファイルを作成するには、 touch
指図:
- sudo touch /var/lib/postgresql/12/main/recovery.signal
これで、次のコマンドを実行してデータベースクラスタを再起動できます。
- sudo systemctl start postgresql@12-main
データベースが正常に起動すると、リカバリモードになります。 データベースクラスタがリカバリターゲットに到達すると、データベースクラスタは削除されます recovery.signal
ファイル。
データベースクラスターを目的の状態に正常に回復したので、通常のデータベース操作を開始できます。 別の時点に回復したい場合は、この手順を繰り返すことができます。
結論
このチュートリアルでは、PostgreSQL 12データベースクラスターをセットアップしてWALファイルをアーカイブしてから、アーカイブされたWALファイルを使用してポイントインタイムリカバリを実行しました。 事故が発生した場合に、データベースクラスターを望ましい状態にロールバックできるようになりました。
継続的なアーカイブとポイントインタイムリカバリの詳細については、docsをご覧ください。
PostgreSQLのその他のチュートリアルについては、PostgreSQLトピックページをご覧ください。