Hi Robert, thank you for answer. Do you know when Sequoia 4.0 will be released? I know that there is no exact date, but maybe more or less accurate?
Regards, Tomasz. W dniu 27 sierpnia 2008 20:50 użytkownik Robert Hodges < [EMAIL PROTECTED]> napisał: > Hi Tomasz, > > Triggers can indeed cause problems. If you have updates on two separate > tables that then trigger updates on a third table, Sequoia won't guarantee > the update order for the third table, because it does not know about the > extra updates. > > There's work afoot to cure this as part of Sequoia 4.0, but until then you > have to use triggers very carefully. > > Cheers, Robert > > > > On 8/27/08 11:45 AM, "Tomasz Lemański" <[EMAIL PROTECTED]> > wrote: > > Hi Emmanuel, > Thank you for quick answer! This exactly clarifies my doubts about how > Sequoia works. I made some tests and indeed there is only one active > connection per table in write operations. > So as far as I can imagine, there could be a problem with data consistency > when triggers on MySQL are used, eg: trigger on INSERT in one table changes > data on another one. But this scenario could not be solved by any solutions > like Sequoia. > Am I right? > > Regards, > Tomasz. > > > W dniu 27 sierpnia 2008 18:09 użytkownik Emmanuel Cecchet < > [EMAIL PROTECTED]> napisał: > > Hi Tomasz, > > Actually the scheduler is now just a big on/off button that let's query go > further in the controller or not, it does not really schedule queries in the > sense of a database scheduler. The group communication just ensures that all > queries are delivered in the same total order at each controller. > It is the role of the BackendTaskQueues (basically a database state > machine) to serialize the writes to the same table and only allow writes to > different table to go in parallel (unless there are referential integrity > constraints). This state machine ensures that for a set of incoming queries > in a total order it will deterministically play the queries on the backend. > As each backend runs exactly the same state machine, it ensures that each > backend is going to play the requests in the same order. > This means that if you have a workload with a high degree of writes > executing in parallel, this will look really slow on Sequoia that will > serialize all the writes to make sure they are executed 1-by-1 in a > deterministic order. This is the price to pay for consistency. > > I hope this clarifies the way some of the things work internally. > > Thanks for your interest in Sequoia, > Emmanuel > > I would like to ask you about mechanism responsible for data consistency in > raidb1 distrubution mode in Sequoia (2.10.10). There isn't much information > about this in documentation. > > Assumptions: > Two sequoia controllers in raidb1 distribution mode (Scheduler set to > PassThrough). Each Controller has one MySql backend. > > I know, that communication protocol between controllers and between > controller and backend provides data consistency (especially order is > preserved). > > As far as I know database engine does not guarantee that in high load > environment (many read/write operations with table locks on myisam) first > query that arrives to the engine is executed earlier then a query that > arrives later. > Eg. there are lots INSERT and DELETE operations. If INSERT operation was > send earlier then DELETE operation, there is no guarantee that engine > execute queries in te same order, and after this operation there will be a > record that should be deleted. > > In one database environment it's acceptable problem, but when we use > sequoia for data replication to more backends there could be situation where > on two different backends databases there will be different data. And it is > not acceptable. > > As far I as I understand documentation pessimisticTransaction scheduler > could help (because there is only one write operation in parallel and no > limits on read queries). But there is no such option on raidb1 > configuration. > > At the end, my question is: > Is there a solution in Sequoia to be sure that on every database backend in > raidb1 scenario there are same data? > > Regards, > > > > -- > Robert Hodges, CTO, Continuent, Inc. > Email: [EMAIL PROTECTED] > Mobile: +1-510-501-3728 Skype: hodgesrm > > _______________________________________________ > Sequoia mailing list > [email protected] > https://forge.continuent.org/mailman/listinfo/sequoia > -- Tomasz Lemański nasza-klasa.pl tel./phone: +48 519 53 26 03 Nasza Klasa Sp. z o.o., ul. Dembowskiego 57/5, 51-670 Wrocław Sąd Rejonowy dla Wrocławia-Fabrycznej we Wrocławiu, VI Wydział Gospodarczy Krajowego Rejestru Sądowego, nr KRS:0000289629, NIP:898-21-22-104, REGON:020586020 Kapitał zakładowy: 67 850,00 PLN
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
