[DRBD-user] Guarantee write to both nodes

Yuri Ushakov yuri.ushakov at gmail.com
Fri Mar 19 16:24:48 CET 2010

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

I need synchronous replication over network, but with one strict rule - if
DRBD says something is written, it should already be written to both nodes.
When secondary is down, and DRBD is still writing to the primary - that is
not really synchronous replication. That behaviour makes it asynchronous,
because actual write to the secondary node is delayed.

In general, I want to ensure that when database transaction is commited, the
data rests on both nodes. If secondary is unavailable, transaction should be
rolled back.

On 19 March 2010 14:15, Digimer <linux at alteeve.com> wrote:

>  On 10-03-17 06:35 AM, Yuri Ushakov wrote:
>> Hello,
>> Is it possible to block write to primary node when secondary is not
>> available?
>> That is, suppose PostgreSQL asks the filesystem to write some bytes. I'd
>> like drbd to reply with "write OK" *only* if the data is written to both
>> nodes. If secondary is unavailable because of network error, reply
>> should be "not written".
>> What I understood from reading the docs is that unavailable secondary is
>> considered non-critical, and drbd continues writing to primary.
>> Tested that as well - drbdadm disconnect resource, and primary can still
>> write to mounted device.
>> Can this behaviour be changed?
>> Thanks for help,
>> Yuri.
> That would largely defeat the purpose of DRBD. When the second node
> disappears, the remaining node gets a "dirty" inode list in memory. When the
> node returns, it knows exactly what needs to be updated and syncs the
> missing data. This sync operation brings the other node back to being
> identical to the good node.
> What, exactly, are you trying to accomplish?
> --
> Digimer
> E-Mail:         linux at alteeve.com
> AN!Whitepapers: http://alteeve.com
> Node Assassin:  http://nodeassassin.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20100319/df8be5e4/attachment.htm>

More information about the drbd-user mailing list