Я получаю следующую ошибку при запуске запроса на db PostgreSQL в режиме ожидания. Запрос, который вызывает ошибку, работает нормально в течение 1 месяца, но когда вы запрашиваете более 1 месяца, возникает ошибка.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed
Любые предложения по устранению? Благодаря
Выполнение запросов на сервере с горячим резервированием несколько сложнее - он может выйти из строя, потому что во время запроса некоторые необходимые строки могут быть обновлены или удалены на первичном. Как первичный не знает, что запрос запускается вторично, он думает, что он может очистить (вакуум) старые версии своих строк. Затем вторичный должен повторить эту очистку и вынужден принудительно отменять все запросы, которые могут использовать эти строки.
Более длинные запросы будут отменены чаще.
Вы можете обойти это, начав повторяющуюся транзакцию чтения на первичной основе, которая выполняет фиктивный запрос, а затем сидит без дела, пока реальный запрос запускается на вторичном. Его присутствие предотвратит пылесосы старых версий строк на первичных.
Подробнее об этой теме и других обходных решениях объясняется в разделе "Горячий режим ожидания - обработка конфликтов запросов" в документации.
Нет необходимости запускать незанятые транзакции на ведущем устройстве. В postgresql-9.1 самый прямой способ решить эту проблему - установить
hot_standby_feedback = on
Это позволит мастеру узнать о длинных запросах. Из docs:
Первый вариант - установить параметр hot_standby_feedback, который предотвращает VACUUM от удаления недавно замерших строк и конфликтов очистки не происходит.
Почему это не по умолчанию? Этот параметр был добавлен после начального и это единственный способ, что резервный режим может повлиять на мастера.
Как указано здесь о hot_standby_feedback = on:
Ну, недостатком этого является то, что в режиме ожидания может раздуваться мастер, которые могут быть удивительными для некоторых людей, тоже
И здесь:
С какой настройкой max_standby_streaming_delay? Я бы лучше по умолчанию - -1, чем по умолчанию hot_standby_feedback. Таким образом, что вы в режиме ожидания влияют только на режим ожидания
Итак, я добавил
max_standby_streaming_delay = -1
И не более pg_dump ошибка для нас, и мастер-раздувание:)
Данные таблицы на подчиненном подчиненном сервере горячего резервирования изменяются, когда выполняется длительный запрос. Решение (PostgreSQL 9.1+), чтобы убедиться, что данные таблицы не изменены, заключается в приостановке репликации и возобновлении после запроса:
select pg_xlog_replay_pause(); -- suspend
select * from foo; -- your query
select pg_xlog_replay_resume(); --resume
Не нужно касаться hot_standby_feedback. Как отмечали другие, установка on может размахивать мастером. Представьте, что вы открываете транзакцию на подчиненном устройстве и не закрываете ее.
Вместо этого установите max_standby_archive_delay и max_standby_streaming_delay в какое-то нормальное значение:
# /etc/postgresql/10/main/postgresql.conf on a slave
max_standby_archive_delay = 900s
max_standby_streaming_delay = 900s
Таким образом, запросы на ведомые устройства продолжительностью менее 900 секунд не будут отменены. Если ваша рабочая нагрузка требует более длинных запросов, просто установите эти параметры на более высокое значение.