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)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: BUG #7803: Replication Problem(no master is there)  (Tomonari Katsumata <katsumata.tomonari@po.ntts.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: katsumata.tomonari@po.ntts.co.jp
Дата:
Сообщение: BUG #7803: Replication Problem(no master is there)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: BUG #7803: Replication Problem(no master is there)