Re: Investigate postgres 9.6.3 repmgr lag 4.0.4

Поиск
Список
Период
Сортировка
От Mariel Cherkassky
Тема Re: Investigate postgres 9.6.3 repmgr lag 4.0.4
Дата
Msg-id CA+t6e1mwWg0SCR0d=0fH-+YxnLwjB-_UKkhvGEvsGM9MS8jFkw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Investigate postgres 9.6.3 repmgr lag 4.0.4  (Rui DeSousa <rui@crazybean.net>)
Ответы Re: Investigate postgres 9.6.3 repmgr lag 4.0.4  (Rui DeSousa <rui@crazybean.net>)
Re: Investigate postgres 9.6.3 repmgr lag 4.0.4  (Jerry Sievers <gsievers19@comcast.net>)
Список pgsql-admin
Hi all,
it happened again. The weird thing is that when I query pg_stat_replication I see only one slave(the one that is still synced) and I dont see the second one. Moreover,  I dont see anything in the repmgr log of the primary and in the slave regarding the disconnection...

2018-06-25 17:21 GMT+03:00 Rui DeSousa <rui@crazybean.net>:


On Jun 25, 2018, at 2:44 AM, Mariel Cherkassky <mariel.cherkassky@gmail.com> wrote:

 "have it fail over to using the archived WALs instead of full database restore" How do I configure this ?


With Postgres replication, it’s configured it in the recovery.conf file using the “restore_command”.  It would amount to a some script that connect into your backups and pulls the requested WAL file.


When you say no firewall; that is bit confusing and I’m left assuming that the nodes are on the same subnet?  I normally only use replication slots with either a backup solution or a replia that is going over a WAN.  I am bit perplex why replication would fall that far behind on a local network (send lag not replay lag).  What is the interconnect; is it gigabit or 10g and what the volume of WALs being generated? Might have a network related issue here.

I haven’t used repmgr; thus I can’t help there.


В списке pgsql-admin по дате отправления:

Предыдущее
От: Fabio Pardi
Дата:
Сообщение: Re: Server Crash
Следующее
От: "Anjul Tyagi"
Дата:
Сообщение: Re: Server Crash