The test should stop MaxScale when it is fixing the replication to prevent
the triggering of the standalone master detection.
Also removed leading spaces from the messages and fixed a possible crash with a
NULL value given to `ssh_node`.
If local address has been specified, then all connections created
using mxs_mysql_real_connect() will use that same local address as
well.
A system test has not been created as our VMs do not have more than
one usable IP-address. Locally it has been verified to work as
expected.
AdressSanitizer is a lightweight memory error detector that instruments at
compile time instead of at execution time. This allows serious memory
errors to be detected without the cost of slowing down the whole program
that often happens when Valgrind is used. It is also easier to enable for
test runs as it is a simple compiler flag.
This is a cherry-pick of fb9b027842a7b65c4826455cd34d88e2f5f28e79 from the
2.2 branch.
When MaxScale is starting, the loading of the listeners can take a while
if there are a large number of services and users to load. To signal this
to the user, progress messages should be logged after every service is
started.
When the test finishes and is about to check whether MaxScale is alive,
the servers should be cleared from maintenance mode and the replication
should be fixed. This way the test will clean up after itself.
When the test changes the master, it should reset the slave configuration
on the new master. This way no circular replication topologies are formed
and the monitor can be expected to perform correctly.
If a DCB is closed before a response to the handshake packet is received,
the DCB's session will point to the dummy session. In this case no error
should be written to the DCB.
This is a cherry-pick of commit f53e112bf49766f1cc55516c2d7ee571461d483f
from the 2.2 branch.
If the avrorouter is being build and the required libraries are not found,
the configuration process should fail. Adding the command to bypass this
into the error message should make it easier to disable this part if it is
not needed.
The message now states the impliciations of missing permissions. If the
MaxScale user does not have the permissions to view all databases, it will
only see its own databases.
A linefeed is whitespace, so given the rules
"\n"+ return '\n'
{SPACE} ;
a line consisting of space followed by a linefeed, will be matched
as space and not as a linefeed and hence will cause the parser to
barf.
"INTERVAL N <unit>" is now handled as an expression in itself and
as asuch will cause both statements such as
"SELECT '2008-12-31 23:59:59' + INTERVAL 1 SECOND;"
and
"select id from db2.t1 where DATE_ADD("2017-06-15", INTERVAL 10 DAY) < "2017-06-15";"
to be handled correctly. The compare test program contains some
heuristic checking, as the the embedded parser will in all cases
report date manipulation as the use of the add_date_interval()
function.
MySQLAuth requires the SHOW DATABASES privilege to see all the databases
so it should be checked that the current user has the permission. A
missing permission will cause errors that are hard to resolve.
When the IO thread of a relay master is stopped, the knowledge that it is
not a real master but a relay master is lost. To prevent this loss of
information, the master server's server_id value should always be stored
if it is available.
If a server is removed from a service, readconnroute will not verify that
the server it is connected to is still the same root master. This fixes
the regression of MXS-1418.
The output of `show threads` could have a negative historic thread load
average that could be explained by the overflow of the signed 32-bit
integer used to count the number of samples.
The time that each thread started to process an event for a DCB used an
old value that is no longer used. Updating this to DCB::last_read retains
the 2.0 behavior.
According to MXS-1644 the refreshing of users may cause a crash.
In that particular case, the refreshing is triggered by the
authentication failing due to the user having hit the
'max_user_connection' limit of the server.
That is, refreshing the users in the situation is never going to
change the end-result. With this change, the users will not be
refreshed in that case and hopefully the crash will be avoided.
Note that this is something of a workaround as the crash could not
be repeated and the refreshing of the users should obviously not
ever cause MaxScale to crash.
