MYSQL INNODB DeadLock

[denny]

hi,

ich weiß, dass ISPCONFIG3 mit MyISAM ausgeliefert wird, aber MyISAM ist halt schlecht in einem Cluster unterzubringen
Daher habe ich alle MyISAM Einträge durch INNODB ersetzt. Das klappt soweit auch problemlos, selbst die Updates laufen durch. Ich stelle allerdings folgendes fest:

Wenn ich eine Node (von 3) offline nehme, z.B. wegen MySQL Updates, dann habe ich schon mehrfach erlebt, wie es zu einem DEADLOCK kommt. Es reicht einfach das Admin Interface aufrufen zu wollen:

[URL="https://web.informatik.tu-darmstadt.de:8080/index.php#"]
[/URL]
 Login #0  db->query(DELETE FROM sys_session WHERE last_updated <  '2014-07-23 09:39:28' AND `permanent` != 'y') called at  [/usr/local/ispconfig/interface/lib/classes/session.inc.php:136] #1  session->gc(1440) called at  [/usr/local/ispconfig/interface/lib/classes/session.inc.php:60] #2  session->close() #3  session_write_close() called at  [/usr/local/ispconfig/interface/lib/app.inc.php:124] #4  app->__destruct()

Der Percona Cluster sagt dazu folgendes:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2014-07-23 09:57:57 7f496f491700
*** (1) TRANSACTION:
TRANSACTION 6905484, ACTIVE 21 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 37 lock struct(s), heap size 6544, 1937 row lock(s), undo log entries 1896
MySQL thread id 199369, OS thread handle 0x7f496f554700, query id 1286155 10.172.0.2 ispconfig updating
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 850 page no 6748 n bits 120 index `PRIMARY` of table `dbispconfigweb01`.`sys_session` trx id 6905484 lock_mode X waiting
*** (2) TRANSACTION:
TRANSACTION 6905572, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
421 lock struct(s), heap size 46632, 846 row lock(s), undo log entries 422
MySQL thread id 199375, OS thread handle 0x7f496f491700, query id 1286191 10.172.0.2 ispconfig updating
DELETE FROM sys_session WHERE last_updated < '2014-07-23 09:33:21' AND `permanent` != 'y'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 850 page no 6748 n bits 120 index `PRIMARY` of table `dbispconfigweb01`.`sys_session` trx id 6905572 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 850 page no 2924 n bits 504 index `last_updated` of table `dbispconfigweb01`.`sys_session` trx id 6905572 lock_mode X waiting
*** WE ROLL BACK TRANSACTION (2)

Nach ein wenig recherchieren bin ich mir sicher, dass dies ein INNODB "Problem" ist. Meine Frage wäre daher, wie ich das lösen kann.

Kann mir da jemand helfen?

Update:

Ein:

TRUNCATE TABLE sys_session;

hat das Problem vorerst gelöst. Die Tabelle wurde geflutet von "Monitor" Anfragen, um zu schauen, ob die Anwendung noch funktioniert .. alle paar Sekunden von zwei HAProxy Nodes. Das hat für mehrere hundert Einträge pro Minute gesorgt. Wie auch immer. Ich würde mich freuen, zu wissen, ob und wie man diese Tabelle für InnoDB "optimieren" kann. Ich schätze, daher rührt auch das Locking Problem, bei den zig tausenden Einträgen.



cu denny