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,
--
Tomasz Lemański
------------------------------------------------------------------------
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
