Обработка идентификатора транзакции Postgres для не пользовательских таблиц - PullRequest
Новая
       11

Обработка идентификатора транзакции Postgres для не пользовательских таблиц

0 голосов
/ 10 декабря 2018

Я был подвержен риску столкновения с идентификатором транзакции в большом кластере Postgres 10 из-за длительной транзакции, которая не простаивала (хотя на самом деле это было в некотором смысле, потому что она зависла в активном состоянии из-за проблемыс FDW Cassandra, который использовался в запросе).Я поймал это вовремя и с огромным использованием vacuum freeze смог вернуть все под контроль ... возможно.

Все выглядит хорошо на уровне базы данных: 

warehouse=# SELECT datname, age(datfrozenxid) FROM pg_database;
  datname  |   age
-----------+----------
 postgres  | 85253797
 template1 | 85253797
 template0 | 85253797
 warehouse | 89423564
 repmgr    | 85253797
(5 rows)

, ноЯ все еще вижу их в журналах и испытываю проблемы с репликацией (в настоящее время отключена, пока что-то не исправлено): 

WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.

Просматривая различные базы данных с помощью этого запроса, я вижу что-то относительно: xid Право на возрастдо предела обтекания, но все для вещей, которые не могут быть vacuum freeze ', как индексы, последовательности и системные таблицы: 

select relname, age from (select relname, age(relfrozenxid) age from pg_class) a order by age desc;
                  relname                  |    age
-------------------------------------------+------------
 user_mappings                             | 2147483647
 pg_stat_sys_indexes                       | 2147483647
 pg_stat_user_indexes                      | 2147483647
 pg_statio_all_indexes                     | 2147483647
 pg_statio_sys_indexes                     | 2147483647
 ...

Был перезапуск как часть восстановления после этого, потому что этоЭто был единственный способ очистить застрявший запрос, так что я не думаю, что у меня все еще есть что-то, что может вызывать высокие xids, такие как долгоживущие подготовленные операторы, временные таблицы и т. д., поэтому мне не ясно, что вызываетпроблема.

Итак, пара вопросов, связанных со всем этим:

  1. Это проблема (помимо генерации множества раздражающих сообщений об ошибках)?
  2. Могу ли я что-нибудь с этим сделать?
  3. Может ли это помешать репликации, когда я теперь не могу получить реплику, которая будет захвачена (всегда показывает постоянный поток сообщений об ошибках на первичной и реплике онедостающие WAL)?

1 Ответ

0 голосов
/ 10 декабря 2018

Все таблицы, которые вы показываете, являются представлениями, и возраст 2147483647 просто отражает, что для них relfrozenxid равно 0.

В представлениях нет кортежей, и им не нужно VACUUM, поэтому они ложныположительные.

Можете ли вы определить, что именно вызывает предупреждение?

Есть вещи, которые блокируют VACUUM и переживают перезапуск: слоты репликации и подготовленные транзакции.

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

...