Might I suggest just using MySQL's master-slave replication? It does the
same thing but without the inherent risks of bringing up an imperfect
block replica.
That's what I'm thinking might be the best method. Just need to find
some documentation on doing this for both MySQL and Postgres. One thing
to be careful of is that if the slave is lagging behind the master and
we have a failure, there will be some database changes missing, which
might be lost. Using drbd would mean that those wouldn't be lost, but as
you say possibly have some form of corruption.
I just realized that DBMail can fix the IMAP UID problem after a split
brain situation by reassigning id's and incrementing UIDVALIDITY. This
would be way out in the future, though. So far we're trying very hard not
to have to be hands-on about the underlying database replication. It will
take lots and lots of code and tons of failure scenario test cases, so we
won't start down that path until we're ready to commit to it. This is one
of those things where half-assed code is far, far worse than no code at
all.
Just remember that the IMAP UID problem may not only occur from a split
brain situation. It could also occur when one server gets busy and lags
behind the other with updates. It could also occur when two messages are
injected at the same time at both sides. I did read about ideas on how
to avoid all of this with tokens etc. As you say it needs a lot of
careful thought before implementing and it's better to say "we don't do
it" than "we do it but don't trust it"
Regards,
Josh.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
