Timing out the statements and adding a LIMIT clause to the DELETE
statement should rule out backend server related problems. If the test
still times out, the problem is most likely in MaxScale.
This commit introduces changes that fix the relay master detection that
was broken by the merge from 2.1 into 2.2 by commit
1ecd791887994209eb29e56e1271f8c407cd0cdf.
In 2.2, the master server ID is used to detect whether a slave is actually
replicating from a master. The value is still displayed even if the slave
is not actively replicating from a master. The commit in 2.1 causes this
value to be stored unconditionally if it is available. By checking the
value of Last_IO_Errno and comparing it to a list of known error codes, we
know whether the slave is replicating properly.
The slave detection in 2.2 correctly identifies a broken slave with a
stopped IO thread. Due to this, the test case must be modified to check
that the relay master is not a slave if the IO thread is stopped.
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.
The test appears to fail due to connection errors when it attempts to
check whether MaxScale is still alive. To offset the chance of the backend
server still refusing connections after the initial spike, the sleep
before the check was increased.
The code had a note in that states that the test uses custom code
backported from 2.2 and that it should be updated to use common code once
merged into 2.2.
Added a small sleep to make sure the monitor picks up the changes in the
topology.
When MaxScale thinks that the master has failed, it tries to verify it by
seeing if the slave server is receiving events. There was a missing IO
thread status check in the slave_receiving_events function which caused
the failover to wait until the verification timed out.
The relay master detection logic also lacked a check for the slave SQL
thread status. The code should check the state of the SQL thread to
determine whether the server is actually a functional slave to a master.
Removed the `socket` options from the network listeners.
Updated wording for the listener sections to only mention network
ports. This makes the tutorial more concise.
The password encryption was documented in the installation instructions
and the main configuration document referred to it as a "section" in the
same document. Having it in the main configuration document makes it the
authoritative source of information.
The fix causes a regression in the failover functionality as there is a
dependency between the slave's master ID and how the failover
performs. This dependency should not exist but fixing it causes a problem
with the mysqlmon_rejoin_bad2 test.
The variable containing the number of workers must be updated
only after the workers have been successfully created.
Failure to do this led to crash in Worker::shutdown_all() if a
terminating signal was received after the worker initialization
had failed.
Instead of trying to figure out whether the kernel supports O_DIRECT
in conjunction with pipes, let's just use it and if it fails, try
without O_DIRECT.
Case in point, based on circumstantial evidence it seems that in a
container context, it may appear as if the kernel supports O_DIRECT
when it in reality does not. So better to use brute-force.
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.
If a listener section specifies both a 'socket' and a 'port' the
creation will fail with a clear error message.
If 'address' and 'socket' is specified, there will be a warning that
the address is meaningless.
It is now impossible to create two listeners for a service that
would listen on the same port/socket (as before), but the error
message is now sensible and provides detailed information to the
user.
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 terminal configuration fails, it usually means that no terminal
is attached to the controlling process. This is the case when scripts are
executed automatically by daemon processes. To allow maxadmin use without
a controlling terminal, the editline library functionality must not be
used when the terminal setup fails.
To facilitate this fix, a minor refactoring of the code was done to split
the parts that use editline into separate functions. This allows simple
and easy fallback to non-editline code in the case that editline is
available but the terminal is not interactive.
When backend SSL connections were created, the connection creation was
done twice. This was due to the lacking detection of an already
established SSL connection.
When readwritesplit receives a reply from a backend, an info level log
message is now logged. This allows easier debugging of situations where
replies aren't properly returned by the router.
When the -p parameter is given without an argument, the password is read
from the command line. This allows passwords to be given to MaxCtrl in a
safer manner.
When MaxAdmin would be used without a controlling terminal, it would
refuse to accept passwords from stdin as it could not set the terminal
attributes. This means that executing MaxAdmin commands from other
programs would fail if the process had no controlling terminal.
Turning the error into a warning will allow users to know that terminal
echo is still enabled before they type their passwords.
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.
