causal_reads does not work with servers that update their state via
mechanisms other than the standard replication. In practice this is just
another Galera limitation.
The settings "match", "exclude" and "options" are now explained once
in the general documentation. The individual filter documentation refers
to the general explanation.
The documentation stated that MVCC reads weren't safe with
transaction_replay when in reality they are not safe in general and
transaction_replay has no effect on it.
Queries such as SHOW TABLES FROM db1 are now routed to the backend with db1.
This gives the correct result as long as db1 is not sharded to multiple
backends.
This commit adds a new parameter that, when enabled, prunes the session
command history to a known length. This makes it possible to keep a
client-side pooled connection open indefinitely at the cost of making
reconnections theoretically unsafe. In practice the maximum history length
can be set to a value that encompasses a single session using the pooled
connection with no risk to session state integrity. The default history
length of 50 commands is quite likely to be adequate for the majority of
use-cases.
Both the replication lag and the message printing state are saved in SERVER,
although the values are mostly used by readwritesplit. A log message is printed
both when a server goes over the limit and when it comes back below.
Because of concurrency issues, a message may be printed multiple times before
different threads detect the new message state.
Documentation updated to explain the change.
The TOC was added only to the long documentation files to make them easier
to navigate. Also modified the headings for Avro and Binlog routers and did
some minor cleanup.
Enabling the feature by default prevents the master connection from dying
during times when there are very little or no writes. Having a modest ping
interval of 300 seconds serves to minimize the amount of extra work that
both MaxScale and the server have to do while still keeping the
connections in good shape.
The causal_reads_timeout default value is too long when considering the
behavioral changes that MXS-2141 introduced. With a 10 second default
value, a result is returned to the client in a reasonable amount of time.
With causal_reads enabled, the query would return with an error if the
slave was not able to catch up to the master fast enough. By automatically
retrying the query on the master, we're guaranteed that a valid result is
always returned to the client.
Now the test program will
1) Write to each node in a Galera cluster and verify that the data
ends up in the slave.
2) At the end of 1) execute STOP SLAVE and START SLAVE to check that
replication can be stopped and started again (won't work unless
each node has the same server_id and value for @@log_bin_basename).
3) Block the node BLR is replicating from and expect it to connect
to the next configured master and that replication continues to
work. Do that for all nodes.
4) Stop MaxScale and restart it and expect 3) to work. That checks
that BLR saves all necessary information in master.ini and is
capable of reading it.
Up until 2.1.12, if it in the configuration file said
'router_options=slave', the master was used if there were no
slaves at session creation time.
That broke in 2.1.13 as a side-effect of MXS-1516 that checks
at routing time whether the server initially selected as master
still is the master.
Now the required server status is stored separately for each
session, so that if the master was chosen, even though we have
'router_options=slave', we can turn on the SERVER_MASTER bit.
That allows us to handle the case correctly in connection_is_valid().
The safest way to stop the avrorouter is to stop replication and wait for
the conversion to halt. This was not previously documented and needs to be
mentioned in the router documentation.
