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
