jesse at kci
Mar 27, 2003, 12:17 PM
Post #4 of 6
A few thoughts... I think Roel is probably on a more feasible
track for dbmail - it seems the current implimentation would need
some substantial redesign if dbmail itsself is going to manage
redundancy and consistency, and would probably have to also provide
some utilities to syncronize the db servers after that; right now
it needs to be done transparently, handled completely by the
Consider the following scenario: I have 2 sites in 2
geographically dispersed locations, and setup one dbmail server and
one database server at each location. The site allows anonymous
user signups, and there are users connecting to the local ISP hosting
the servers using the system. Now one site looses internet (and
intranet) connectivity. Users continue to be made and maybe delete,
mail is sent locally and one site continues to receive mail from the
Internet. Now comparing the 2 databases, you have multiple users with
the same user_idnr, possibly duplicate userid's, messages with the
same message_idnr's, mailboxes created with duplicate mailbox_idnr's,
and generally one big mess. There is no right way to solve that - it
would take redesigning almost all the dbmail database tables and a
fair chunk of how it deals with databases.
Don't get me wrong, I would *love* to have duplicate database
servers too, and I think it's definitely worth looking at all the
options, but I don't think a quick "try alternate database
connections" approach will work now.
---- Original Message ----
From: lou <dbmail-dev [at] dbmail>
To: dbmail-dev [at] dbmail
Subject: [Dbmail-dev] re: redundancy patch
Sent: Thu, 27 Mar 2003 18:59:34 +0000
> > Hi lou,
> Ello Roel,
> > The problem here is that the database consistency is not guaranteed -
> > the databases are not synchronized so behaviour seems pretty undefined
> > when for example the imap daemon connects to another database in the
> > mid of a session.
> True, no database consistency = problems, but.
> I still dont get something, let say if we have good replication (not perfect anyway,
> let say multimaster replication - no locks). If the replication keeps the two db
> servers replicated at any time, i dont see a reason why it wont work.
> > The unique-id's and message_idnr's are no longer
> > unique nor will the message_idnr guarantee the correct order of
> > delivery; some messages/folders will suddenly be no longer available
> > when a system fails and some others again will no longer be available
> > as the first system is up again.
> Let say two parallel inserts in the very same time of the replication i.e. server1 will
> have uID2 and server2 uID2 what happens after that? How the servers are going to deal with
> it, i`m sure someone at mysql.com and pgsql-r thought of that and found the right
> algorithm for it. Anaway, what happens when we replace the uIDs with randomly generated
> unique IDs.
> Anyway, we expect really quick replication from server2 to server1 to make the messages
> available *again* on server1.
> > We are still looking for some good replication funcionality but it
> > seems that the logics for such failover system should be a database
> > issue and not a dbmail one - the ultimate system would allow dbmail to
> > connect to some front-end (preferrably local so network failure is
> > shielded from dbmail) SQL interface which would implement all the
> > failover functionality we desire: different groups of replicating
> > clusters spread out over the world :)
> It`s possible with code but the performance will be decresed and the whole thing would be
> much more complex than it`s now.
> I personally dont strife for clustering but for grid redundancy and shared responsibility
> regarding different jobs and objects.
> That will be really neat algorithm, since a machine is not able to analyze the objects
> before applying/inserting/updating them. Even a one with rules in it, will face a new
> stuff, and wont be able to decide what to do with it, since that problem is not only
> present in dbs but in everything. Sometime ago i was having the same discussion about fs
> synchronization and consistency, but trust me Databases are far more consistent in any way
> than a filesystem, so that`s why i`m using dbmail.
> Anyway if you`re happy discussing this issue or i misunderstood you in any way, please let
> me know.
> If it doesnt work, i`ll be the first one to find out, since i installed it recently on two
> productional systems.
> Lou Kamenov AEYE R&D lou.kamenov [at] aeye
> FreeBSD BGUG http://www.freebsd-bg.org lou [at] FreeBSD-bg
> Secureroot UK http://secureroot.org.uk phayze [at] secureroot
> Key Fingerprint - 936F F64A AD50 2D27 07E7 6629 F493 95AE A297 084A
> One advantage of talking to yourself is that you know at least
> somebody's listening. - Franklin P. Jones
> Dbmail-dev mailing list
> Dbmail-dev [at] dbmail
-- End Original Message --
jesse (at) kci.net