From: | Martín Marqués <martin(at)2ndquadrant(dot)com> |
---|---|
To: | Pekka Rinne <tsierkkis(at)gmail(dot)com> |
Cc: | Ian Barwick <ian(at)2ndquadrant(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: upgrade to repmgr3 |
Date: | 2016-08-11 11:55:56 |
Message-ID: | CAPdiE1zauZjmWp9MU5oZC3AXztSnj+ese9D-YkK5HzBRW5JkeA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
2016-08-11 7:54 GMT-03:00 Pekka Rinne <tsierkkis(at)gmail(dot)com>:
>>
>> Do you by chance have synchronous replication set? That ps output alone
>> doesn't say much, but being stuck on COMMIT normally points to failure
>> to sync the replication on a standby.
>>
>
> Yeah, I learned that repmgr3 actually writes to DB during promote. Repmgr2
> does not do that. And if the failed master itself is on the synchronized
> replicas list then the promote command hangs in commit as its not possible
> to sync to that failed node. Solution seemed to be to temporarily comment
> out synchronized replicas from postgresql.conf in new master and reload
> configfile. Then the promote command returns in command line.
Solution would be having at least 2 standbys listed in
synchronous_standby_names. With only one node name there, if the
standby goes down, all the transactions that make changes will hang at
commit execution.
Regards,
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Rakesh Kumar | 2016-08-11 12:11:32 | Serializable read and blocking |
Previous Message | Pekka Rinne | 2016-08-11 10:54:42 | Re: upgrade to repmgr3 |