Thanks for your answer.

I checked again the logs, and I noticed that there is a warning on the 
controller about the 2 backends configuration:
Here are the warnings, but not sure how to interpret these.
23:44:32,316 WARN  VirtualDatabaseWorkerThread.myDB.metadata Metadata key 
[storesMixedCaseQuotedIdentifiers] is not compatible. (Backends are: 
[jdbc:mysql://192.168.0.101:3306/poundtaxi_seq] and 
[jdbc:mysql://192.168.0.102:3306/poundtaxi_seq] ; Values are:[false] and [true])
  23:44:32,316 WARN  VirtualDatabaseWorkerThread.myDB.metadata Metadata key 
[storesLowerCaseIdentifiers] is not compatible. (Backends are: 
[jdbc:mysql://192.168.0.101:3306/poundtaxi_seq] and 
[jdbc:mysql://saturn:3306/poundtaxi_seq] ; Values are:[true] and [false])
  23:44:32,316 WARN  VirtualDatabaseWorkerThread.myDB.metadata Metadata key 
[storesLowerCaseQuotedIdentifiers] is not compatible. (Backends are: 
[jdbc:mysql://192.168.50.78:3306/poundtaxi_seq] and 
[jdbc:mysql://192.168.0.102:3306/poundtaxi_seq] ; Values are:[true] and [false])
  23:44:32,316 WARN  VirtualDatabaseWorkerThread.myDB.metadata Metadata key 
[supportsMixedCaseQuotedIdentifiers] is not compatible. (Backends are: 
[jdbc:mysql://192.168.0.101:3306/poundtaxi_seq] and 
[jdbc:mysql://192.168.0.102:3306/poundtaxi_seq] ; Values are:[false] and [true])
  23:44:32,316 WARN  VirtualDatabaseWorkerThread.myDB.metadata Metadata key 
[storesMixedCaseIdentifiers] is not compatible. (Backends are: 
[jdbc:mysql://192.168.0.101:3306/poundtaxi_seq] and 
[jdbc:mysql://192.168.0.102:3306/poundtaxi_seq] ; Values are:[false] and [true])
  ********************************

I changed the WaitForCompletion policy to ALL, but that didn't make a 
difference, other than both backends were in deadlock now. 
However, I also changed the deployment configuration. I deployed Sequoia 
controller on  a separate machine. So, the configuration I had before was:
- one MySQL server on a dedicated machine;
- 2nd MySQL server and Sequoia controller collocated on the 2nd machine.
Now I changed everything, and each MySQL server and Sequoia controller are on 
separate machines (so 3 machines). 
This seems to make the difference because even if I run JMeter with 20 
concurrent users I get no deadlock and before I got when using 5 concurrent 
users. Not sure if the deadlock went away as the fact that the machine was 
freed up and had more memory for MySQL than it had when Sequoia controller was 
also deployed on the same time, but this is how it looks like.
I am wondering what is the deployment configuration one should have when using 
sequoia. Can you please give me some thoughts on this?

Thanks,
Patricia

Emmanuel Cecchet <[EMAIL PROTECTED]> wrote: Patricia,

> I am using Sequoia 2.10.9 for a proof of concept. The configuration I 
> have is using one Sequoia controller, with 2 MySQL backends (Raidb1). 
> All tables are Innodb.
> Each backend is created on a separate MySQL server, and the recovery 
> db is collocated with one of the backends. The 2 MySQL servers are 
> located on 2 different machines, so perhaps a network latency can also 
> interfere.
> Everything works fine, until I try load testing this configuration. If 
> I run a JMeter test for 5 concurrent users, I have a lock error on one 
> of the backends, which is disabled as result of the lock.
> *********************************
> 2008-01-21 18:49:03,312 ERROR backend.DatabaseBackend.cg113-seq2 
> Request 'update log_call_session set call_type=?,...' failed on 
> backend cg113-seq2 but 1 succeeded (java.sql.SQLException: Lock wait 
> timeout exceeded; try restarting transaction)
> 2008-01-21 18:49:03,312 WARN  backend.DatabaseBackend.cg113-seq2 Task 
> execution failed (java.sql.SQLException: Request 'update 
> log_call_session set call_type=?,...'
>
> ***********************************
Actually if you had a deadlock, you should experience the same error on 
both backends. If only one backend deadlocks it means that you have a 
configuration problem. Possible causes are:
- your backends are not properly synchronized and actually their config 
(my.cnf) or content differ
- a process is executing queries directly on one backend without going 
through Sequoia (locking will be completely messed up in that case)
- if you are using a single Sequoia controller, I guess that you don't 
use group communication so the settings should not be an issue there.
- try to change  to 
 in case there would be a 
synchronization issue in the asynchronous execution management code.

Keep us posted with your findings.
Emmanuel

-- 
Emmanuel Cecchet - Research scientist
EPFL - LABOS/DSLAB - IN.N 317
Phone: +41-21-693-7558

_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to