Курс DBA1-16: Администрирование СУБД Tantor. WAL-G

Резервирование и восстановление с использованием WAL-G

Часть 1. Конфигурирование сервера хранения бэкапов minio

Протокол S3 (Simple Storage Service) используется компаниями, предоставляющими услуги по хранению данных большого объема. Приложение, обслуживающее хранилище, может быть быть установлено в сети предприятия. В этой практике используется приложение minio.

1) Проверьте установлено ли приложение minio:

postgres@tantor:~$ sudo apt-get install minio

Reading package lists... Done

Building dependency tree

Reading state information... Done

minio is already the newest version (20240321231343.0.0).

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Приложение установлено.

2) Посмотрите содержимое конфигурационного файла minio:

postgres@tantor:~$ cat /etc/default/minio

MINIO_ROOT_USER=minioadmin

MINIO_ROOT_PASSWORD=minioadmin

MINIO_VOLUMES="/var/local/minio/disk1"

MINIO_SERVER_URL=http://localhost:9000

После установки приложения этот файл и директория создаются вручную. В нем указывается директория, в которой будут создаваться бэкапы, имя и пароль привилегированного пользователя, порт для веб-оболочки управления приложением.

3) Запустите службу minio:

postgres@tantor:~$ sudo systemctl enable --now minio

Created symlink /etc/systemd/system/multi-user.target.wants/minio.service > /lib/systemd/system/minio.service.

4) Запустите браузер и откройте адрес http://127.0.0.1:9000

Введите имя minioadmin и пароль minioadmin

Нажмите кнопу Login и сохраните пароль в браузере.

5) Создайте корзину (логический контейнер для классификации бэкапов). Нажмите на ссылку Create Bucket или слева в меню выберите Buckets

Введите в поле Bucket Name название bucket1. Нажмите кнопку Create Bucket. Корзина будет создана.

Создавать корзины и давать им названия так чтобы было легко идентифицировать кластер баз данных, который будет резервироваться. Для каждого кластера свою корзину. WAL-G поддерживает backup offloading - резервирование с физической реплики. Для физических реплик создавать отдельные корзины не нужно.

6) Этот пункт опционален. Его можно не выполнять, он не требуется для WAL-G. Пункт иллюстириует конфигурирование клиентской утилиты, которая не используется WAL-G. Пункт может быть инетересен тем, что можно получить доступ к тестовому облачному хранилищу minio по адресу https://play.min.io.

postgres@tantor:~$ cat << EOF > s3.config

access-key = minioadmin

secret-key = minioadmin

s3-host = localhost

s3-port = 9000

s3-bucket = bucket1

s3-secure = off

EOF

postgres@tantor:~$ sudo chmod 755 /usr/local/bin/mccli

postgres@tantor:~$ /usr/local/bin/mccli alias set local http://127.0.0.1:9000

mccli: Configuration written to `/var/lib/postgresql/.mccli/config.json`. Please update your access credentials.

mccli: Successfully created `/var/lib/postgresql/.mccli/share`.

mccli: Initialized share uploads `/var/lib/postgresql/.mccli/share/uploads.json` file.

mccli: Initialized share downloads `/var/lib/postgresql/.mccli/share/downloads.json` file.

Enter Access Key: minioadmin

Enter Secret Key: minioadmin

Added `local` successfully.

postgres@tantor:~$ cat .mccli/config.json

{

"version": "10",

"aliases": {

"gcs": {

"url": "https://storage.googleapis.com",

"accessKey": "YOUR-ACCESS-KEY-HERE",

"secretKey": "YOUR-SECRET-KEY-HERE",

"api": "S3v2",

"path": "dns"

"local": {

"url": "http://127.0.0.1:9000",

"accessKey": "minioadmin",

"secretKey": "minioadmin",

"api": "s3v4",

"path": "auto"

"play": {

"url": "https://play.min.io",

"accessKey": "Q3AM3UQ867SPQQA43P2F",

"secretKey": "zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG",

"api": "S3v4",

"path": "auto"

"s3": {

"url": "https://s3.amazonaws.com",

"accessKey": "YOUR-ACCESS-KEY-HERE",

"secretKey": "YOUR-SECRET-KEY-HERE",

"api": "S3v4",

"path": "dns"

}

Можно открыть новую вкладку в браузере и зайти на адрес https://play.min.io

Ввести из файла имя Q3AM3UQ867SPQQA43P2F пароль zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG

На этом сайте можно посмотреть пример работы серверной части minio.

Часть 2. Установка WAL-G

1) Откройте новый терминал и выполните команду:

astra@tantor:~$ sudo dpkg -i wal-g-tantor-all_2.0.1-1astra1.7-1_amd64.deb

Выбор ранее не выбранного пакета wal-g-tantor-all.

(Чтение базы данных … на данный момент установлено 211859 файлов и каталогов.)

Подготовка к распаковке wal-g-tantor-all_2.0.1-1astra1.7-1_amd64.deb …

Распаковывается wal-g-tantor-all (2.0.1-1astra1.7-1) …

Настраивается пакет wal-g-tantor-all (2.0.1-1astra1.7-1) …

Пакет содержит единственный файл /opt/tantor/usr/bin/wal-g

2) Проверьте версию WAL-G:

astra@tantor:~$ wal-g --version

wal-g version v2.0.1 b7d53dd7 2024.01.12_16:25:53 PostgreSQL

3) Посмотрите как называется файл параметров WAL-G и его местоположение:

postgres@tantor:~$ wal-g | grep config

--config string config file (default is $HOME/.walg.json)

--turbo Ignore all kinds of throttling defined in config

По умолчанию местоположение файла параметров $HOME/.walg.json.

4) Создайте файл параметров WAL-G в домашнем каталоге пользователя операционной системы postgres:

postgres@tantor:~$ cat > .walg.json << EOF

{

"AWS_ENDPOINT": "http://127.0.0.1:9000",

"WALG_S3_PREFIX": "s3://bucket1",

"AWS_ACCESS_KEY_ID": "minioadmin",

"AWS_SECRET_ACCESS_KEY": "minioadmin",

"AWS_S3_FORCE_PATH_STYLE": "true",

"WALG_COMPRESSION_METHOD": "brotli",

"WALG_DELTA_MAX_STEPS": "5",

"PGDATA": "/var/lib/postgresql/tantor-se-16/data",

"PGHOST": "/var/run/postgresql"

}

EOF

5) Проверьте, что утилита командной строки wal-g может подсоединяться к серверу по протокуолу S3. Для этого проверьте список бэкапов:

postgres@tantor:~$ wal-g backup-list

INFO: 2024/07/04 15:51:48.707457 No backups found

Если корзина не существует, то будет выдана ошибка. Пример ошибки:

ERROR: 2024/07/04 15:43:19.396870 failed to list s3 folder: 'basebackups_005/': NoSuchBucket: The specified bucket does not exist

status code: 404, request id: 17DF031B83CC101C, host id: dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8

6) Посмотрите какие wal сегменты есть у кластера:

postgres@tantor:~$ ls $PGDATA/pg_wal

000000010000000000000019 archive_status

7) Посмотрим какой командой передаются WAL-сегменты.

Выполните команду, передав в качестве параметра имя файла WAL-сегмента:

postgres@tantor:~$ wal-g wal-push $PGDATA/pg_wal/000000010000000000000019

INFO: 2024/07/04 15:56:05.009296 FILE PATH: 000000010000000000000019.br

8) Утилита не удаляет то, что бэкапит. Проверьте, что исходный файл не был удалён:

postgres@tantor:~$ ls $PGDATA/pg_wal

000000010000000000000019 archive_status walg_data

В директории журналов была создана поддиректория walg_data/walg_archive_status

9) Выполните команду:

postgres@tantor:~$ wal-g backup-list

INFO: 2024/07/04 16:01:30.875297 No backups found

Бэкапов кластера не найдено, так как мы их пока не делеали.

10) Выполните команды:

postgres@tantor:~$ wal-g wal-show

INFO: 2024/07/04 16:02:11.822601 No backups found in storage.

+-----+------------+-----------------+------------------------+------------------------+-------------

+-----+------------+-----------------+------------------------+------------------------+-------------

| 1 | 0 | 0/0 |000000010000000000000019|000000010000000000000019| 1 |

1 | OK | 0 |

+-----+------------+-----------------+------------------------+------------------------+-------------

postgres@tantor:~$ wal-g wal-verify timeline

WARNING: 2024/07/04 16:03:17.728025 It seems your archive_mode is not enabled. This will cause inconsistent backup. Please consider configuring WAL archiving.

INFO: 2024/07/04 16:03:17.750944 000000010000000000000019

INFO: 2024/07/04 16:03:17.762117 Building check runner: timeline

INFO: 2024/07/04 16:03:17.762253 Running the check: timeline

[wal-verify] timeline check status: OK

[wal-verify] timeline check details:

Highest timeline found in storage: 1

Current cluster timeline: 1

postgres@tantor:~$ wal-g wal-verify integrity

WARNING: 2024/07/04 16:03:43.575246 It seems your archive_mode is not enabled. This will cause inconsistent backup. Please consider configuring WAL archiving.

INFO: 2024/07/04 16:03:43.579362 Current WAL segment: 000000010000000000000019

INFO: 2024/07/04 16:03:43.586333 Building check runner: integrity

WARNING: 2024/07/04 16:03:43.604241 Failed to detect earliest backup WAL segment no: 'No backups found',will scan until the 0000000X0000000000000001 segment.

INFO: 2024/07/04 16:03:43.604378 Running the check: integrity

[wal-verify] integrity check status: WARNING

[wal-verify] integrity check details:

+-----+--------------------------+--------------------------+----------------+-------------------+

+-----+--------------------------+--------------------------+----------------+-------------------+

| 1 | 000000010000000000000001 | 000000010000000000000008 | 8 | MISSING_LOST |

| 1 | 000000010000000000000009 | 000000010000000000000018 | 16 | MISSING_UPLOADING |

+-----+--------------------------+--------------------------+----------------+-------------------+

Часть 3. Конфигурирование кластера для архивирования журналов

1) Запустите psql и установите значения параметров конфигурации:

postgres@tantor:~$ psql

psql (16.1)

Type "help" for help.

postgres=# alter system set archive_command = '/opt/tantor/usr/bin/wal-g wal-push "%p" >> $PGDATA/log/archive_command.log 2>&1';

ALTER SYSTEM

postgres=# alter system set restore_command = '/opt/tantor/usr/bin/wal-g wal-fetch "%f" "%p" >> $PGDATA/log/restore_command.log 2>&1';

ALTER SYSTEM

postgres=# alter system set archive_mode=on;

ALTER SYSTEM

Параметр archive_command устанавливает команду, которая будет выполняться после переключения на следующий WAL-сегмент. Команда должна завешаться успешно (возвращать статус "0"), иначе сегмент будет считаться не зарархивированным и не сможет удаляться. %p - переменная которая инициализируется названием и путём к WAL-сегменту в который завершена запись и который должен быть заархивирован.Сообщения утилиты которые она выводит в stdout и stderr направляются в файл.

Параметр restore_command указывает какая команда будет выполнена процессом startup, который восстанавливает кластер после запуска экземпляра и определяет по файлу backup_label или pg_colntrol какой WAL-сегмент нужен для продолжения восстановления (будет накатываться следующим). Эта команда должна создать WAL-файл в директории $PGDATA/pg_wal

Параметр archive_mode включает действие параметра archive_command.

У этого параметра есть еще значение always, что означает что archive_command будет выполняться и во время восстановления из бэкапа и в режиме физической реплики.

Утилита wal-g использует файл параметров $HOME/.walg.json. Если нужно иметь несколько файлов параметров, то можно использовать параметр --config. Пример:

alter system set archive_command = '/opt/tantor/usr/bin/wal-g --config /var/lib/postgresql/.walg.json wal-push "%p" >> $PGDATA/log/archive_command.log 2>&1';

2) Перезапустите экземпляр:

postgres@tantor:~$ pg_ctl stop

postgres@tantor:~$ sudo systemctl start tantor-se-server-16

3) Проверьте, что в директории журналов появилась поддиректория archive_status:

postgres@tantor:~$ ls -a $PGDATA/pg_wal/archive_status

. .. 00000001000000000000001A.done

В директории присутствует пустой файл.

4) Проверьте, что появился файл archive_command.log путь к которому был указан в параметре archive_command:

postgres@tantor:~$ cat $PGDATA/log/archive_command.log

INFO: 2024/07/04 16:34:37.373971 FILE PATH: 00000001000000000000001A.br

Если файл не появился и опечаток нет, это может означать, что экземпляр не был остановлен, а был перезапущен опцией restart (процесс postgres не выгружался из памяти).

5) Выполните команду:

postgres@tantor:~$ wal-g wal-verify integrity

INFO: 2024/07/04 16:43:29.235139 Current WAL segment: 00000001000000000000001B

INFO: 2024/07/04 16:43:29.244838 Building check runner: integrity

WARNING: 2024/07/04 16:43:29.266445 Failed to detect earliest backup WAL segment no: 'No backups found',will scan until the 0000000X0000000000000001 segment.

INFO: 2024/07/04 16:43:29.266730 Running the check: integrity

[wal-verify] integrity check status: WARNING

[wal-verify] integrity check details:

+-----+--------------------------+--------------------------+----------------+-------------------+

+-----+--------------------------+--------------------------+----------------+-------------------+

| 1 | 000000010000000000000001 | 00000001000000000000000A | 10 | MISSING_LOST |

| 1 | 00000001000000000000000B | 000000010000000000000018 | 14 | MISSING_UPLOADING |

| 1 | 000000010000000000000019 | 00000001000000000000001A | 2 | FOUND |

+-----+--------------------------+--------------------------+----------------+-------------------+

Файлы журнала были заархивированы.

6) Зарезервируйте директорию кластера. WAL-G запускается на хосте с кластером, поэтому можно не пользоваться протоколом репликации, а копировать содержимое директории.

Для этого передать в качестве параметра название директории кластера:

postgres@tantor:~$ wal-g backup-push $PGDATA

INFO: 2024/07/04 16:45:29.484805 Couldn't find previous backup. Doing full backup.

INFO: 2024/07/04 16:45:29.514046 Calling pg_start_backup()

INFO: 2024/07/04 16:45:29.630427 Starting a new tar bundle

INFO: 2024/07/04 16:45:29.630574 Walking ...

INFO: 2024/07/04 16:45:29.632062 Starting part 1 ...

INFO: 2024/07/04 16:45:35.436669 Packing ...

INFO: 2024/07/04 16:45:35.439440 Finished writing part 1.

INFO: 2024/07/04 16:45:35.814169 Starting part 2 ...

INFO: 2024/07/04 16:45:35.814216 /global/pg_control

INFO: 2024/07/04 16:45:35.816267 Finished writing part 2.

INFO: 2024/07/04 16:45:35.816305 Calling pg_stop_backup()

INFO: 2024/07/04 16:45:35.864195 Starting part 3 ...

INFO: 2024/07/04 16:45:35.868956 backup_label

INFO: 2024/07/04 16:45:35.869596 tablespace_map

INFO: 2024/07/04 16:45:35.871637 Finished writing part 3.

INFO: 2024/07/04 16:45:35.989039 Wrote backup with name base_00000001000000000000001C

В начале резервирования при вызове функции pg_start_backup() была выполнена контрольная точка в режиме immediate force wait

postgres@tantor:~/tantor-se-16/data/log$ tail -n 2 postgresql-2024-07-04_163447.log

2024-07-04 16:45:29.581 MSK [2973] LOG: checkpoint starting: immediate force wait

2024-07-04 16:45:29.625 MSK [2973] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.045 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16383 kB, estimate=16383 kB; lsn=0/1C000070, redo lsn=0/1C000028

7) Проверьте, что созданный бэкап есть в списке:

postgres@tantor:~$ wal-g backup-list

name modified wal_segment_backup_start

base_00000001000000000000001C 2024-07-04T13:45:35Z 00000001000000000000001C

Если при резервировании указать произвольную директорию, а не директорию кластера выдастся ошибка:

postgres@tantor:~$ wal-g backup-push abcd

WARNING: 2024/07/04 16:54:15.130694 Data directory for postgres 'abcd' is not equal to backup-push argument '/var/lib/postgresql/tantor-se-16/data'

ERROR: 2024/07/04 16:54:15.131420 Data directory read from Postgres (abcd) is different than as parsed (/var/lib/postgresql/tantor-se-16/data).

panic: Data directory read from Postgres (abcd) is different than as parsed (/var/lib/postgresql/tantor-se-16/data).

Интуитивно не понятно, что обозначается "Postgres" и "parsed", вероятно, директории перепутаны местами.

Для просмотра бэкапов через веб-интерфейс нужно на странице корзины кликнуть на иконку папки спрва вверху окна браузера:

8) В директории pg_wal появился файл:

postgres@tantor:~$ ls $PGDATA/pg_wal/

00000001000000000000001C.00000028.backup 00000001000000000000001E archive_status

00000001000000000000001D 00000001000000000000001F walg_data

postgres@tantor:~$ cat $PGDATA/pg_wal/*.backup

START WAL LOCATION: 0/1C000028 (file 00000001000000000000001C)

STOP WAL LOCATION: 0/1C000130 (file 00000001000000000000001C)

CHECKPOINT LOCATION: 0/1C000070

BACKUP METHOD: streamed

BACKUP FROM: primary

START TIME: 2024-07-04 16:45:29 MSK

LABEL: 2024-07-04 16:45:29.514037 +0300 MSK m=+0.118109848

START TIMELINE: 1

STOP TIME: 2024-07-04 16:45:35 MSK

STOP TIMELINE: 1

Часть 4. Восстановление из бэкапа созданного WAL-G

В конфигурации есть физическая реплика. Проверьте, что слот репликации используется:

postgres=# select * from pg_stat_replication\gx

-[ RECORD 1 ]----+------------------------------

pid | 2981

usesysid | 16384

usename | replicator

application_name | walreceiver

client_addr | ::1

client_hostname |

client_port | 41306

backend_start | 2024-07-04 16:34:47.297025+03

backend_xmin |

state | streaming

sent_lsn | 0/1D000198

write_lsn | 0/1D000198

flush_lsn | 0/1D000198

replay_lsn | 0/1D000198

write_lag |

flush_lag |

replay_lag |

sync_priority | 0

sync_state | async

reply_time | 2024-07-04 17:04:43.201876+03

postgres=# select * from pg_replication_slots \gx

-[ RECORD 1 ]-------+-----------

slot_name | pgstandby1

plugin |

slot_type | physical

datoid |

database |

temporary | f

active | t

active_pid | 2981

xmin |

catalog_xmin |

restart_lsn | 0/1D000198

confirmed_flush_lsn |

wal_status | reserved

safe_wal_size | 1090518632

two_phase | f

conflicting |

2) Если предыдущая часть этой практики была успешно выполнена, то есть архивирование журналов выполнялось, бэкап был сделан, то остановите кластер и удалите директорию PGDATA:

postgres@tantor:~$ pg_ctl stop

waiting for server to shut down.... done

server stopped

postgres@tantor:~$ rm -rf $PGDATA/*

Команда симулирует полную потерю мастера ("disaster") Команда удаляет в том числе и текущий WAL-сегмент, который не был записан в архив. Транзакции, которые находятся в этом файле не будут восстановлены.

2) Выполните команду восставновления директории кластера из бэкапа:

postgres@tantor:~$ wal-g backup-fetch $PGDATA LATEST

INFO: 2024/07/04 17:09:21.604287 Selecting the latest backup...

INFO: 2024/07/04 17:09:21.608464 LATEST backup is: 'base_00000001000000000000001C'

INFO: 2024/07/04 17:09:21.648710 Finished extraction of part_003.tar.br

INFO: 2024/07/04 17:09:28.920711 Finished extraction of part_001.tar.br

INFO: 2024/07/04 17:09:28.926843 Finished extraction of pg_control.tar.br

INFO: 2024/07/04 17:09:28.927310

Backup extraction complete.

Директория восстановлена.

3) Проверьте содержимое директории журналов:

postgres@tantor:~$ ls $PGDATA/pg_wal

Директория пуста.

4) Посмотрите содержимое управляющего файла:

postgres@tantor:~$ pg_controldata

pg_control version number: 1300

Catalog version number: 202307071

Database system identifier: 7353194261070147214

Database cluster state: in production

pg_control last modified: Thu 04 Jul 2024 04:45:29 PM MSK

Latest checkpoint location: 0/1C000070

Latest checkpoint's REDO location: 0/1C000028

Latest checkpoint's REDO WAL file: 00000001000000000000001C

Latest checkpoint's TimeLineID: 1

Latest checkpoint's PrevTimeLineID: 1

Latest checkpoint's full_page_writes: on

Latest checkpoint's NextXID: 764

Latest checkpoint's NextOID: 16529

Latest checkpoint's NextMultiXactId: 1

Latest checkpoint's NextMultiOffset: 0

Latest checkpoint's oldestXID: 723

Latest checkpoint's oldestXID's DB: 1

Latest checkpoint's oldestActiveXID: 764

Latest checkpoint's oldestMultiXid: 1

Latest checkpoint's oldestMulti's DB: 1

Latest checkpoint's oldestCommitTsXid:0

Latest checkpoint's newestCommitTsXid:0

Time of latest checkpoint: Thu 04 Jul 2024 04:45:29 PM MSK

Fake LSN counter for unlogged rels: 0/3E8

Minimum recovery ending location: 0/0

Min recovery ending loc's timeline: 0

Backup start location: 0/0

Backup end location: 0/0

End-of-backup record required: no

wal_level setting: replica

wal_log_hints setting: off

max_connections setting: 100

max_worker_processes setting: 8

max_wal_senders setting: 10

max_prepared_xacts setting: 0

max_locks_per_xact setting: 64

track_commit_timestamp setting: off

Maximum data alignment: 8

Database block size: 8192

Blocks per segment of large relation: 131072

WAL block size: 8192

Bytes per WAL segment: 16777216

Maximum length of identifiers: 64

Maximum columns in an index: 32

Maximum size of a TOAST chunk: 1996

Size of a large-object chunk: 2048

Date/time type storage: 64-bit integers

Float8 argument passing: by value

Data page checksum version: 0

Mock authentication nonce: 5c6cff5b22f9ce01ca3ad035abc27d15de5499782456494a5dbc7016b5fdc3a9

Управляющий файл - образ того который существовал на момент резервирования.

На это указывают строки:

Database cluster state: in production

pg_control last modified: Thu 04 Jul 2024 04:45:29 PM MSK

5) Вместо управляющего файла будет использоваться backup_label

Посмотрите что он присутствует и не пуст:

postgres@tantor:~$ cat $PGDATA/backup_label

START WAL LOCATION: 0/1C000028 (file 00000001000000000000001C)

CHECKPOINT LOCATION: 0/1C000070

BACKUP METHOD: streamed

BACKUP FROM: primary

START TIME: 2024-07-04 16:45:29 MSK

LABEL: 2024-07-04 16:45:29.514037 +0300 MSK m=+0.118109848

START TIMELINE: 1

6) Попробуйте запустить экземпляр:

postgres@tantor:~$ pg_ctl start

waiting for server to start....

2024-07-04 17:16:12.130 MSK [3368] СООБЩЕНИЕ: передача вывода в протокол процессу сбора протоколов

2024-07-04 17:16:12.130 MSK [3368] ПОДСКАЗКА: В дальнейшем протоколы будут выводиться в каталог "log".

stopped waiting

pg_ctl: could not start server

Examine the log output.

Экземпляр не смог запуститься, нет журналов для синхронизации файлов кластера, так как в директории pg_wal нет ни одного файла журнала.

7) Создайте файл, который укажет, что выполняется восстановление из бэкапа:

postgres@tantor:~$ touch $PGDATA/recovery.signal

8) Запустите экземпляр:

postgres@tantor:~$ pg_ctl start

waiting for server to start....

2024-07-04 17:21:25.081 MSK [3445] СООБЩЕНИЕ: передача вывода в протокол процессу сбора протоколов

2024-07-04 17:21:25.081 MSK [3445] ПОДСКАЗКА: В дальнейшем протоколы будут выводиться в каталог "log".

. done

server started

Кластер был восстановлен и экземпляр запущен. Последний примененный журнальный файл тот, который был заархивирован. Было выполнено неполное восстановление.

Журнальные файлы, которые не попали в архив не были применены и транзакции которые могли бы в них быть были потеряны.

9) Посмотрите содержимое директории с журналами:

postgres@tantor:~$ ls -a $PGDATA/pg_wal

. 00000002000000000000001E 000000020000000000000020 archive_status walg_data

.. 00000002000000000000001F 00000002.history .wal-g

Директория непустая. Была создана новая линия времени.

Помимо прочего, появились файл 0000002.history и пустая директория .wal-g/prefetch/running

10) Проверьте, что слоты репликации, которые существовали в начале этой части практики были удалены:

postgres@tantor:~$ psql

psql (16.1)

Type "help" for help.

postgres=# select * from pg_stat_replication\gx

(0 rows)

postgres=# select * from pg_replication_slots \gx

(0 rows)

Причина: неполное восстановление.

Часть 5. Использование WAL-G с файловой системой

WAL-G кроме использования протокола S3 может резервировать и восстанавливать из директории в файловой системе. Директория не обязательно на локальном диске, можно смонтировать любую файловую систему, например, NFS.

1) Создайте файл параметров WAL-G:

postgres@tantor:~$ cat > /var/lib/postgresql/.walgf.json <<EOF

{

"WALG_FILE_PREFIX": "/var/lib/postgresql/tantor-se-16",

"WALG_COMPRESSION_METHOD": "brotli",

"WALG_DELTA_MAX_STEPS": "5",

"PGHOST": "/var/run/postgresql/.s.PGSQL.5432",

"PGDATA": "/var/lib/postgresql/tantor-se-server-15/main/$(cat /etc/hostname)"

}

EOF

Резервирование будет выполняться в директорию, на которую указывает ключ WALG_FILE_PREFIX

2) Создайте бэкап, выполнив команду:

postgres@tantor:~$ wal-g --config /var/lib/postgresql/.walgf.json backup-push $PGDATA

INFO: 2024/07/04 18:38:13.859671 Couldn't find previous backup. Doing full backup.

INFO: 2024/07/04 18:38:13.884199 Calling pg_start_backup()

INFO: 2024/07/04 18:38:13.937985 Starting a new tar bundle

INFO: 2024/07/04 18:38:13.938445 Walking ...

INFO: 2024/07/04 18:38:13.939263 Starting part 1 ...

INFO: 2024/07/04 18:38:16.984992 Packing ...

INFO: 2024/07/04 18:38:16.987214 Finished writing part 1.

INFO: 2024/07/04 18:38:16..987498 Starting part 2 ...

INFO: 2024/07/04 18:38:16.987877 /global/pg_control

INFO: 2024/07/04 18:38:16.988634 Finished writing part 2.

INFO: 2024/07/04 18:38:16.988737 Calling pg_stop_backup()

INFO: 2024/07/04 18:38:17.021268 Starting part 3 ...

INFO: 2024/07/04 18:38:17.022452 backup_label

INFO: 2024/07/04 18:38:17.022772 tablespace_map

INFO: 2024/07/04 18:38:17.023600 Finished writing part 3.

INFO: 2024/07/04 18:38:17.039974 Wrote backup with name base_00000002000000000000001F

3) Посомтрите какие директории и файлы были созданы:

postgres@tantor:~$ ls -a /var/lib/postgresql/tantor-se-16

. .. basebackups_005 data

postgres@tantor:~$ ls -a /var/lib/postgresql/tantor-se-16/basebackups_005

. base_00000002000000000000001F

.. base_00000002000000000000001F_backup_stop_sentinel.json

postgres@tantor:~$ wal-g --config /var/lib/postgresql/.walgf.json backup-push $PGDATA

INFO: 2024/07/04 18:49:13.386080 LATEST backup is: 'base_00000002000000000000001F'

INFO: 2024/07/04 18:49:13.386934 Delta backup from base_00000002000000000000001F with LSN 0/1F000028.

INFO: 2024/07/04 18:49:13.430095 Calling pg_start_backup()

INFO: 2024/07/04 18:49:13.492602 Delta backup enabled

INFO: 2024/07/04 18:49:13.492820 Starting a new tar bundle

INFO: 2024/07/04 18:49:13.493022 Walking ...

INFO: 2024/07/04 18:49:13.493596 Starting part 1 ...

INFO: 2024/07/04 18:49:13.536216 Packing ...

INFO: 2024/07/04 18:49:13.541442 Finished writing part 1.

INFO: 2024/07/04 18:49:13.541661 Starting part 2 ...

INFO: 2024/07/04 18:49:13.541839 /global/pg_control

INFO: 2024/07/04 18:49:13.543270 Finished writing part 2.

INFO: 2024/07/04 18:49:13.543529 Calling pg_stop_backup()

INFO: 2024/07/04 18:49:13.590353 Starting part 3 ...

INFO: 2024/07/04 18:49:13.590899 backup_label

INFO: 2024/07/04 18:49:13.591465 tablespace_map

INFO: 2024/07/04 18:49:13.592343 Finished writing part 3.

INFO: 2024/07/04 18:49:13.598641 Wrote backup with name base_000000020000000000000021_D_00000002000000000000001F

postgres@tantor:~$ ls -a /var/lib/postgresql/tantor-se-16/basebackups_005

base_00000002000000000000001F

base_00000002000000000000001F_backup_stop_sentinel.json

base_000000020000000000000021_D_00000002000000000000001F

base_000000020000000000000021_D_00000002000000000000001F_backup_stop_sentinel.json

Часть 6. Остановка архивирования журналов

1) Выполните команды:

postgres@tantor:~ $ rm -rf /var/lib/postgresql/tantor-se-16/basebackups_005

postgres@tantor:~ $ psql -c "alter system set archive_mode = off;"

ALTER SYSTEM

postgres@tantor:~ $ pg_ctl stop

waiting for server to shut down.... done

server stopped

postgres@tantor:~ $ sudo systemctl start tantor-se-server-16

postgres@tantor:~$ sudo systemctl stop tantor-se-server-16-replica

Значение параметра archive_mode = off отключает резервирование WAL-сегментов.