Hello, 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 database.
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. Jesse ---- Original Message ---- From: lou <[email protected]> To: [email protected] 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. > > cheers, > -lou > > > -- > Lou Kamenov AEYE R&D [EMAIL PROTECTED] > FreeBSD BGUG http://www.freebsd-bg.org [EMAIL PROTECTED] > Secureroot UK http://secureroot.org.uk [EMAIL PROTECTED] > 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 > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- End Original Message -- -- Jesse Norell jesse (at) kci.net
