[DRBD-user] Ideas for splitting data between A and C protocol devices - safe or not?

[Casey Allen Shobe]

I've been tossing around a couple ideas in my head with a mind to  
improve overall performance.  I'd just like some feedback on the  
sanity of these ideas, especially if any seem inherently risky.

Reading through some random DRBD documents, I read something  
familiar:  "Applications like databases and journaling file systems  
maintain the consistency of their data by keeping track of  
modifications of their data sets in special places (logs, journals).  
In case of a system crash, the information of such a journal is  
sufficient to bring the data set in consistent state again."

This makes me wonder, well just how much can I get away with if the  
log/journal isn't damaged?

The idea that occurs to me is that since I'm already using two DRBD  
partitions for our PostgreSQL database, one for the data and another  
separate one for the write-ahead log, maybe it's tolerable to make the  
data partition use Protocol A (async replication) rather than B or  
C?.  And/or if I reconfigure the underlying JFS filesystem on the data  
partition to store it's journal on a synchronously-replicated device,  
making the main data replicated using protocol A, is this safe?

I ask because I see almost no difference between protocols B and C (I  
believe B is plenty safe for our needs, but no point in using it if  
it's no faster, eh?), but protocol A is significantly speedier.   
Protocol A "sounds" unsafe, but maybe since the filesystem and/or  
database can store their journals on Protocol C devices, it really is  
"safe"?

By "safe", I mean to say that "as long as one node always remains up,  
data is never lost".  I am not concerned about simultaneous failure of  
both nodes, and next year I hope to add a third node to boost  
redundancy further (such that when a secondary is intentionally  
offline, we're not in single point of failure mode).

Thanks in advance!
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
cshobe at bepress.com (email/jabber/aim/msn)
http://www.bepress.com | +1 (510) 665-1200 x163