From: | Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7803: Replication Problem(no master is there) |
Date: | 2013-01-11 12:18:09 |
Message-ID: | 50F00301.1060301@po.ntts.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
>> hi, I'm playing with Synchronous Replication on PostgreSQL 9.2.2.
>> And I saw a strange behavior.
>
> Unless you left out something, the configuration you described
> actually sets up asynchronous replication.
>
Thank you for the comment.
I was thinking to promote one of them and set
synchronous_standby_names = 'sby' and reload configure file.
Before that, I noticed the issue.
>> =================================================================
>> [issues]
>> two standbys are connected on each other, but
>> no master is there.
>> ...
>> =================================================================
>>
>> I did not see the situation like above on PostgreSQL 9.1.7.
>>
>> Is this intended change?
>
> In 9.1, this scenario was impossible because you could not connect a
> standby to another standby. In 9.2, that's allowed. It's a new feature
> called "cascading replication", see
> http://www.postgresql.org/docs/9.2/static/warm-standby.html#CASCADING-REPLICATION.
>
> With that feature, it's indeed possible to form a cycle of standby
> servers connected to each other. There was just a long discussion on
> pgsql-hackers on whether we should try to detect that scenario [1],
> but the consensus seems to be that we should not. It would be
> difficult to implement such detection, and sometimes it's useful to
> have such a cycle, as a transient state at a failover, for example.
Sorry, I had not read the discussion and have reported it again.
And I understand it's hard to detect cyclic situation.
>
> So the bottom line is that this is an intended change, and the admin
> will just have to avoid doing that.
OK.
This situation was made by playing, so it's not big problem for now.
>
> This makes me wonder if there should be a GUC to forbid cascading
> replication, though. If you don't want to do cascading replication
> (which is quite rare, I'd say), you could just disable it to avoid a
> situation like this.
I'm not sure but what about adding the parameter("cascade_mode") on
recovery.conf ?
The parameter represents a will to connect to standby server when
starting as standby.
If the parameter is set to on, connect to a server forcely like
PostgreSQL 9.2,
and if the parameter is set to off, connect to the another standby server is
refused like PostgreSQL 9.1.
>
> [1] http://archives.postgresql.org/pgsql-hackers/2012-12/msg01134.php
>
> - Heikki
>
>
regards,
--------
NTT Software Corporation
Tomonari Katsumata
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2013-01-11 13:19:41 | Re: [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception |
Previous Message | Heikki Linnakangas | 2013-01-11 09:25:54 | Re: BUG #7803: Replication Problem(no master is there) |