Hi Tomasz, I don't have a firm date on a 4.0 release as it's dependent on availability of folks like Emmanuel Cecchet, who is the original author. We hope later this year.
Cheers, Robert On 8/27/08 12:01 PM, "Tomasz Lemański" <[EMAIL PROTECTED]> wrote: 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
