是一個簡單有效的將 PostgreSQL 備份到雲端的工具。 就其主要功能而言，它是流行工具的繼承者 ，但用 Go 重寫。 但 WAL-G 有一個重要的新功能——增量副本。 增量副本 存儲自上一個備份版本以來已更改的文件頁面。 WAL-G 實現了相當多的並行備份技術。 WAL-G 比 WAL-E 快得多。
有關 wal-g 工作原理的詳細信息可以在文章中找到：
S3 存儲協議已成為流行的數據存儲方式。 S3 的優勢之一是能夠通過 API 進行訪問，這允許您組織與存儲的靈活交互，包括公共讀取訪問，而更新存儲中的信息只能由授權人員進行。
有多種使用 S3 協議的公共和私有存儲實現。 今天我們將介紹一種流行的小型存儲解決方案 - Minio。
單個 PostgreSQL 服務器足以測試 wal-g，並且使用 Minio 作為 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啟動 Minio
systemctl start minio進入Minio網頁界面 並創建一個存儲桶（例如，pg-backups）。
數據庫服務器
WAL-G rpm 是由我（Anton Patsev）組裝的。 , .
如果沒有基於 RPM 的系統，請使用官方的 通過安裝。
除了 wal-g 二進製文件之外，rpm 還包含從 /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安裝沃爾格。
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 台服務器上進行測試，則需要重新配置 wal_level 參數以對版本 10 以下的 PostgreSQL 進行歸檔，並為 PostgreSQL 版本 10 及更早版本重新配置副本。
wal_level = archive讓我們使用 PostgreSQL 本身每 60 秒備份一次 WAL 存檔。 在產品上，您將擁有不同的 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 文件夾中的所有內容。
以 postgres 用戶身份運行 /usr/local/bin/backup-fetch.sh 腳本。
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 數據庫
生成1GB數據後請求bucket大小。
postgres=# SELECT pg_size_pretty(pg_database_size('test1'));
pg_size_pretty
----------------
1003 MBs4cmd 是一個免費的命令行工具，用於處理駐留在 Amazon S3 存儲中的數據。 該實用程序是用 python 編程語言編寫的，因此它可以在 Windows 和 Linux 操作系統中使用。
安裝 s4cmd
pip install s4cmdLZ4
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 мб занимает полный бекап в формате lzmaBrotli
После генерации 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 社區的聊天：
如果您使用請給Github一個star
來源： www.habr.com