Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Aug 12, 2008 at 09:50:48PM -0700, Casey Allen Shobe wrote:
> 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,
wich is already risky, as DRBD currently has no means to ensure
consistency (write-ordering) accros multiple devices,
so in case of crash/disconnect/failover,
your data files may be more recent than your wal-files,
or your wal-files may be more recent than your data files.
> maybe it's tolerable to make the data partition use Protocol A (async
> replication) rather than B or C?.
no.
> 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?
certainly not.
> 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"?
journals and wal-files and whatever reference data files.
you cannot apply todays wal-files to last-weeks base file backup,
right?
if you try to apply this seconds wal-files to last seconds base files,
it may or may not work, you may or may not be lucky.
if you are very unlucky, they would seem to apply, but not notice that
they actually did not because of slightly outdated base files.
do not replicate journal and data files with different protocols.
try to avoid to replicate them on different devices.
you should put logically dependend data on the same drbd.
> By "safe", I mean to say that "as long as one node always remains up,
> data is never lost".
as long as one node always remains up...
protocol A:
data-base commit
`- submitted to DRBD
|- handed over to network stack (in tcp sendbuffer)
`- submitted to local disk
` local disk completion.
with protocol "A", that database commit is now "done".
CRASH.
with drbd protocol "A",
peer node may not yet know anything about that commit.
commit was lost.
--
: Lars Ellenberg
: LINBIT HA-Solutions GmbH
: DRBD®/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks
of LINBIT Information Technologies GmbH
__
please don't Cc me, but send to list -- I'm subscribed