LINUX.ORG.RU
Форум — Admin  

Postrgesql 9.1 с репликацией - проблема с длинными запросами к Slave

 , ,


1

2

Есть конфигурация из двух серверов. Настроена streaming-репликация. Нагрузка на первичный сервер на изменение и удаление высокая. Решили перенести статистику на slave. Однако, при длинных запросах происходит их сброс с выдачей ошибки.

Описание проблемы, в общем-то есть в документации по Postgresql - http://www.postgresql.org/docs/9.0/static/hot-standby.html «Application of a vacuum cleanup record from WAL conflicts with standby transactions whose snapshots can still „see“ any of the rows to be removed.»

Судя по дальнейшему описанию, это можно решить, например, командой VACUUM FREEZE. Но я не понял, как после отработки запроса вернуть нормальную работу автовакуума.

Может быть кто-то сталкивался с этой проблемой и может подсказать работающий вариант решения?

max_standby_archive_delay = 3000s       # max delay before canceling queries
                                        # when reading WAL from archive;
                                        # -1 allows indefinite delay
max_standby_streaming_delay = 3000s     # max delay before canceling queries
                                        # when reading streaming WAL;
                                        # -1 allows indefinite delay
wal_receiver_status_interval = 10s      # send replies at least this often
                                        # 0 disables
hot_standby_feedback = on               # send info from standby to prevent
                                        # query conflicts

Запросы дольше чем max_standby_streaming_delay будут откатываться на слейве. Это происходит потому что в случае standby запрос может конфликтовать с накатом лога, в этом случае чтобы не останавливать накат лог дольше чем на max_standby_streaming_delay приходится сбрасывать запросы.

ventilator ★★★
() 
set vacuum_freeze_min_age  TO '0';

а потом 

set vacuum_freeze_min_age  TO DEFAULT;
Должно делать тоже самое что и vacuum freeze. Но этот способ я не пробовал, вариант с увеличением max_standby_streaming_delay мне вполне подходит.

ventilator ★★★
()
Ответ на: комментарий от ventilator

Спасибо! Уже нашел параметр hot_standby_feedback. По идее, если он включен, слэйв должен информировать мастера о запросах и мастер должен «придерживать» удаление неактуальных версий записей нужных для этого запроса.

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy

Однако, по факту, в логе слэйва все-равно возникает сообщение о ресете коннекта если значение max_standby_archive_delay не очень большое. Тогда не совсем понятно на что влияет параметр hot_standby_feedback.

UncleAndy ★★★
() автор топика
Ответ на: комментарий от UncleAndy 
SELECT * from pg_stat_database_conflicts ;

hot_standby_feedback решает только проблему с VACUUM. Кроме вакуума к конфликтам может приводить все что требует Access Exclusive locks (LOCK TABLE,DROP TABLE,ALTER TABLE,TRUNCATE, REINDEX,CREATE INDEX,CLUSTER, DROP TABLESPACE, DROP DATABASE);

ventilator ★★★
()
Ответ на: комментарий от ventilator

По этому запросу обнаружилось несколько конфликтов в колонке confl_snapshot. Я так понимаю, что это происходит из-за активного изменения данных, участвующих в запросе на слэйве?

UncleAndy ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin