> 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.
true. > 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. > i`m quite aware of that, and it has been already tested, and yes it`s failing. > 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. How many options do we have? i say *quite* a few, db replication in a consistent manner or let the code synchronize it in a more smart manner, change the store procedures? If anyone can think of something else i`ll be more than delighted to hear it. for these reasons all of us using dbmail are statically linked to 1db per server without being related in any way to any other db server regarding the problems that you and roel mentioned in your emails. Since i`m not aware of db smart enuf to cope with it. However I personally find the task implemeting a mechanism and redesigning the backend much more easier. Consider the fact that some dbs will let us replicate in our dream way, what about the others? that means the users will be urged to use only N specific dbs when they want to use M let say. I`m about 80% sure that you guys are aware of this: why this wont happen on a filesystem, when you sync 2 different maildirs, let say using qmail. Cause basically the identifiers indexing this objects are not the same never and simple rsync would synchronize it. think about that, cause i think that is the case where we should look for a workaround for now until something more robust and sofisticated comes on the scene. And not in the application itself but the way it stores all the data, to be exceptional from any other. I`ll be happy to help with anything i can if anyone is keen on moving forward regarding this impl. all you guys from IC&C did something amazing in the form of dbmail, thanks a lot! just my two bits. 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
