pg_create_logical_replication_slot зависает на неопределенное время из-за старого процесса Walsender
Я тестирую логическую репликацию между двумя базами данных 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 или блокировка транзакции и т. Д.
Потому что, если что-то подобное произойдет на производстве, я не смогу использовать рестарт или любую другую "грубую силу". Спасибо...
ОБНОВЛЕНИЕ: процесс "Walsender" через некоторое время "вымер", но в журнале ничего об этом не видно, поэтому я не знаю, когда именно это произошло. Я могу только догадываться, это зависит от параметров tcp_keepalives_*. По умолчанию в Debian 9 время простоя составляет 2 часа. Поэтому я попытался установить эти параметры в postgresql.conf и увидим в следующих тестах.
1 ответ
Как ни странно, сегодня все работает без проблем, и как бы я ни пытался имитировать вчерашние проблемы, я не могу. Возможно, в облачном центре обработки данных были некоторые проблемы с сетевым взаимодействием - у нас также были некоторые тайм-ауты при подключении к другим базам данных.
Поэтому я действительно не знаю ответа, за исключением "дождаться, пока процесс walsender на master не умрет", - что, скорее всего, может зависеть от настроек tcp_keepalives_*. Поэтому я рекомендую установить для них разумные значения в postgresql.conf, потому что значения по умолчанию в ОС обычно слишком велики.
На самом деле мы используем его в наших больших аналитических базах данных (установленных как на PostgreSQL, так и на ОС) из-за схожих проблем. Программы Golang и nodejs, время от времени вычисляющие статистику, не могли распознать, что сеанс базы данных заканчивался или прекращался в некоторых случаях, и зависали до тех пор, пока ОС не прервала соединение через 2 часа (по умолчанию в Debian). Все это, казалось, всегда было связано с проблемами сетевого взаимодействия. При правильной настройке tcp_keepalives_* реакция будет намного быстрее в случае проблем.
После того, как старый процесс Walsender умирает на мастере, вы можете повторить все шаги, и он должен работать Похоже, мне просто не повезло вчера...