Re: pg_stat_replication when standby is unreachable
От | Abhishek Rai |
---|---|
Тема | Re: pg_stat_replication when standby is unreachable |
Дата | |
Msg-id | CA+sC4q5O2FOFS+QVzs41FiZw4ENj62-knJ5DAtYe_NPkSewMwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_replication when standby is unreachable (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
On Wed, May 29, 2013 at 9:16 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 5/28/13 9:42 PM, Abhishek Rai wrote:Then how do you define "live" for your use case?
> Detecting primary health is easy. But what is the best way to know if
> the standby is live? Since this is not a hot-standby, I cannot send
> queries to it.
By a "live standby", I mean that the standby is currently connected to the primary and being used for synchronous replication. It may be lagging (e.g. when in catchup mode), but at least it's connected. This way, when the standby is fully caught up, I can be sure that if I suffer a permanent loss of the master or the replica, I would not lose any transaction which was successfully acknowledged to a client.
No, pg_stat_replication is not an appropriate tool for tracking
> Currently, I'm sending the following query to the primary:
>
> SELECT * from pg_stat_replication();
>
> I've noticed that when I terminate the standby (cleanly or through kill
> -9), the result of above function goes from 1 row to zero rows. The
> result comes back to 1 row when the standby restarts and reconnects. I
> was wondering if there is any kind of guarantee about the results of
> pg_stat_replication as the standby suffers a network partition, and/or
> restarts and reconnects with the primary. Are there any parameters that
> control this behavior?
standbys, for the reasons you point out. You need to track the list of
actual and potential standbys that you are interested in somewhere else.
I see. Thanks for the response.
Actually, pg_stat_replication seemed to be doing almost the exact thing I needed - providing a list of currently successfully connected standbys. And as per my observation, it was getting updated as standbys joined and left, precisely what I wanted. The request for a config parameter was simply to tune how quickly a down standby is reported via pg_stat_replication. But I can live without a configuration param to tune this behavior, as long as there is something in the code based on which I can infer how long it will take for the result of pg_stat_replication to be updated when a standby joins or leaves. I can use these timeouts to configure timeouts in the clustering software.
Actually, pg_stat_replication seemed to be doing almost the exact thing I needed - providing a list of currently successfully connected standbys. And as per my observation, it was getting updated as standbys joined and left, precisely what I wanted. The request for a config parameter was simply to tune how quickly a down standby is reported via pg_stat_replication. But I can live without a configuration param to tune this behavior, as long as there is something in the code based on which I can infer how long it will take for the result of pg_stat_replication to be updated when a standby joins or leaves. I can use these timeouts to configure timeouts in the clustering software.
Thanks,
Abhishek
В списке pgsql-hackers по дате отправления: