The SHOW DATABASES greatly slows down the test. By doing that only from
time to time, the test time drops from roughly 160 seconds to 15
seconds. There's also no point in continuing the test after a failure has
been seen.
Also added a missing sync_slaves to the database creation to make sure
they are created on all servers before the test starts.
The message now logs the instructions on how to increase the per-process
page limit for pipe buffers. This can happen if fs.pipe-max-size
multiplied by the number of workers exceeds the value of
fs.pipe-user-pages-soft multiplied by 4096.
Logging the pipe buffer size on startup will tell how large it was at the
time when MaxScale read it. If there are some abnormalities in it, this
will make it visible.
Logging the worker ID when the posting of a message fails will tell which
particular worker it was. For example, if the worker in question is the
main worker (i.e. ID 0), we know there's something that's blocking the
processing.
This allows the same verbose information to be logged in the cases where
it is of use. Mostly this information can be used to figure out why a
certain session was closed.
By doing the reconnection only when a new query arrives, we prevent the
excessive reconnecting that is done when a server's actual and monitored
states are in conflict.
Galeramon will now only use the larger cluster in case a split brain
situation occurs. If the clusters are of equal size, the one whose UUID
compares less will be used. This will guarantee that all MaxScales that
see the same picture will end up using the same cluster.
With this change, a parenthesized top-level SELECT, such as
"(SELECT f FROM t)" will be fully parsed. Before this change,
the statement was classified as invalid and would thus have
been sent to the master.
With this change also statements like
(SELECT f FROM t1) UNION (SELECT f FROM t2)
will be correctly classified, although only partially parsed.
With these changes
SET @saved_cs_client= @@character_set_client;
will be classified as QUERY_TYPE_USERVAR_WRITE and
SELECT 1 AS c1 FROM t1 ORDER BY ( SELECT 1 AS c2 FROM
t1 GROUP BY GREATEST(LAST_INSERT_ID(), t1.a) ORDER BY
GREATEST(LAST_INSERT_ID(), t1.a) LIMIT 1);
will be classified as QUERY_TYPE_READ|QUERY_TYPE_MASTER_READ
The TLS parameters were defined but the main parameter that enables it
wasn't automatically added. As the REST API documentation states that this
parameter does not need to be defined, the runtime configuration must add
it.
When a system test program is invoked with the flag '-l', it will
assume MaxScale is running on 127.0.0.1 using a configuration that
is compatible with the test.
NOTE: Currently any test that directly or indirectly sshes to the
MaxScale node will fail. With a bit of setup that could also
be made to work.