[Disk-level replication instead of using Slony-I]
> What are the reasons they recommend this? (See my blathering in
> another thread about how often the hand-wavy recommendations that are
> made on this topic can really bite you hard if you don't know all the
> intimate details underneath.)
The reason usually given is simplicity. Why replicate the state of every
service individually if you can just replicate the file system?
Obviously this neglects the fact that there is lots of other state than
the persistent state stored in the file system. That this could bite me
hard was exactly my gut feeling.
[Are there any risks in disk-level replication?]
> Sure, there's risk. There's risk in using Slony, too (if you
> accidentally issue DDL under Slony without using EXECUTE SCRIPT, you
> can find yourself having a rather bad day).
Agreed. I should have been a bit more precise here. Let's assume that I
do everything under my control to minimize risk, i.e. I follow best
practices using Slony-I and I follow best practices using disk-level
replication. I'd like to understand the risk that remains in both cases.
For Slony-I it seems to me that my risk is losing a couple of rows in my
database, which is something that I could live with. For disk-level
replication it seems to me that, in case of a master failure, I could
easily end up with a corrupted database file on the master's as well as
the slave's harddrive (which is a mirror of the master's), possibly
preventing the slave from taking over, which is clearly something that I
cannot live with as this means downtime.
[Suppose that the master fails in the middle of a write. How likely is
corruption?]
> Well, this is going to depend partly on the implementation and the
> hardware and the settings you give. Also, you _cannot_ have another
> postmaster attached to that data area, and if you accidentally open
> up another postmaster on a data area and it does work while the first
> postmaster is still connected, you are just completely hosed. This
> is not a place to be 95% sure you got it right.
Agreed. Accidentally running two postmasters on the same data file is
indeed an additional risk that I did not think of when making my
original posting. But you mention settings. So let's for a moment assume
that I get everything right in this respect and then my postmaster fails
in the middle of a write. Which settings would I want to modify in which
way to minimize the risk of database corruption in such a case?
> Note, too, that copying the data files around does not give you the
> significant advantage that Slony or other replication systems do,
> that you can use the replicated database to satisfy some times of
> queries; so you should consider whether you need that. (This is why
> the excellent docs on this emphasise that there are different kinds
> of need and therefore different replication technologies.)
Yup, that's true, thanks for pointing this out. In my scenario, however,
I do not have any need to, for example, load-balance read accesses. I am
solely interested in improving the availability by having one active
database node and one passive node that tracks the state of the active
node as closely as possible.
-Thomas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
