If the client sends another query before reading the previous result, it
was possible that another session finished the shard update and the
following query would reuse this result. This would cause the assertion in
the delayed call to fail as it assumes the shard would always be empty
when it was being called. To correctly handle this case, the delayed call
must be the one that moves the session into the normal routing state.
It is worth documenting this change as the amount of queries done by
MaxScale is likely to decrease by a significant amount. This change can
also have a negative effect on the worst-case delay of the database
mapping but this isn't really a practical problem.
Putting the sessions that aren't doing the update on hold makes the new
mechanism work the same way the old one did with the exception that it
won't put any extra work on the database itself.
As there are no practical benefits to multiple sessions for the same user
mapping the databases at the same time, limiting them to one update per
user is sensible. This is especially true now that we know the
information_schema tables aren't the most efficient things in the world.
The current code implements this rate limiting by closing any extra
sessions that would start a second update. The final implementation should
suspend them for the duration of the update as it is far more
user-friendly.
The limits are currently global as the shard caches are also global. This
is a performance bottleneck and it could be solved by storing the shard
cache inside of a mxs::WorkerGlobal instead of having it as a global
cache.
If the schemarouter service used a filter, any queued queries would end up
being routed twice for them as well. This would break any filters that
would expect a result for each query and it could also cause a hang if the
filter did not forward it up to the router.
The correct thing to do is to call the routeQuery method of the router
directly.
As both `SET autocommit=1` and `SET autocommit=0` share the same canonical
query form but do not have the same types, they should not be stored in
the cache.
The code is now identical to the one in 2.5 and it still suffers from the
problem described in MXS-3885. This will be fixed in a separate commit.
This commit changes the persisted filename but since it was ignored, it
won't affect old installations.
The fact that the parameter does nothing in 2.4 and newer versions is now
at least documented. Fixing it this late in 2.4 could result in unwanted
changes in behavior.
Backported the fix for MXS-3617 to 2.4.
If a packet was read from the backend while the client DCB was being
throttled due to writeq_high_water being hit, the response would be
discarded as it did not qualify for routing. The check should not check
whether the client DCB is in epoll as it has no effect on writes.
Currently the state change explanations are only added to mariadbmon. They
are less relevant for Galera clusters as they themselves explain why they
change their states but should still be added to make them easier to
analyze.
The event that isn't explained and is most often encountered is the loss
of a Slave status. Most often the loss of a Slave status happens because
either the IO thread or the SQL thread has stopped. Printing the states of
the threads as well as the latest error should hint at what caused the
outage.
The information can be added to the REST API in 2.5 where the monitors can
add extra information to the server JSON.
Backporting to 2.4.
The listener search used the host and port for listeners that used sockets
and vice versa. This caused multiple listeners with sockets to fail to be
created.
The sqlite code is indented oddly:
In file included from query_classifier/qc_sqlite/qc_sqlite3.c:21:
sqlite-bld-3110100/sqlite3.c:98051:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
98051 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~
sqlite-bld-3110100/sqlite3.c:98051:35: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
98051 | if( a[0]<33 ) a[0] = 33; assert( 33==sqlite3LogEst(10) );
| ^~~~~~
In the case of qc_sqlite, it is done "precisely", while in the
case of qc_mysqlembedded rather bluntly. Not time well spent
to figure out exactly which pointer chains need to be walked.
When a transaction migration starts, the old master must be
unconditionally closed. This is the simplest way of resetting the
connection state and it also helps close unused connections.
The test failed because the linux user it used was not available
on buildbot. Now the test is part of the larger pam_authentication-
test, which sets up the users.
