Andrew Sullivan wrote:
> On Wed, Mar 01, 2006 at 09:51:46AM -0800, Bryce Nesbitt wrote:
>
>> switch over and rebuild the DB. "No-lost transaction" is far more
>> important than switch time.
>>
>
> You can't guarantee that without two phase commit, no matter what you
> do. Log shipping doesn't require you to have an active database
> running on the origin (slony-1 does, which is one of its potential
> drawbacks). But that won't help you if a transaction committed at
> the instant an earthquake hit your datacentre, wiping it out. You
> can't get the data off the failed origin no matter what.
>
Actually let me loosen that a bit: we don't need two phase commit. We
can loose the most recent transaction, or even the last few seconds of
transactions. What we can't survive is -- on the day of the emergency
-- a long and complicated DB rebuild with mistakes and hard-to-debug
data issues.
>> Anyone here using replication or transaction journaling? Has it proved
>> reliable, easy to maintain?
>>
>
> Define "easy". Every possible replication system is going to have
> slightly grotty corners into which you find yourself wandering. The
> question is merely whether the room is octagonal or merely
> rectangular.
>
There's no fire creating demand for replication, so there is little time
budget.
So is there a sort of padded, no-sharp-corners, playroom that gets us
90% of the way there?
We're looking to reduce what's now a 24 hour window on data loss (since
the most recent
nightly) into something more reasonable (like 500 milliseconds). But
risk -- of data corruption --
and time --too much-- will can the project.
