проверить статус репликации postgres

Может ли кто-нибудь предложить шаги для проверки состояния репликации pgsql и когда сказать, что репликация не происходит должным образом?

Мы используем потоковую репликацию с pgsql9.0 и pgsql9.4.

Спасибо.


postgresql database-replication
person Dino Daniel    schedule 13.04.2017    source источник
comment
stackoverflow.com/ вопросы/28323355/   -  person Vao Tsun    schedule 13.04.2017

Ответы (3)


arrow_upward
31
arrow_downward

Обычно я использую следующие SQL-запросы для проверки состояния Postgres v11.

На мастере:

select * from pg_stat_replication;

На реплике (потоковая репликация в моем случае):

select * from pg_stat_wal_receiver;
person Alexey    schedule 12.01.2019
comment
Для вертикального вывода замените ; на \x\g\x. - person x-yuri; 24.10.2020

arrow_upward
26
arrow_downward

На вашем мастере pg_stat_replication предоставляет данные о текущей репликации:

select client_addr, state, sent_location, write_location,
        flush_location, replay_location from pg_stat_replication;

В postgresql v10:

select client_addr, state, sent_lsn, write_lsn,
    flush_lsn, replay_lsn from pg_stat_replication;
person Reinsbrain    schedule 27.04.2017
comment
Хорошо, а что не так, если приведенный выше запрос возвращает 0 строк? - person gvasquez; 17.07.2017
comment
0 строк означает, что на вашем сервере не настроена репликация. При правильной настройке должны быть получены строки, но это не означает, что у вас есть репликация, так как ведомое устройство может не подключаться (проверьте столбец «состояние») - person Reinsbrain; 18.07.2017
comment
мммм... у нас репликация работала нормально, но она не удалась, теперь она не показывает строк, см.: dba.stackexchange.com/questions/180062/ - person gvasquez; 18.07.2017

arrow_upward
16
arrow_downward

Показать статус репликации в PostgreSQL

на сервере

postgres=# select usename,application_name,client_addr,backend_start,state,sync_state from pg_stat_replication ;

usename   | application_name |  client_addr   |         backend_start         |   state   | sync_state 
------------+------------------+----------------+-------------------------------+-----------+------------
replicator | walreceiver      | 192.168.10.132 | 2018-07-06 06:12:20.786918+03 | streaming | async
(1 row)

на клиенте

postgres=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
 (1 row)


postgres=# select pg_last_xlog_receive_location();
 pg_last_xlog_receive_location 
-------------------------------
 0/540C1DB8


postgres=# select pg_last_xlog_replay_location();
 pg_last_xlog_replay_location 
------------------------------
 0/540C1DB8
 (1 row)

postgres=#    SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location()
                  THEN 0
                ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
              END AS log_delay;
 log_delay 
-----------
 0
 (1 row)
person truth    schedule 10.07.2018
comment
на postgres 10 это не работает полностью, но SELECT pg_last_xact_replay_timestamp(); дает полезную информацию! - person user39950; 12.07.2018
comment
Сравните статусы master и slave в одном запросе: select pg_last_xlog_receive_location(), pg_last_xlog_replay_location(), pg_last_xact_replay_timestamp(), CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp()) END AS log_delay; - person Sergey Nemchinov; 14.04.2020
comment
Чтобы проверить главный IP от подчиненного, dba.stackexchange.com/a/45062/123063 - person GypsyCosmonaut; 27.05.2020