Recent Features
| |||||||||||||
Also, consider DRBDAlso, consider DRBDPosted Jun 1, 2012 16:44 UTC (Fri) by Richard_J_Neill (subscriber, #23093)In reply to: Also, consider DRBD by jberkus Parent article: Clustering, development, and galactic conquest at PGCon 2012
We had to deploy this into production ~ 3 years ago, when there were fewer alternatives. I agree that it hurt performance a bit, though in fact we still got pretty awesome performance: the secondary server was completely idle apart from the drbd slave, and the network was a single 6' cable between 2 dedicated gigabit cards. With protocol B, I think we found that DRBD's copying data to the secondary server's RAM took less time than for the primary server to write to its disk (at least for larger datasets).
I'm curious as to why replicating the whole filesystem has to copy much more data than other forms of database replication: I thought that typically the ext4 overhead was quite small?
As you say, for small writes, there are some problems, and there is some case for deciding on a per-transaction-type basis whether that transaction is critical, or slightly less critical. (i.e. if someone puts an axe through the server right now, how much do the last 20 ms of that type of data matter?). Either way, postgresql is an amazing product :-)
(Log in to post comments)
Also, consider DRBD Posted Jun 1, 2012 17:52 UTC (Fri) by nix (subscriber, #2304) [Link]
When you copy the whole filesystem, you're copying across changes to the WAL (journal) as well as changes to the data/ files it is journalling. As the WAL is frequently (f)(data)sync()ed, this overhead is even higher. I am also sceptical as to its safety: it seems easy to me to synch across a change to the WAL on commit or WAL rollover but lose power before the corresponding change to the datafile is synched: on restart, the remote PostgreSQL will think that no WAL replay is necessary, when in fact one is needed.
PostgreSQL's native replication simply streams the WAL across, and replays it into the datafiles on the remote node. This is guaranteed safe.
Also, consider DRBD Posted Jun 1, 2012 22:33 UTC (Fri) by jberkus (guest, #55561) [Link]
Nix,
We've had reason to destruction-test DRBD+Postgres. From a data safety perspective it works as well as one could hope, provided that you take steps to prevent split-brain. It's just performance which leaves something to be desired.
Also, consider DRBD Posted Jun 4, 2012 12:36 UTC (Mon) by nix (subscriber, #2304) [Link]
Oh, I'm willing to believe it works most of the time. I just can't see how it's safe 100% of the time (when WAL rollover happens). However, it might be that the failure cases require long periods of downtime and very unluckily-timed powerdowns, in which case you might never see it.
But quite possibly I'm missing something.
Also, consider DRBD Posted Jun 4, 2012 15:07 UTC (Mon) by andresfreund (subscriber, #69562) [Link]
As long as the snapshot is atomic it *has* to work. Otherwise the original purpose of the wal - crash recovery - wouldn't be met.
Checkpoints are crash safe. Whats the problem youre seeing there? The checkpoint record is only written to the wal *after* everything but the checkpoint information has been written out. Only after the checkpoint has been fsynced to disk resources - like the wal - are reused.
Also, consider DRBD Posted Jun 4, 2012 18:18 UTC (Mon) by nix (subscriber, #2304) [Link]
Agreed, this is perfectly fine. I now suspect that my memory is lying to me: it tells me faintly that DRBD may transmit data in arbitrary order and does not do a complete transmit on fsync(), but I now suspect I'm thinking of some other distributed block device and just mixed it up with DRBD. If DRBD respects fsync(), then everything works.
Also, consider DRBD Posted Jun 4, 2012 18:25 UTC (Mon) by andresfreund (subscriber, #69562) [Link]
I think you can configure it in a way not all required guarantees are met. They are not generally recommended as far as I remember though.
... Yep: http://www.drbd.org/users-guide/re-drbdconf.html check the docs for disk-barrier.
|
|||||||||||||