| From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Samrat Revagade <revagade(dot)samrat(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Subject: | Re: Inconsistent DB data in Streaming Replication |
| Date: | 2013-04-10 16:44:42 |
| Message-ID: | 516596FA.90601@optionshouse.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/10/2013 11:40 AM, Fujii Masao wrote:
> Strange. If this is really true, shared disk failover solution is
> fundamentally broken because the standby needs to start up with the
> shared "corrupted" database at the failover.
How so? Shared disk doesn't use replication. The point I was trying to
make is that replication requires synchronization between two disparate
servers, and verifying they have exactly the same data is a non-trivial
exercise. Even a single transaction after a failover (effectively)
negates the old server because there's no easy "catch up" mechanism yet.
Even if this isn't necessarily true, it's the safest approach IMO.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2013-04-10 16:46:35 | Re: Inconsistent DB data in Streaming Replication |
| Previous Message | Fujii Masao | 2013-04-10 16:40:12 | Re: Inconsistent DB data in Streaming Replication |