Re: BUG #7803: Replication Problem(no master is there)
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #7803: Replication Problem(no master is there) |
Дата | |
Msg-id | 50EFCFF5.4040109@vmware.com обсуждение исходный текст |
Ответ на | BUG #7803: Replication Problem(no master is there) (katsumata.tomonari@po.ntts.co.jp) |
Ответы |
Re: BUG #7803: Replication Problem(no master is there)
Re: BUG #7803: Replication Problem(no master is there) |
Список | pgsql-bugs |
On 11.01.2013 06:09, katsumata.tomonari@po.ntts.co.jp wrote: > The following bug has been logged on the website: > > Bug reference: 7803 > Logged by: Tomonari Katsumata > Email address: katsumata.tomonari@po.ntts.co.jp > PostgreSQL version: 9.2.2 > Operating system: RHEL 5.3 x86_64 > Description: > > 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. > ================================================================= > [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. So the bottom line is that this is an intended change, and the admin will just have to avoid doing that. 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. [1] http://archives.postgresql.org/pgsql-hackers/2012-12/msg01134.php - Heikki
В списке pgsql-bugs по дате отправления: