The STL regex implementations have proven to be unreliable on older
systems and replacing the regex with hand-written code for version
extraction is less prone to break.
The test seems to fail from time to time due to the monitor not picking up
the master state fast enough. To prevent this, the test needs to wait for
at least one monitor interval.
If the monitor setting "replication_master_ssl" is set to on, any CHANGE MASTER TO-command
will have MASTER_SSL=1. If set to off or unset, MASTER_SSL is left unchanged to match existing
behaviour.
Basic tests can be executed with 15 machines Master/slave backend. Tests have label BIG_REPL_BACKEND Default template modified to support big backend. Tests temporaraly labeled as UNSTABLE to prevent their execution nightly
If case of MDBCI_VM_PATH variable does not have trailing slash full names of _network_config
and _lables files are defined in the wrong way: MDBCI_VM_PATH is interpreted as a part of file name
instead of direcoty name
In case when nodes/servers/replication/etc in backend are broken test can not
get proper version information and exits without doing anything.
To avoid it, test first checks backend, call fix_replication() if needed
and only after that tris to check if backend version is ok for this test
Recognize the XA keyword and classify the statement as write.
Needs to be dealt with explicitly as sqlite3 assumes there are
no keywords starting with the letter X.
The largest part of the code deals with the start of a response. Moving
this into a subfunction makes the function clearer as the switch statement
inside a switch statement is removed.
By processing the packets one at a time, the reply state is updated
correctly regardless of how many packets are received. This removes the
need for the clunky code that used modutil_count_signal_packets to detect
the end of the result set.
The checking of MariaDB and Galera nodes is now done asynchronously while
the MaxScale check is done which leads to faster testing. Rough
measurements show that doing all the work in parallel reduces test startup
time by two seconds. Most of the time appears to still be in the MaxScale
startup which takes on average three to four seconds per test.
The numeric values of the labels aren't of value when inspecting test
results. For this reason, it makes sense to put them behind the verbose
flag to make test framework debugging happen purpose.
The new `force=yes` option closes all connections to the server that is
being put into maintenance mode. This will immediately close all open
connections to the server without allowing results to return.
Given the assumption that queries are rarely 16MB long and that
realistically the only time that happens is during a large dump of data,
we can limit the size of a single read to at most one MariaDB/MySQL packet
at a time. This change allows the network throttling to engage a lot
sooner and reduces the maximum overshoot of throtting to 16MB.
By logging the connection ID for each created connection, failures can be
traced back from the backend server all the way up to the client
application.
If a transaction replay has to be executed twice due to a failure of the
original candidate master, the query queue could contain replayed
queries. The replayed queries would be placed into the queue if a new
connection needs to be created before the transaction replay can start.
Backported the changes that convert the query queue in readwritesplit into
a proper queue. This changes combines both
5e3198f8313b7bb33df386eb35986bfae1db94a3 and
6042a53cb31046b1100743723567906c5d8208e2 into one commit.
The load_persisted_configs parameter now controls whether persisted
runtime changes are loaded on startup. The changes are still generated as
it persists the current state of MaxScale making problem analysis easier.
By storing the queries in the query queue and routing it once the
transaction replay is done, we prevent two problems:
* Multiple transaction replays would overwrite the m_interrupted_query
buffer that was used to store any queries executed during the
transaction replay.
* Incorrect ordering of queries when the query queue is not empty and a
new query is executed during transaction replay.
If the session starts with no master but later one becomes available, when
a transaction is started the code would unconditionally use the master's
name in a log message.
