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:) >
I had never thought about this one, either, but then during discussion a few months ago Eelco brought this us and indeed it is quite scary! For anyone else who didn't get my last sentence, it was tyoped [sic]: "The delay gets worse as the load goes up, making a medium load split database feel much laggier and buggier than a heavily loaded single database." > > 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) > Is it possible to have a transaction that forces all replicas to be up to date before committing to the master? I'm not sure if that's any kind of solution, or if it just makes it worse... but interesting to know of... > > 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? > Please do. There's been a lot of work on the list lately involving the database design, and if this is the sort of thing that isn't any much harder to do anyways, I'd like to propose that the v2.0 schema provide its own sequence tracking that avoids inter-server collisions like this. For those who've been keeping track of my personal soapboxing, I still think that the new schema is a long term project, but it *does* need a wishlist, after all :-) > cheers > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail >
