name_lookup() now returns all results given by getnameinfo(). When searching
for a server, finding one matching address in the lookup-results is enough for
a match.
Also, added a test for name_lookup(). The test is minimal on its own, as hardcoded
test cases are not generally valid.
When matching hostnames between MaxScale server configuration and the
SHOW SLAVE STATUS-output, use DNS-resolution if a simple string comparison
doesn't find an answer. Results of the resolution are saved to avoid
repeating the operation for the same address.
The settings are different from the other fields in that they should not change
on their own. Most manipulation functions only require the settings.
Also takes into use a class for host and port data.
The setting didn't work because the code updated a status flag which
would be overwritten before being read. Also, promotion code now checks
that the server is not in maintenance.
This prevents some questionable status assignments, but also means that
the Relay Master status can be lost if a slave goes down. This is
contrary to Master status which is not lost if slaves go down. Fixes
mxs1961_standalone_rejoin.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
Uses mostly the status functions for reading the flags. Strickly
speaking this breaks the REST API since in some cases (status combinations)
the printed string is different from what was printed before.
The monitor can now differentiate between slaves with a running
series of slave connections to the master from slaves with broken
links. Both still get the SERVER_SLAVE-flag if 'detect_stale_slave'
is on.
Also, relay servers must be running.
If auto_failover is disabled and an alternative master exists, the
monitor will swap the master. This may break replication, but the
situation requires that the dba has set up a cluster with multiple
masters.
The relay master status was assigned to a server based on the last known
replication status of the slaves that have at some point replicated from
it. This can cause false positives and the relay master status is assigned
to servers that have never been observed to act as relay masters.
