Incidentally, if as per my last email we do start talking schemas and code and whatnot else, we should move to the dev list: dbmail-dev@dbmail.org
Aaron On Thu, 1 May 2003, lou wrote: > In some email I received from Aaron Stone <[EMAIL PROTECTED]> on Thu, 1 May > 2003 > 12:37:53 -0700 (PDT), wrote: > > > You wouldn't be able to separate reads and writes because the IMAP/POP3 > > servers are so much faster than the database replication that even > > something as simple as moving a message from one folder to another would > > appear to have failed but then suddenly take effect a few seconds later. > > The delay would get worse as the load went up, making a medium load > > system appear even laggier and buggier than a heavily loaded one. > > right, dbmail is not optimized for parallel operations nor mysql is. > however you answer is quite scary:) > > > Allowing a slave to step up to master status presents another problem > > because at the time of resynchronization, you are likely to find that > > changes were committed to the failed master before they could be > > propagated. This leaves the sequence numbers in a perfect position to > > collide and cause a full halt of all replication until manually restored > > (this is further explained in the MySQL manual). > > that depends, depends what's the factor to generate those numbers.. > also consider each server working i its own dimension of the database where > the others > doesnt have write permissions, also the access shouldnt be async but synch, > we all know > that sync access with transactions is more safe(not super fast, but in some > cases it is) > > > I've been thinking about this problem, and it might be possible to > > eliminate the auto_increment fields, > I was trying to tell you this since i wrote this very basic thing, > auto increment suck in general especially when you cant change the increment > factor > > (on pgsql you can but the replication is not for productional use though) > > Also why dont you push for per server table for sequences, that how you can > easily > implemend a group communication between the servers and make it lot more > robust.. > anyway the sequence generation have to be coded but i dont see this as a big > problem... > > just from my experience with mysql/pgsql/soso, i've never used auto increment > with any > database, simply because it's not portable (if you want to move it to a > different > database) and doesnt give you this really important management layer, like in > this case. > > > using only the unique id of each > > message as its handle. It's just a thought, and would require a lot of > > work to implement the full semantics to maintain referential integrity, > > but might be a good place to start. > > if you're interested i can send over the design paper? > > cheers > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
