CentOS 7

Used the following to create the grants:

create user 'dlb01_bhs'@'10.3.10.86' identified by '<SECRET>';
grant SELECT on mysql.user to 'dlb01_bhs'@'10.3.10.86';
GRANT SELECT ON mysql.db TO 'dlb01_bhs'@'10.3.10.86';
create user 'dlb02_bhs'@'10.3.10.86' identified by '<SECRET>';
grant SELECT on mysql.user to 'dlb02_bhs'@'10.3.10.86';
GRANT SELECT ON mysql.db TO 'dlb02_bhs'@'10.3.10.86';
create user 'dlb03_bhs'@'10.3.10.86' identified by '<SECRET>';
grant SELECT on mysql.user to 'dlb03_bhs'@'10.3.10.86';
GRANT SELECT ON mysql.db TO 'dlb03_bhs'@'10.3.10.86';

Looking at the grants alone, it seems the SHOW DATABASES permission is missing. For more details, read the section about creating database users in the MaxScale Tutorial.

The error log does state that the connection was actively refused which suggests that there's something wrong with the grants. I would make sure that MaxScale's host is 10.3.10.86 and that the grants are given to the right host.

Hello Markus,

I created a brand new user according to that tutorial:

create user 'maxscale_bhs'@'10.3.10.86' identified by '<secret>';
grant select on mysql.user to 'maxscale_bhs'@'10.3.10.86';
grant select on mysql.db TO 'maxscale_bhs'@'10.3.10.86';
grant show databases on . TO 'maxscale_bhs'@'10.3.10.86';
grant replication slave on . to 'maxscale_bhs'@'10.3.10.86';
grant replication client on . to 'maxscale_bhs'@'10.3.10.86';

and the problem persists. Thank you.

Can you attach the maxscale.cnf file you used?

The services and monitors needs to be configured with user=maxscale_bhs with the appropriate password. In addition to this, when connecting from the machine MaxScale is on to all databases, the SELECT USER() output must match maxscale_bhs@10.3.10.86.

maxscale.cnf

As requested.

The configuration looks correct and if the maxscale_bhs user has the appropriate grants, it should work. Just to be sure, can you confirm that from the mysql command line doing a SELECT USER() shows the right user and hostname?

[root@dlb01 /]# mysql -u maxscale_bhs -h 10.3.10.80 -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 5848
Server version: 10.1.11-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select user();
-------------------------

-------------------------

-------------------------
1 row in set (0.00 sec)

Are you using password encryption? I'm thinking that there's a possibility that the password is being decrypted into the wrong password.

No, the passwords are clear text in maxscale.cnf. Should add that this configuration is being used on our other site without any issue though using different username/password combination. The six nodes are all within the same Galera cluster. Three at primary site and three at secondary. Its only this one, the secondary, that is failing.

I think this because in Encrypting Passwords, the document said the password key stores in /var/lib/maxscale, and the sample command shows the same path. But the real path of maxscale used is /var/lib/maxscale/data. If the .secrets file moved to /var/lib/maxscale/data, it would be ok.

This was caused by a hard-coded path in maxkeys which used /var/lib/maxscale/ as the destination instead of using the newer, dynamic path resolution functionality.