1) Only two backends are set up for extra-port
2) The setting is checked to work by connecting directly to servers
3) The server connections are saturated before starting MaxScale
4) MaxScale logs are checked for extra-port-related messages
Made sure that the inserted row is replicated before inserting another
one. Shortened the test so that slower systems finish it within a
reasonable time. Increased the time that the writes are routed to the
master.
The `global` parameter causes the time window defined by the `time`
parameter to be applied at the instance level instead of the session
level. This means that a write from one connection will cause all other
connections to use the master for a certain period of time.
Using a configurable time window for consistency is not good as it is not
absolute and cannot adjust to how servers behave.
One example that demonstrates this is when a slave is normally lagging
behind by less than a second but some event causes the lag to spike up to
several seconds. In this case the configured time window would no longer
guarantee consistency.
Another reason to avoid a "static" time window is the fact taht it
prevents load balancing in the cases where slaves catch up to the master
within time window. This happens when time is configured to a higher value
to avoid inconsistencies at all costs.
Added a test case that verified the feature works.
Due to incorrect SSL certs copying to backend and wrong setting in
maxscale.cnf it was not possible to active backend SSL.
Additionally, one more maxscale restart added to 'sql_queries' test
to reproduce SSL bug in 2.4.1.
Also ssl.cnf tuned in order to reproduce SSL bug
The test case covers a few bugs that were fixed by the previous
commits. The first part of the test covers the case when master
reconnection fails while session command history is being executed. The
second part of the test makes sure exceeding the session command history
will prevent master reconnections from taking place.
The hard limit of 10 seconds is too strict when taking into account the
fact that infinite refreshes was possible before the bug was fixed. This
also makes testing a lot easier where rapid reloads are necessary.
The test appears to fail when the throttling is unable to keep the QPS
high enough for the test to pass. To reduce the likelihood of this, lower
the limit to 500 QPS.
In theory, the minimum delay of one millisecond in the delayed_call limits
the filter to a maximum QPS of 1000 as each query would wait for at least
a millisecond before being routed. This is yet to be proven but it would
explain why the tests are having a hard time approaching that level of
QPS.
Very simple, creates 10 threads that concurrently starts making
simple INSERTs and SELECTs. The purpose is to test that the basic
router to router mechanism of smartrouter works.
The test performs the following:
CREATE tbl (x INT PRIMARY KEY)
t1 t2
BEGIN BEGIN
INSERT INTO tbl VALUES (1)
SELECT * FROM tbl FOR UPDATE
That will cause t2 to wait.
INSERT INTO tbl VALUES (0)
That will cause t2 to be rolled back due to a deadlock.
Without transaction replay, the SELECT will return with an error.
With transaction replay, the deadlock error will be caught, the
transaction replayed and SELECT will return successfully.
Before the MXS-2250 fix, the following ends with an error:
CREATE TEMPORARY TABLE t (f INT);
DESCRIBE t;
Reason is that the first is sent to the master (and the table will
not be replicated to slaves) and the latter to some slave.
The bug appears when a session command that is executed on the master
fails. The logic in the code doesn't take this case into consideration
when it processes failed connections.
