| |||||||||||||
Also, consider DRBDAlso, consider DRBDPosted Jun 1, 2012 21:25 UTC (Fri) by andresfreund (subscriber, #69562)In reply to: Also, consider DRBD by Richard_J_Neill Parent article: Clustering, development, and galactic conquest at PGCon 2012
The problem is that you cannot use the 2nd server for anything (running backups, reporting queries, ...) that way. Also you have the problem that starting with crash recovery (which is what will happen if you failover to the 2nd server, because pg hasn't been cleanly shut down) can take a long time if you have a big time and allow for some wal to collect for performance reasons (checkpoint_segments).
(Log in to post comments)
Also, consider DRBD Posted Jun 4, 2012 10:08 UTC (Mon) by niner (subscriber, #26151) [Link]
That's not entirely true. If your DRBD device is on top of LVM you can take a snapshot and mount this snapshot even on the secondary. We use such a setup for backups and it works just fine. You could even run PostgreSQL on this snapshot and do your reports from it.
Of course LVM snapshots have their own performance problems and just using PostgreSQL's native replication might be easier and faster, but still just using DRBD is a possibility which allows to cover not just the database.
Also, consider DRBD Posted Jun 4, 2012 10:36 UTC (Mon) by andresfreund (subscriber, #69562) [Link]
Sure, you can do that or similar things (loads of SANs have that capability). Keeping the secondary pg instance up2date is really expensive in that scenario though. You need to shutdown pg, drop old, create new snapshot, start pg which will do recovery. If you have nontrivial amounts of writes the wal replay uppon startup will take quite some time....
I don't really see any reason to do so these days unless your database is gigantonormous and you cannot afford to have a full copy of the datadir for reporting.
|
|||||||||||||