Всем доброго дня. Подскажите, пожалуйста, у меня в коннектах висят

"COMMIT" в статусе "active", а как узнать что было до вызова commit ?

В логи посмотреть. Если включен какой-то log_statment или auto_explain... А так — это по дефолту никуда не записывается.

Синхронная репликацыя что ли встала?

да вот не понимаю, мне приходит этот коммит и синх реплика схватывает replay_lag Хотя уже настроил, synchronous_commit = remote_apply (был просто On )

А реплика логическая или физическая?

физическая.

Хм. МНОГО удалений таблиц/сужэний их сегментов? Или одна удаляется, но на тысячи сегментов?

А, слушай, туплю что-то replay_lag — на ведомом смотришь? Тут да, есть какие-то шансы, что если COMMIT ужэ одобрен, но долго что-то делает — то WAL дальшэ не идут, ведомый не видит WAL и ты на нём видишь lag.

удалений нет, если и есть то одна запись раз в час. приблизительно такая концепция: select * where id in (1, 2, 3) lock for update update field1 = value1, ... where id = 1 update field2 = value2, ... where id = 2 update field3 = value3, ... where id = 3 insert into another_table update another_table2 commit

я на мастере вызываю select * from pg_catalog.pg_stat_replication PG 15.4

Кстати, подумалось — сужэния сегментов не в момент COMMIT делаются, так что это не оно. Но удаления таблиц — могут быть...

удаления таблиц точно нет.

Я про удаление таблиц именно, а не записей.

Сегментов таблиц? Индэексов? Реиндэксацыя? vacuum full?

А вообще — strace на него, и смотреть, над чем задумался.

strace на "головной процесс ПГ" или на walreceiver ?

commit waiting for wal/log коммиты ждут принятия вала на реплике видимо.

Да на всех по очереди. Я бы для начала выяснил — какого чёрта COMMIT висит в active, а не переходит в idle почти мгновенно.

хороший, вопрос.

Ах, да, у тебя жэ сейчас synchronous , replay...

видимо что-то типа того, о чём я три недели назад писал? ну, когда реплика теряла мастер, а после восстановления коннекта не забирала WAL'ы, пока с уже имевшимися replay не доделала...

Вряд ли. У него-то наборот synchronous = ... apply, так что неприменённых WAL не можэт быть много.

Слушай, а там на ведомом нет max_standby_streaming_delay ? Если есть, и нет (или протух по max_что-то там) hot_standby_feedback — то понятно, ведущий ждёт ведомого, ведомый получил WAL, который при apply помешает одной из его транзакцый — и ждёт, пока эта транзакцыя завершытся.

max_standby_streaming_delay = 5 hot_standby_feedback = off

Показали бы Вы все поля записи pg_stat_activity для "зависшего" backend, что ли...

он в статусе wait_event - IPC - SyncRep

ждет когда синхранная реплика ответит

это я понял, только я не понимаю что вызывает "Лаг " синх реплики.

synchronous_commit = remote_apply — более жёсткий уровень чем просто on, то есть включив его вы замедлили commit на мастере, а не ускорили

да что угодно, сеть, диск, synchronous_commit

да я к этому и пришёл, в режиме ON отставанние реплики доходило до 20-ти часов.

ну значит реплика медленнее мастера :-)

я тоже думал про это, смотрел скорость дисков, разницу, даже менял местами реплику и мастер

ну во вервых должно быть главное правило, если синхронная репликация то должно быть не менее 2х реплик, это даже в доке написано. и поставить режим что бы он ожидал подтверждения от хотя бы от одной

мож там индексов каких-то не хватает, которые есть/работают на мастере, а на реплике нет?

Не должно, откуда вы это вообще взяли?

а как, при потоковой репликации, может не работать индекс ? Да и при чем тут индекс, если реплика находится только в лишь наполнении WAL

перепутал, у вас физическая же, угу

Не можэт, там физическая реплика.

это если бэкапа нет видимо "Нормального".

Скорее — если высокая доступность сервиса очень важна. Тогда да, тогда аппаратная конфигурацыя должна начинаться с трёх серверов, и на все три должно всё литься, и какое-то управление всем этим нужно (хотя такое). (Но в большынстве случаев, когда людям нужна реплика — это не настолько всё существенно).

а swap выключен на реплике?