самый старый xmin далеко в прошлом - Postgresql 9.4.4 - PullRequest
Новая
       61

самый старый xmin далеко в прошлом - Postgresql 9.4.4

1 голос
/ 23 апреля 2020

У меня есть postgresql 9.4.4 в производственной среде. Уже через 3 недели я получаю много сообщений в pg_log: 

<:::2020-04-06 23:59:59 BRT::2020-04-06 23:59:55 BRT:72350>|LOG:  automatic vacuum of table "template0.pg_catalog.pg_range": index scans: 0
    pages: 0 removed, 1 remain
    tuples: 0 removed, 6 remain, 0 are dead but not yet removable
    buffer usage: 20 hits, 0 misses, 0 dirtied
    avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
<:::2020-04-07 00:00:00 BRT::2020-04-06 23:59:59 BRT:72428>|WARNING:  oldest xmin is far in the past
<:::2020-04-07 00:00:00 BRT::2020-04-06 23:59:59 BRT:72428>|HINT:  Close open transactions soon to avoid wraparound problems.

Предупреждения появляются много раз в день, и похоже, что это происходит в вакууме в каждой таблице template0.pg_catalog.

Поиск в других вопросах переполнения стека, я нашел много ответов, но ни один из них не подходит для моего случая.

Говорят, что это может быть 3 вещи:

  1. Неактивный в транзакции, запущенной в течение длительного времени:

Запуск select * from pg_stat_activity где state = 'idle in транзакция' , я получаю только одно соединение в этом состоянии, и оно было открыто сегодня.

Подготовленные транзакции транзакций, которые не были закрыты

Запуск select * from pg_prepared_xacts; , я получил 9 строк и закончил все с ROLLBACK PREPARED 'gid' ;. Итак, у меня сейчас нет готовых транзакций.

Неиспользуемый слот репликации

Запуск select * from pg_replication_slots , я получил только одну строку, и эта репликация используется на другом сервере. 

slot_name;plugin;slot_type;datoid;database;active;xmin;catalog_xmin;restart_lsn
replica;;physical;;;t;2845561097;;584C/CC6604F0

Итак, я не могу уронить этот, потому что он используется. Мои два сервера работают нормально, за исключением этих сообщений в журнале. 

My server:
autovacuum = on 
archive_mode = on
wal_keep_segments = 20
max_wal_senders = 3
max_replication_slots = 3
wal_level = hot_standby
hot_standby = on
archive_command = 'test -f %p && cp %p /opt/postgres/archxlog/%f'

Мой recovery.conf (на другом сервере с резервной репликацией): 

standby_mode = 'on'
primary_conninfo = 'user= host= port= sslmode=disable sslcompression=1'
primary_slot_name = 'replica'

Спасибо за помощь!

РЕДАКТИРОВАТЬ:

Поиск в Google, я нашел этот сайт: http://micronetinternational.com/index.pl/en/00/https/postgrespro.com/list/thread-id/1556972

Говорят, что проблема связана с субоперацией это в ожидании потоковой передачи.

Глядя на папку pg_subtrans , я обнаружил много таких старых файлов. 

ls -lha | more
total 1,4G
drwx------.  2 postgres postgres  92K Abr 27 10:56 .
drwx------. 19 postgres postgres 4,0K Fev 21 16:38 ..
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99B
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99C
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99D
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99E

Моя репликация относится к февралю этого года. Итак, эти файлы не последние. Как лучше всего очистить эту папку?

1 Ответ

1 голос
/ 06 мая 2020

Мне удалось решить проблему;

Я остановил репликацию и отбросил слот репликации. Когда я сделал это, pg_subtrans был очищен, и предупреждение исчезло.

Но я потерял свою репликацию и должен был начать с нуля.

Теперь все работает нормально.

Спасибо, ребята!

...