[MXS-271] Schemarouter and unknown databases Created: 2015-07-15  Updated: 2015-09-10  Resolved: 2015-09-10

Status: Closed
Project: MariaDB MaxScale
Component/s: schemarouter
Affects Version/s: 1.1.1
Fix Version/s: 1.3.0

Type: Bug Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS 7

Issue Links:
Relates
relates to MXS-306 User authentication fails when using ... Closed

 Description   

Schemarouter occasionally reports an unknown database when connecting directly to a database:

ERROR 1045 (28000): Access denied for user 'user'@'127.0.0.1' (using password: YES) to database 'database1'

The database exists on the backend server and the user has correct grants. I haven't found a way to reproduce this every time.

 Comments   
Comment by martin brampton (Inactive) [ 2015-07-17 ]

Comments by Simon Mudd:

As I’m sure you are aware MySQL treats localhost specially and it’s not the same as 127.0.0.1.
So any grant processing that MaxScale is doing should treat these 2 “domain parts" differently.

Localhost is an “alias” for the unix socket which in MySQL is defined in [mysqld] by socket=/path/to/mysql.sock or similar.

I don’t believe that MaxScale supports local connections to a unix socket, but either way if you see the address part
of a grant using that name you should not treat it as being the same as 127.0.0.1 or try to resolve it at all.
If you don’t support unix sockets then probably any grants for <whatever_user>@localhost should probably be ignored.
Failing to take this special case into account may cause issues, though possibly only in a situation where you have
MySQL installed on the same server as MaxScale.

Either way improving the error message to explain more clearly what the actual problem is would be most helpful.

Comment by markus makela [ 2015-08-17 ]

This is most likely related to MXS-306.

Comment by Dipti Joshi (Inactive) [ 2015-09-09 ]

markus makela Will this be closed when MXS-306 is closed ?

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