Re: Issues with Quorum Commit
От | Fujii Masao |
---|---|
Тема | Re: Issues with Quorum Commit |
Дата | |
Msg-id | AANLkTimTRDEjxPq1uYJ1JQR3F4--Vs5wJinunkePAaWu@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Issues with Quorum Commit (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Issues with Quorum Commit
|
Список | pgsql-hackers |
On Wed, Oct 6, 2010 at 6:00 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > 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. No. That depends on the type of failure. Unless the disk in the master has been corrupted, we might be able to salvage WAL. >> 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. No. That depends on how far you'd like to ensure no data loss. Poeple who use shared disk failover solution with one master and one standby don't such a high durability. They can avoid data loss by using something like RAID to a certain extent. So it's not problem for them to run the master alone after failover happens or standby goes down. But something like RAID cannot increase availability. Synchronous replication is solution for that purpose. Of course, if we are worried about running the master alone, we can increase the number of standbys. Furthermore, if we'd like to avoid data loss from the disaster which can destroy all the servers at the same time, we might need to increase the standbys further and locate some of them in the remote site. Please imagine that "return-immediately (i.e., timeout = small)" is useful for some use cases. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: