|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
На кластере (1 мастер, 2 стендбая) наблюдается следующая картина: 1. Начинает расти лаг репликации между мастером и одним стендбаем. 2. Иду на сервер со стенбаем и вижу SELECT запрос, который читает данные из таблицы T. К этому времени запрос выполняется, скажем, один час. 3. По списку процессов на standby вижу, что WAL'ы получены с мастера, но не накатываются (в ps статус "waiting"). 4. Смотрю на эту таблицу на местере и вижу что как раз перед тем, как начал расти лаг (скажем, за минуту до этого), по таблице T отработал автовакум. 5. Как только убиваю запрос на standby сервере WAL'ы начинают накатываться и лаг исчезает. Настройки: Код: css 1. 2. 3. 4. 5.
Версия 9.5.13. Репликация streaming, асинхронная, используются слоты репликации. Вопрос - почему строки могут чиститься н мастере (все симптомы говорят о том, что это именно так). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 11:01 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755a, Как правило реплика может отставать по причинам нагрузки в сети, слабые диски на реплике, ну или аномально высокая активность на мастере которая порождает тонны WAL , которая реплика не успевает переварить. Попробуйте оценить запросом в момент проблемы на мастере: SELECT client_addr AS client, usename AS user, application_name AS name, state, sync_state AS mode, (pg_xlog_location_diff(pg_current_xlog_location(),sent_location) / 1024)::int as pendingKB, --network? (pg_xlog_location_diff(sent_location,write_location) / 1024)::int as writeKB, --disks? (pg_xlog_location_diff(write_location,flush_location) / 1024)::int as flushKB, --disks? (pg_xlog_location_diff(flush_location,replay_location) / 1024)::int as replayKB, --disks/cpu? (pg_xlog_location_diff(pg_current_xlog_location(),replay_location))::int / 1024 as total_lag_KB FROM pg_stat_replication ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 13:51 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
gav21bff7755a, Как правило реплика может отставать по причинам нагрузки в сети, слабые диски на реплике, ну или аномально высокая активность на мастере которая порождает тонны WAL , которая реплика не успевает переварить. Попробуйте оценить запросом в момент проблемы на мастере: FROM pg_stat_replication Мне кажется, вы невнимательно прочитали моё сообщение. Причём тут высокая нагрузка на мастере? Говорю же, WAL'ы не пишутся, процесс подвис из-за standby recovery конфликта. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 14:47 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
Прикладываю картинку, которая отлично иллюстрирует описанное мной. Внизу фиолетовый - это vacuum на мастере. а зелёный - длинный запрос на standby Видно, что как только vacuum заканчивается, начинает расти лаг а как только заканчивается длинный запрос на standby, лаг уменьшается. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 14:53 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755aВопрос - почему строки могут чиститься н мастере (все симптомы говорят о том, что это именно так). А почему бы им не чистится?.. Это типичная ситуация с запросами на реплике, если они идут по таблицам, которые активно пользуются на мастере. Надо выбирать: или долгие запросы, или актуальная реплика. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 15:04 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755aВопрос - почему строки могут чиститься н мастере (все симптомы говорят о том, что это именно так). Тут все сложнее. Вы попали на ситуацию когда не мертвые строки чистятся а autovacuum в какой то из таблиц пытается обрезать свободное место в конце таблицы (а это требует коротокго acccessexclusive lock который wal replay не может взять если у вас есть долгая транзакция на реплике зацепившая эту таблицу). См обсуждение: https://www.postgresql.org/message-id/flat/c9374921e50a5e8fb1ecf04eb8c6ebc3@postgrespro.ru и https://www.postgresql.org/message-id/flat/CAHGQGwE5UqFqSq1=kV3QtTUtXphTdyHA-8rAj4A=Y e4kyp3BQ@mail.gmail.com в общем в текущих версиях не лечится. Я бы рекомендовал управлять через max_standby_streaming_delay если надо очень отсутствие лага. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 16:00 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
Maxim Boguk, а если это будет синхронная реплика? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 17:12 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
gav21Maxim Boguk, а если это будет синхронная реплика? А синхронность реплики это не про wal replay а только на ЗАПИСЬ принятого wal на реплике на диск. Синхронная реплика ну совсем не гарантирует что на реплике и мастере вы одно и тоже в select получите. Так что получится ровно тоже самое с асинхронной репликой. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 17:23 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
Maxim Boguk, а как же режим remote_apply, который как я понимаю гарантирует видимость строк на реплике? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 17:28 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
Maxim Bogukbff7755aВопрос - почему строки могут чиститься н мастере (все симптомы говорят о том, что это именно так). Тут все сложнее. Вы попали на ситуацию когда не мертвые строки чистятся а autovacuum в какой то из таблиц пытается обрезать свободное место в конце таблицы (а это требует коротокго acccessexclusive lock который wal replay не может взять если у вас есть долгая транзакция на реплике зацепившая эту таблицу). См обсуждение: https://www.postgresql.org/message-id/flat/c9374921e50a5e8fb1ecf04eb8c6ebc3@postgrespro.ru]https://www.postgresql.org/message-id/flat/c9374921e50a5e8fb1ecf04eb8c6ebc3@postgrespro.ru и https://www.postgresql.org/message-id/flat/CAHGQGwE5UqFqSq1=kV3QtTUtXphTdyHA-8rAj4A=Y e4kyp3BQ@mail.gmail.com в общем в текущих версиях не лечится. Я бы рекомендовал управлять через max_standby_streaming_delay если надо очень отсутствие лага. Максим, спасибо вас за ответ. Я читал про truncate но не думал, что это когда-нибудь коснётся меня... Вы случайно не знаете, сделали ли с этим что-нибудь в 11 версии? Вроде разговоры шли об этом. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 18:04 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755a, Да, я пропустил упоминание hot_standby_feedback в теме :( Патч всё ещё в работе, в 11-й точно ничего не появилось вокруг AEL блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 18:23 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755a, Оба упомянутых обсуждения были уже после feature freeze, но хотя что-то как багфикс ещё возможно что портируют. Соответствующая запись в commitfest для патча: https://commitfest.postgresql.org/20/1683/ Всё ещё Needs review. И судя по обсуждению есть большие вопросы к корректности предложенного алгоритма, оставшиеся авторами патча без ответа. radix-tree патча сейчас тоже ещё пока нет, до feature freeze 12 осталось около 4 месяцев, маловероятно. Ну и его backpatch не будет точно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 18:28 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
vyegorovbff7755a, Да, я пропустил упоминание hot_standby_feedback в теме :( Патч всё ещё в работе, в 11-й точно ничего не появилось вокруг AEL блокировок. Виктор, а почему, например, не решили добавить опцию "не транкейтить таблицу при lazy vacuum"? Не смертельно ведь было бы. И пользуясь случаем - я нашёл, где берётся блокировка, когда обрезается таблица на master ( внутри lazy_truncate_heap() ), но не нашёл где это происходит во время проигрывания WAL (там как-то с smgr всё сложно). Не могли бы подсказать мне, для удовлетворения моего любопытсвта? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 18:32 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
Melkij, я смотрю в этом патче даже новый вид блокировки добавляется, настолько всё серьёзно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 18:36 |
|
Автовакум на мастере чистит строки нужные реплике при включенном hot_standby_feedback
|
|||
---|---|---|---|
#18+
bff7755aя смотрю в этом патче даже новый вид блокировки добавляется, настолько всё серьёзно. Так основная проблема как раз с тем, чтобы обеспечить удаление страниц на диске и в памяти непротиворечиво и безопасно для конкурентных процессов. bff7755aя нашёл, где берётся блокировка, когда обрезается таблица на master ( внутри lazy_truncate_heap() ), но не нашёл где это происходит во время проигрывания WAL (там как-то с smgr всё сложно). Не могли бы подсказать мне, для удовлетворения моего любопытсвта Вот здесь, блокировка пишется в WAL (XLogInsert из LogAccessExclusiveLocks) и читается затем: https://github.com/postgres/postgres/blob/REL9_5_STABLE/src/backend/storage/ipc/standby.c#L785 (по идее, с gdb не проверял) bff7755aВиктор, а почему, например, не решили добавить опцию "не транкейтить таблицу при lazy vacuum"? Не смертельно ведь было бы. Выпиливать потом настройки довольно больно и ожидался патч с другой реализацией buffer mapping, как минимум решили подождать. Но что-то не видно активности. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2018, 19:01 |
|
|
start [/forum/topic.php?fid=53&fpage=48&tid=1995499]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 256ms |
total: | 400ms |
0 / 0 |