🥇wal-g PostgreSQL バックアップシステムのご紹介

WAL-G は、PostgreSQL をクラウドにバックアップするためのシンプルかつ効果的なツールです。主な機能の点では、人気のあるツールの後継です。ウォーリー、ただし Go で書き直されました。しかし、WAL-G にはデルタコピーという重要な新機能が XNUMX つあります。デルタコピー WAL-G 以前のバックアップバージョン以降に変更されたファイルのページを保存します。 WAL-G は、バックアップを並列化するための非常に多くのテクノロジを実装しています。 WAL-G は WAL-E よりもはるかに高速です。

wal-g の仕組みの詳細については、次の記事を参照してください。バックアップをオーバークロックします。ヤンデックスの講義

S3 ストレージプロトコルは、データを保存するために普及しています。 S3 の利点の XNUMX つは、API 経由でアクセスできることです。これにより、ストレージ内の情報の更新は権限のある人のみが行う一方で、パブリック読み取りアクセスを含むストレージとの柔軟な対話を組織化できます。

S3 プロトコルを使用するパブリックおよびプライベートストレージの実装がいくつかあります。今日は、小さなストレージを整理するための人気のあるソリューションである Minio を見ていきます。

wal-g のテストには単一の PostgreSQL サーバーで十分であり、S3 の代わりに Minio が使用されます。

ミニオサーバー

ミニオのインストール

yum -y install yum-plugin-copr
yum copr enable -y lkiesow/minio
yum install -y minio

/etc/minio/minio.conf の AccessKey と SecretKey を編集します

vi /etc/minio/minio.conf

Minio の前に nginx を使用しない場合は、変更する必要があります

--address 127.0.0.1:9000

--address 0.0.0.0:9000

ミニオの発売

systemctl start minio

Minio Web インターフェースに移動します http://ip-адрес-сервера-minio:9000 そしてバケット (pg-backups など) を作成します。

DBサーバー

rpm の WAL-G は私 (Anton Patsev) によって組み立てられました。 githubの, Fedora COPR.

RPM ベースのシステムを持っていない人は、公式を使用してください。命令インストールによって。

rpm には、wal-g バイナリとともに、/etc/wal-gd/server-s3.conf ファイルから変数をインポートするスクリプトが含まれています。

backup-fetch.sh
backup-list.sh
backup-push.sh
wal-fetch.sh
wal-g-run.sh
wal-push.sh

wal-gをインストールします。

yum -y install yum-plugin-copr
yum copr enable -y antonpatsev/wal-g
yum install -y wal-g

Wal-Gのバージョンを確認しています。

wal-g --version
wal-g version v0.2.14

必要に応じて /etc/wal-gd/server-s3.conf を編集します。

データベースクラスターで使用される構成ファイルとデータファイルは、伝統的にクラスターデータディレクトリ (一般にクラスターデータディレクトリと呼ばれます) に一緒に保存されます。 PGDATA

#!/bin/bash

export PG_VER="9.6"

export WALE_S3_PREFIX="s3://pg-backups" # бакет, который мы создали в S3
export AWS_ACCESS_KEY_ID="xxxx" # AccessKey из /etc/minio/minio.conf 
export AWS_ENDPOINT="http://ip-адрес-сервера-minio:9000"
export AWS_S3_FORCE_PATH_STYLE="true"
export AWS_SECRET_ACCESS_KEY="yyyy" # SecretKey из /etc/minio/minio.conf

export PGDATA=/var/lib/pgsql/$PG_VER/data/
export PGHOST=/var/run/postgresql/.s.PGSQL.5432 # Сокет для подключения к PostgreSQL

export WALG_UPLOAD_CONCURRENCY=2 # Кол-во потоков для закачки 
export WALG_DOWNLOAD_CONCURRENCY=2 # Кол-во потоков для скачивания
export WALG_UPLOAD_DISK_CONCURRENCY=2 # Кол-во потоков на диске для закачки
export WALG_DELTA_MAX_STEPS=7
export WALG_COMPRESSION_METHOD=brotli # Какой метод сжатия использовать.

WAL-G を構成するときは、WALG_DELTA_MAX_STEPS (ベースバックアップからの差分バックアップの最大ステップ数) を指定し、差分コピーポリシーを指定します。既存の最後のデルタからコピーを作成するか、元の完全バックアップからデルタを作成します。これは、データベースの同じコンポーネントがデータベース内で常に変更されている場合、つまり同じデータが常に変更されている場合に必要です。

データベースをインストールしています。

yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.
noarch.rpm
yum install -y postgresql96 postgresql96-server mc

データベースを初期化します。

/usr/pgsql-9.6/bin/postgresql96-setup initdb
Initializing database ... OK

1 台のサーバーでテストしている場合は、PostgreSQL バージョン 10 未満の場合はアーカイブし、PostgreSQL バージョン 10 以前の場合はレプリカを作成するように wal_level パラメータを再構成する必要があります。

wal_level = archive

PostgreSQL 自体を使用して、60 秒ごとに WAL アーカイブをバックアップしてみましょう。 prod では、異なる archive_timeout 値が設定されます。

archive_mode = on
archive_command = '/usr/local/bin/wal-push.sh %p'
archive_timeout = 60 # Каждые 60 секунд будет выполнятся команда archive_command.

PostgreSQLの起動

systemctl start postgresql-9.6

別のコンソールで、PostgreSQL ログにエラーがないか調べます (postgresql-Wed.log を現在のログに変更します)。

tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

psqlに行きましょう。

su - postgres
psql

psqlでデータベースを作成する

データベース test1 にテーブルを作成します。

create database test1;

データベースのテストに切り替えます。

postgres=# c test1;

テーブルindexing_tableを作成します。

test1=# CREATE TABLE indexing_table(created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW());

データを追加しています。

データの挿入を開始します。 10～20分ほどお待ちしております。

#!/bin/bash
# postgres
while true; do
psql -U postgres -d test1 -c "INSERT INTO indexing_table(created_at) VALUES (CURRENT_TIMESTAMP);"
sleep 60;
done

必ず完全バックアップを作成してください。

su - postgres
/usr/local/bin/backup-push.sh

データベース test1 のテーブル内のレコードを調べます。

select * from indexing_table;
2020-01-29 09:41:25.226198+
2020-01-29 09:42:25.336989+
2020-01-29 09:43:25.356069+
2020-01-29 09:44:25.37381+
2020-01-29 09:45:25.392944+
2020-01-29 09:46:25.412327+
2020-01-29 09:47:25.432564+
2020-01-29 09:48:25.451985+
2020-01-29 09:49:25.472653+
2020-01-29 09:50:25.491974+
2020-01-29 09:51:25.510178+

文字列は現在の時刻です。

完全バックアップのリストを参照する

/usr/local/bin/backup-list.sh

回復テスト

利用可能なすべての WAL をローリングして完全にリカバリします。

PostgreSQLを停止します。

/var/lib/pgsql/9.6/data フォルダーからすべてを削除します。

/usr/local/bin/backup-fetch.sh スクリプトを postgres ユーザーとして実行します。

su - postgres
/usr/local/bin/backup-fetch.sh

バックアップの抽出が完了しました。

次の内容を含むrecovery.confを/var/lib/pgsql/9.6/dataフォルダーに追加します。

restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'

PostgreSQLを起動します。 PostgreSQL はアーカイブされた WAL から回復プロセスを開始し、その後初めてデータベースが開きます。

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

一定時間回復。

データベースを特定の分まで復元したい場合は、recovery_target_time パラメータをrecovery.confに追加します。データベースを復元する時間を指定します。

restore_command = '/usr/local/bin/wal-fetch.sh "%f" "%p"'
recovery_target_time = '2020-01-29 09:46:25'

リカバリ後、テーブルindexing_tableを確認します。

 2020-01-29 09:41:25.226198+00
 2020-01-29 09:42:25.336989+00
 2020-01-29 09:43:25.356069+00
 2020-01-29 09:44:25.37381+00
 2020-01-29 09:45:25.392944+00

PostgreSQLを起動します。 PostgreSQL はアーカイブされた WAL から回復プロセスを開始し、その後初めてデータベースが開きます。

systemctl start postgresql-9.6
tail -fn100 /var/lib/pgsql/9.6/data/pg_log/postgresql-Wed.log

テスト

ここで説明されているように 1GB データベースを生成する https://gist.github.com/ololobus/5b25c432f208d7eb31051a5f238dffff

1 GB のデータを生成した後のバケットサイズをリクエストします。

postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MB

s4cmd は、Amazon S3 ストレージに存在するデータを操作するための無料のコマンドラインツールです。このユーティリティは Python プログラミング言語で書かれているため、Windows と Linux の両方のオペレーティングシステムで使用できます。

s4cmdのインストール

pip install s4cmd

LZ4

s4cmd --endpoint-url=http://ip-адрес-сервера-minio:9000 --access-key=xxxx --secret-key=yyyy du -r s3://pg-backups
840540822       s3://pg-backups/wal_005/
840 МБ в формате lz4 только WAL логов

Полный бекап с lz4 - 1GB данных
time backup_push.sh
real 0m18.582s

Размер S3 бакета после полного бекапа

581480085       s3://pg-backups/basebackups_005/
842374424   s3://pg-backups/wal_005
581 МБ занимает полный бекап

LZMA

После генерации 1ГБ данных
338413694       s3://pg-backups/wal_005/
338 мб логов в формате lzma

Время генерации полного бекапа
time backup_push.sh
real    5m25.054s

Размер бакета в S3
270310495       s3://pg-backups/basebackups_005/
433485092   s3://pg-backups/wal_005/

270 мб занимает полный бекап в формате lzma

ブロトリ

После генерации 1ГБ данных
459229886       s3://pg-backups/wal_005/
459 мб логов в формате brotli

Время генерации полного бекапа
real    0m23.408s

Размер бакета в S3
312960942       s3://pg-backups/basebackups_005/
459309262   s3://pg-backups/wal_005/

312 мб занимает полный бекап в формате brotli

チャート上の結果の比較。

ご覧のとおり、Brotli のサイズは LZMA と同等ですが、バックアップは LZ4 時間で実行されます。

ロシア語を話す PostgreSQL コミュニティのチャット: https://t.me/pgsql

Githubを使用する場合はスターを付けてくださいウォルグ

出所： habr.com

wal-g PostgreSQL バックアップシステムの概要

ミニオサーバー

DBサーバー

完全バックアップのリストを参照する

回復テスト

利用可能なすべての WAL をローリングして完全にリカバリします。

一定時間回復。

テスト

LZ4

LZMA

ブロトリ

コメントを追加します返信をキャンセル

wal-g PostgreSQL バックアップ システムの概要

ミニオサーバー

DBサーバー

完全バックアップのリストを参照する

回復テスト

利用可能なすべての WAL をローリングして完全にリカバリします。

一定時間回復。

テスト

LZ4

LZMA

ブロトリ

コメントを追加します 返信をキャンセル

wal-g PostgreSQL バックアップシステムの概要

コメントを追加します返信をキャンセル