Re: Configuring synchronous replication
От | Robert Haas |
---|---|
Тема | Re: Configuring synchronous replication |
Дата | |
Msg-id | AANLkTinWfir_ZFdQ9onv-Dv_VwCyDJq+XgWXAejsX85-@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Configuring synchronous replication (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On Fri, Sep 17, 2010 at 8:43 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers >> can be seen as important special cases of this. > > I think that we should skip quorum commit at the first phase > because the design seems to be still poorly-thought-out. > > I'm concerned about the case where the faster synchronous standby > goes down and the lagged synchronous one remains when n=1. In this > case, some transactions marked as committed in a client might not > be replicated to the remaining synchronous standby yet. What if > the master goes down at this point? How can we determine whether > promoting the remaining standby to the master causes data loss? Yep. That issue has been raised before, and I think it's quite valid. That's not to say the feature isn't valid, but I think trying to include it in the first commit is going to lead to endless wrangling about design. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: