[MXS-1924] [MySQLAuth] Failed to execute auth query: database table is locked: mysqlauth_users Created: 2018-06-14  Updated: 2020-08-25  Resolved: 2018-06-21

Status: Closed
Project: MariaDB MaxScale
Component/s: Authenticator
Affects Version/s: 2.1.16
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None


 Description   

A MaxScale instance that has a very high rate of authentication failures is seeing occasional errors like the following:

2018-06-14 18:39:15   error  : [MySQLAuth] Failed to execute auth query: database table is locked: mysqlauth_users
2018-06-14 18:39:15   warning: [MySQLAuth] Client hostname lookup of '' failed, getnameinfo() returned: 'Name or service not known'.
2018-06-14 18:39:15   warning: [MySQLAuth] Splitter Service: login attempt for user 'platform_app_usr'@[10.1.1.1]:41650, authentication failed.
2018-06-14 18:39:16   notice : [MySQLAuth] [Splitter Service] Loaded 332 MySQL users for listener Splitter Listener.

Is this caused by the high rate of authentication failures?



 Comments   
Comment by markus makela [ 2018-06-14 ]

The SQLite database is shared in 2.1 whereas in 2.2 it is not. This most likely is the root cause of the authentication problems and is more likely to happen when users are being loaded.

To completely prevent this in 2.1, the authentication would need to be changed to grab a global lock. This would slow down the authentication even when users are not being loaded. Another option would be to switch from MEMORY journal mode to WAL mode. This should mostly prevent locking of the read connections caused by updating of the users database.

Comment by Geoff Montee (Inactive) [ 2018-06-14 ]

So upgrading to 2.2 might help prevent this?

Comment by markus makela [ 2018-06-15 ]

Yes, it will fix this.

Generated at Thu Feb 08 04:10:24 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.