Re: Issues with Quorum Commit
От | Heikki Linnakangas |
---|---|
Тема | Re: Issues with Quorum Commit |
Дата | |
Msg-id | 4CAC3A90.6040007@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Issues with Quorum Commit (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Issues with Quorum Commit
|
Список | pgsql-hackers |
On 06.10.2010 11:49, Fujii Masao wrote: > On Wed, Oct 6, 2010 at 5:17 PM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> Sure, but it's not the synchronous aspect that increases availability. It's >> the replication aspect, and we already have that. Making the replication >> synchronous allows zero data loss in case the master suddenly dies, but it >> comes at the cost of availability. > > Yep. But I mean that the synchronous aspect is helpful to increase the > availability of the system which requires no data loss. In asynchronous > replication, when the master goes down, we have to salvage the missing > WAL for the standby from the failed master to avoid data loss. This would > take very long and decrease the availability of the system which doesn't > accept any data loss. Since the synchronous doesn't require such a salvage, > it can increase the availability of such a system. In general, salvaging the WAL that was not sent to the standby yet is outright impossible. You can't achieve zero data loss with asynchronous replication at all. > If we want only no data loss, we have only to implement the wait-forever > option. But if we make consideration for the above-mentioned availability, > the return-immediately option also would be required. > > In some (many, I think) cases, I think that we need to consider availability > and no data loss together, and consider the balance of them. If you need both, you need three servers as Simon pointed out earlier. There is no way around that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: