Stefan Viljoen
2016-Dec-01 08:39 UTC
[asterisk-users] ODBC locks warning in CLI - Asterisk 1.8.32.3
Hi all Just to report back if it is of interest to anybody, I managed to solve this. Had nothing to do with Asterisk, rather with Percona 5.6 / MySQL which is the database used via ODBC from Asterisk to store CELs and CDRs. I added the following in the /etc/my.cnf file for the Percona instance I am running: innodb_lock_wait_timeout=120 transaction-isolation=READ-COMMITTED and restarted the Percona instance. This appears to have definitively removed the below warning from my Asterisk instance's CLI. Using READ-COMMITTED (instead of the default REPEATABLE-READ) transaction isolation level apparently has optimised InnoDB table row locking (at least in my use case, Percona / MySQL version and load) to such a degree that I no longer see the warning below come up. Everything is still reliably logging as far as I can determine, and all my MySQL stored procedures which process my CDRs and CELs into useful form for my dialing back-end are still working fine. Just in case somebody can be helped by this.>Hi all>I get this warning in the Asterisk CLI about once every ten minutes or so:>[Nov 23 14:47:36] WARNING[2544]: res_odbc.c:647ast_odbc_prepare_and_execute: SQL Execute returned an error -1: HY000: [MySQL][ODBC 5.1 Driver][mysqld-5.1.73]Deadlock found when trying to get lock; try restarting transaction (105) [Nov >23 14:47:36] WARNING[2544]: res_odbc.c:659 ast_odbc_prepare_and_execute: SQL Execute error -1! Verifying connection to cdr [asterisk-cdr]...>[Nov 23 14:47:36] WARNING[2544]: res_odbc.c:763 ast_odbc_sanity_check:Connection is down attempting to reconnect...>[Nov 23 14:47:36] NOTICE[2544]: res_odbc.c:1541 odbc_obj_connect:Connecting cdr [Nov 23 14:47:36] NOTICE[2544]: res_odbc.c:1573 odbc_obj_connect: res_odbc: Connected to cdr [asterisk-cdr]>Does this imply that I'm missing the ODBC CELs and / or CDRs that weretrying to write to MySQL over ODBC when the above occurred?>Or will the ODBC module in Asterisk (or ODBC itself?) recover gracefullyand re-emit the CEL or CDR insert that hit the lock and were therefore NOT written to MySQL?>Thanks,>Stefan