Thread: DRDB risk factors?

DRDB risk factors?

From
Kevin Kempter
Date:
Hi List ;

per considering DRDB as a replication solution in a failed master node
scenario, is there a risk of loosing not only in-flight transactions but alos
un-sync'd buffer-pool dirty pages?

If so, how might I minimize this risk ?

Thanks in advance...

Re: DRDB risk factors?

From
Ben
Date:
If it's been fsync'd to a DRDB device, it's been fsync'd to both systems.
I think that answers your question...

On Wed, 30 May 2007, Kevin Kempter wrote:

> Hi List ;
>
> per considering DRDB as a replication solution in a failed master node
> scenario, is there a risk of loosing not only in-flight transactions but alos
> un-sync'd buffer-pool dirty pages?
>
> If so, how might I minimize this risk ?
>
> Thanks in advance...
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

Re: DRDB risk factors?

From
Hannes Dorbath
Date:
On 30.05.2007 23:31, Kevin Kempter wrote:
> per considering DRDB as a replication solution in a failed master node
> scenario, is there a risk of loosing not only in-flight transactions but alos
> un-sync'd buffer-pool dirty pages?
>
> If so, how might I minimize this risk ?

If you have DRBD using protocol C and fsync enabled in PG you don't lose
a single commit. That is true for any ACID conform application.

Be sure to you have your hardware right. Running DRBD on fsync/fua lying
hardware is committing suicide. I can't stress that enough.


--
Regards,
Hannes Dorbath