[DRBD-user] Consistency in protocol A

[Lars Ellenberg]

On Tue, Feb 21, 2012 at 12:31:39AM +0100, Andreas Bauer wrote:
> Hello again,
> 
> On a different topic....
> 
> I run DRBD Primary/Secondary with protocol A. Because performance is
> important,

If performance is important, use a decent RAID controller.
And give it decent amounts of write cache.
And make that write cache non-volatile.

> and I do not require the Secondary to be up to date to the
> millisecond. So if bad stuff happens to the primary node, I can expect
> the secondary node to be more or less up-to-date, depending on the
> amount of data that was still sitting in primary node's buffers.
> 
> Can I reasonably expect the secondary node to be clean in terms of
> order of writes, i.e. slighly outdated maybe yes but consistent up to
> that past moment in time?
> 
> Let's further assume I want even more performance and disable
> disk-barriers and disk-flushes on both nodes, disregarding the clear
> warning in the documentation, and the primary node crashes. Now I
> understand that consistency in terms of write order is not guaranteed
> anymore for data on the primary node. So the data on the primary node
> can be considered junk after a crash / failure.


Why don't you just add a non-volatile write cache module?
That will improve performance *and* improve reliability.

> But the data on the secondary node should still be fine, slightly
> outdated maybe, but consistent. So as long as the primary node is
> fenced and the data there invalidated, life should be good. Correct?

Unless you have a "hickup" in the replication link first,
and then your primary crashes during the resulting resync:
while synctarget, the secondary is inconsistent.

Look into "before-resync-target" handler,
it can snapshot the last consistent data.

Of course the snapshot will again have impact on performance...


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com