Re: BUG #7803: Replication Problem(no master is there)
| От | Tomonari Katsumata |
|---|---|
| Тема | Re: BUG #7803: Replication Problem(no master is there) |
| Дата | |
| Msg-id | 50F00301.1060301@po.ntts.co.jp обсуждение исходный текст |
| Ответ на | Re: BUG #7803: Replication Problem(no master is there) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Ответы |
Re: BUG #7803: Replication Problem(no master is there)
|
| Список | 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
В списке pgsql-bugs по дате отправления: