pg_create_logical_replication_slot зависает бесконечно из-за старого процесса Walsender

Question

Я тестирую логическую репликацию между 2 базами данных PostgreSQL 11 для использования в нашей работе (я смог установить его благодаря этому ответу - Логическая репликация PostgreSQL - создание подписки зависает ), и она работала хорошо.

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

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

Я удалил подписку на master (я все еще только тестирую) и попытался повторить весь процесс с новым слотом логической репликации, но я столкнулся со странной ситуацией.

Я не могу создать новый слот логической репликации с новым именем. Процесс, работающий в старом слоте логической репликации, все еще активен и показывает wait_event_type=Lock и wait_event=transaction.

Когда я пытаюсь использовать pg_create_logical_replication_slot для создания нового слота логической репликации, я получаю похожую ситуацию. Новый слот создан - я вижу его в pg_catalog, но он помечен как активный для PID сеанса, который выдал эту команду, и команда зависает на неопределенный срок. Когда я проверяю процессы, я вижу эту команду активной с теми же ожидающими значениями Блокировка / транзакция.

Я попытался активировать параметр "lock_timeout" в postgresql.conf и перезагрузить конфигурацию, но это не помогло.

Убийство этого старого процесса зависания, скорее всего, обрушит весь postgres, потому что это процесс "walsender". Это видно в списке процессов еще с IP реплики со статусом «idle wating».

Я попытался найти некоторые параметры, которые могли бы помочь заставить postgres остановить этот вальсендер. Но настройки wal_keep_segments или wal_sender_timeout ничего не изменили. Я даже пытался остановить реплику на более длительное время - безрезультатно.

Есть ли способ что-то сделать в этой ситуации, не перезапуская весь postgres? Например, принудительное превышение тайм-аута для Walsender или блокировка транзакции и т. Д. *

Потому что, если что-то подобное произойдет на производстве, я не смогу использовать рестарт или любую другую "грубую силу". Спасибо ...

UPDATE: "Walsender" процесс "вымер" через некоторое время, но журнал ничего не показывает об этом, поэтому я не знаю, когда именно это произошло. Я могу только догадываться, это зависит от параметров tcp_keepalives_ *. По умолчанию в Debian 9 время простоя составляет 2 часа. Поэтому я попытался установить эти параметры в postgresql.conf и увидим в следующих тестах.

Answer 1

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

Так что я действительно не знаю ответа, за исключением «подождать, пока процесс walsender на master не умрет», - что, скорее всего, может зависеть от настроек tcp_keepalives_ *. Поэтому я рекомендую установить для них разумные значения в postgresql.conf, потому что значения по умолчанию в ОС обычно слишком велики.

На самом деле мы используем его в наших больших аналитических базах данных (установленных как в PostgreSQL, так и в ОС) из-за схожих проблем. Программы Golang и nodejs, время от времени вычисляющие статистику, не могли распознать, что сеанс базы данных заканчивался или прекращался в некоторых случаях, и зависали до тех пор, пока ОС не прервала соединение через 2 часа (по умолчанию в Debian). Все это, казалось, всегда было связано с проблемами сетевого взаимодействия. При правильной настройке tcp_keepalives_ * в случае проблем настройка намного быстрее.

После того, как старый процесс Walsender умирает на мастере, вы можете повторить все шаги, и он должен работать. Похоже, мне просто не повезло вчера ...