Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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