Ubuntu, DEB packages from MariaDB.org

The error message states why the loading of the users failed.

2018-02-08 14:38:49   error  : [MySQLAuth] Failed to load users: Lost connection to MySQL server during query

I'd recommend adding query_retries=2 under the [maxscale] section to see if the query retry feature helps.

Thanks for your prompt response. We did try adding query_retries=X to our maxscale.cnf (where X ranged from 2 to 5), but no dice: it still fails to load users from server B (2485 rows returned by that query above, in the description - all works fine for server A, with 1620 rows being loaded).

What did the trick for us was the following patch (against branch 2.1.13, BTW):

diff --git a/server/modules/authenticator/MySQLAuth/dbusers.c b/server/modules/authenticator/MySQLAuth/dbusers.c

index eb72bba..67e558c 100644

--- a/server/modules/authenticator/MySQLAuth/dbusers.c

+++ b/server/modules/authenticator/MySQLAuth/dbusers.c

@@ -59,7 +59,7 @@ static bool get_hostname(DCB *dcb, char *client_hostname, size_t size);

 static char* get_new_users_query(const char *server_version, bool include_root)

 {

     const char* password = strstr(server_version, "5.7.") ? MYSQL57_PASSWORD : MYSQL_PASSWORD;

-    const char *with_root = include_root ? "" : "WHERE u.user NOT IN ('root')";

+    const char *with_root = include_root ? "" : "WHERE u.user NOT IN ('root') AND u.user LIKE 'crew%'";

     size_t n_bytes = snprintf(NULL, 0, NEW_LOAD_DBUSERS_QUERY, password, with_root, password, with_root);

     char *rval = MXS_MALLOC(n_bytes + 1);

lines 1-13/13 (END)

This time, 31 and 73 users/credentials are (pre) loaded by MaxScale (from servers A and B, respectively) and everything works fine (since for this particular application we're only interested on those users).

We'll still trying to figure out what could be wrong and we're currently working with two hypothesis on our side:

• there might be some malformed/invalid string somewhere in the authentication/credentials data for server B
• it might be simply a matter some memory allocation limit being reached

We'll post more details as we have them.
Thanks for your time.

Ok - so we just tested one of the hypothesis mentioned above by artificially injecting 6000+ users on a mysql.user table via a stored procedure on a MariaDB 10.2 instance and... it worked: MaxScale loaded all those users just fine (this sorta rules out our 2nd hypothesis). We'll keep digging for the needle in the haystack (some malformed/invalid string somewhere) and report back when we find it so such a fringe case can be possibly addressed on a future release.
Thanks.

As the monitors in MaxScale use the MariaDB Connector-C, it could also be a bug in that component. To test whether this affects newer versions of the connector, you could try to test with the 2.2.1 beta version of MaxScale. It upgrades the connector to the 3.0 version whereas the 2.1 version of MaxScale uses the 2.3 version of the connector.

Hi there - just downloaded MaxScale 2.2.1 from http://goo.gl/U43755 (maxscale-2.2.1.ubuntu.xenial.tar.gz) and deployed on our test server: no dice (still getting "Lost connection to MySQL server during query" - only for that particular server). The connector upgrade doesn't seem to be making any difference. We're left with diff'ing the auth credentials and shall post here when/if we find the culprit.
Thanks.

Still no luck in finding the culprit (that is, we're still working on the hypothesis of having a specific combination of an 'old' version of MySQL with MaxScale). We'll post news as we find them. Thanks.

Just a quick status update on this one: we've narrowed down the possiblities down to the fact the problematic server runs MySQL v5.1. We've moved on with MaxScale v2.2.1 (again, compiled with the patch above) for now, and plan to upgrade that server to a newer version (the bug doesn't occur with that same auth/credential information on MySQL v5.5 onwards or MariaDB v10.2 and up).
Feel free to close this one as we won't be pursuing fixing such old setup on our end.
Thanks for your time.

OK, thanks for letting us know.