После настройки физической репликации двух кластеров main и beta остаётся

проблема с архивными журналами. Как принято, их копировать и удалять?

Никто не расскажет?

Что именно вы хотите понять?

У меня в кроне настроено удалять архивные журналы старше суток

Я пытаюсь понять, зачем после репликации кластеров PostgreSQL остаются архивные журналы в /var/lib/postgresql/archive. Никто их удалять после репликации и не обещал? По идее, архивные журналы нужны если есть горячая копия БД и сервер рухнул посреди рабочего дня, вместе со 100500 пользователей, для восстановления с ночной горячей копии БД, и наката до последнего возможного момента времени? Или не так? На работе в свое время БД Oracle были небольшие, копировали их как холодную копию только. За 20 лет Oracle не падал до такого состояния, чтобы понадобилось посреди дня восстанавливать с горячей копии.

Везучие :)

за pg_wal отвечает wal_keep_size https://www.postgresql.org/docs/current/runtime-config-replication.html

Должны сами удаляться. Либо у вас где-то висит клиент, открывший и не завершивший транзакцию, либо слот репликации лишний, который не вычитывает реплика.

Спасибо, буду разбираться сегодня. Нашел на Хабре https://habr.com/ru/company/oleg-bunin/blog/414111/ postgres=# select * from pg_stat_replication \gx -[ RECORD 1 ]----+------------------------------ pid | 1154 usesysid | 28579 usename | test application_name | 14/beta client_addr | 127.0.0.1 client_hostname | client_port | 56022 backend_start | 2022-04-20 06:40:14.972072+00 backend_xmin | state | streaming sent_lsn | 2/586707D8 write_lsn | 2/586707D8 flush_lsn | 2/586707D8 replay_lsn | 2/586707D8 write_lag | 00:00:00.000182 flush_lag | 00:00:00.000516 replay_lag | 00:00:00.000546 sync_priority | 0 sync_state | async reply_time | 2022-04-20 21:36:40.497465+00 postgres=# select * from pg_stat_archiver \gx -[ RECORD 1 ]------+------------------------------ archived_count | 472 last_archived_wal | 000000010000000200000057 last_archived_time | 2022-04-20 21:31:02.762088+00 failed_count | 0 last_failed_wal | last_failed_time | stats_reset | 2022-04-13 16:59:02.335214+00 postgres=# \! ls -la /var/lib/postgresql/archive итого 3358744 drwxrwxr-x 2 postgres postgres 20480 апр 20 21:31 . drwxr-xr-x 5 postgres postgres 4096 апр 14 07:39 .. -rw------- 1 postgres postgres 16777216 апр 18 10:21 00000001000000010000008B ... -rw------- 1 postgres postgres 16777216 апр 20 21:31 000000010000000200000057

Получается, что понимание не получается. В /var/lib/postgresql/archive лежат файлы с датой и номером ранее последнего архивированного журнала. Всё их содержимое давно уехало с main на beta. Но они не удалены после этого. А кто должен их удалить после успешной репликации?

Перезапуск кластера beta даёт в журнале: /var/log/postgresql/postgresql-14-beta.log l2022-04-20 21:54:31.724 UTC [125319] LOG: starting PostgreSQL 14.2 (Ubuntu 14.2-1.pgdg20.04+1+b1) on x86_64-pc-linux-gnu, compiled by gcc (x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.725 UTC [125319] LOG: listening on IPv4 address "127.0.0.1", port 5433 x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.726 UTC [125319] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5433" x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.740 UTC [125322] LOG: database system was shut down in recovery at 2022-04-20 21:53:51 UTC x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.741 UTC [125322] LOG: entering standby mode x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.749 UTC [125322] LOG: redo starts at 2/58FE2AB0 x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.785 UTC [125322] LOG: consistent recovery state reached at 2/593BCA30 x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.785 UTC [125322] LOG: invalid resource manager ID 24 at 2/593BCA30 x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.786 UTC [125319] LOG: database system is ready to accept read-only connections x /var/log/postgresql/postgresql-14-beta.log x2022-04-20 21:54:31.805 UTC [125326] LOG: started streaming WAL from primary at 2/59000000 on timeline 1 x Перезапуск main: /var/log/postgresql/postgresql-14-main.log l2022-04-20 21:57:03.863 UTC [125737] LOG: starting PostgreSQL 14.2 (Ubuntu 14.2-1.pgdg20.04+1+b1) on x86_64-pc-linux-gnu, compiled by gcc (x /var/log/postgresql/postgresql-14-main.log x2022-04-20 21:57:03.864 UTC [125737] LOG: listening on IPv4 address "127.0.0.1", port 5432 x /var/log/postgresql/postgresql-14-main.log x2022-04-20 21:57:03.865 UTC [125737] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" x /var/log/postgresql/postgresql-14-main.log x2022-04-20 21:57:03.870 UTC [125738] LOG: database system was shut down at 2022-04-20 21:56:43 UTC x /var/log/postgresql/postgresql-14-main.log x2022-04-20 21:57:03.878 UTC [125739] zabbix@zabbix FATAL: the database system is starting up x /var/log/postgresql/postgresql-14-main.log m2022-04-20 21:57:03.885 UTC [125737] LOG: database system is ready to accept connections x /var/log/postgresql/postgresql-14-beta.log l2022-04-20 21:57:08.428 UTC [125789] LOG: started streaming WAL from primary at 2/5A000000 on timeline 1 x

postgres=# SELECT client_addr AS client, usename AS user, application_name AS name, state, sync_state AS mode, postgres-# (pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) / 1024)::int as pending, postgres-# (pg_wal_lsn_diff(sent_lsn, write_lsn) / 1024)::int as write, postgres-# (pg_wal_lsn_diff(write_lsn,flush_lsn) / 1024)::int as flush, postgres-# (pg_wal_lsn_diff(flush_lsn,replay_lsn) / 1024)::int as replay, postgres-# (pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn))::int / 1024 as total_lag postgres-# FROM pg_stat_replication; client | user | name | state | mode | pending | write | flush | replay | total_lag -----------+------+---------+-----------+-------+---------+-------+-------+--------+----------- 127.0.0.1 | test | 14/beta | streaming | async | 0 | 0 | 0 | 0 | 0 (1 строка)

А вот это интересно postgres=# select name, setting, setting::int * 16 || 'MB' AS setting_in_mb postgres-# from pg_settings postgres-# where name in ('min_wal_size', 'max_wal_size'); name | setting | setting_in_mb --------------+---------+--------------- max_wal_size | 1024 | 16384MB min_wal_size | 80 | 1280MB postgres@singularity:~$ du /var/lib/postgresql/archive 3457044 /var/lib/postgresql/archive

по этой картинке я понял что у вас проблема с директорией pg_wal - её трогать нельзя, там postgres сам должен ротацию делать. если у вас проблема с директорией archive - которая наполняется командой archive_command то вам уже дали совет, удаляете (сами, например кроном) старше 1 дня или как часто у вас полный бэкап

Пока что этой мой личный стенд, на котором из пользователей только я да Zabbix. Можно делать что угодно для тестирования PostgreSQL. Если, как писали выше, в каталоге /var/lib/postgresql/archive сейчас online redo logs в терминологии Oracle Database, то это очень странно. В Oracle redolog я создавал при настройке экземпляра и они переключаются по кругу. Здесь же видим другое поведение процесса, ну не может же PostgreSQL так сильно отличаться от Oracle Database в плане управления redo log? Значит, в /var/lib/postgresql/archive всё-таки не online redo log, а архивированные журналы. По ним стратегия должна быть одинакова для PostgreSQL и Oracle - скопируй и удали. В Oracle для этого я настраивал HP Data Protector, в нём есть интеграция с rman. Скрипт rman удалял archivelog. А как в PostgreSQL? Временное решение postgres@singularity:~$ rm /var/lib/postgresql/archive/* postgres@singularity:~$ ls -la /var/lib/postgresql/archive итого 24 drwxrwxr-x 2 postgres postgres 20480 апр 21 21:53 . drwxr-xr-x 5 postgres postgres 4096 апр 14 07:39 ..

покажите что у вас в archive_command

Пусто. Закомментирован на кластере main.

а в postgresql.auto.conf?

postgres@singularity:~$ cat /var/lib/postgresql/14/main/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. archive_mode = 'on' archive_command = 'test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f' max_wal_size = '512' На beta так postgres@singularity:~$ cat /var/lib/postgresql/14/beta/postgresql.auto.conf # Do not edit this file manually! # It will be overwritten by the ALTER SYSTEM command. archive_mode = 'on' archive_command = 'test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f' max_wal_size = '512' primary_conninfo = 'user=test password=testpassword channel_binding=prefer host=127.0.0.1 port=5432 sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'