The possibility to have multiple cache rules in a cache
configuration file is now handled throughout the cache
filter.
The major difference is that while you earlier directly
queried the Cache whether data should be stored to the
cache and whether data in the cache should be used, you
now query the Cache whether data should be stored to the
cache and, if so, get a CacheRules object from which you
subsequently query whether data from the cache should
be used.
Added the `transaction_replay_max_size` parameter that controls the
maximum size of a transaction that can be replayed. If the limit is
exceeded, the stored statements are released thus preventing the
transaction from being replayed.
This limitation prevents accidental misuse of the transaction replaying
system when autocommit is disabled. It also allows the user to control the
amount of memory that MaxScale will use.
The transaction retrying behavior is now configurable and documented. The
`transaction_replay` parameter implicitly enables the required
functionality in the router that it needs.
In this case, the server was already a slave and is not being demoted. Also, the file may
contain queries which cannot be ran while a slave connection is running.
The REST API configuration documentation is now located after all other
global parameters in its own section. Added it to the ToC and put a link
to it into the REST API overview document.
Large session commands weren't properly handled which caused the router to
think that the trailing end of a multi-packet query was actually a new
query.
This cannot be confidently solved in 2.2 which is why the router session
is now closed the moment a large session command is noticed.
Also, the list of release notes have been removed from the upgrading
document. The referral to the ChangeLog remains. That way, the list
of release notes need not be maintained in several places.
Also, the list of release notes have been removed from the upgrading
document. The referral to the ChangeLog remains. That way, the list
of release notes need not be maintained in several places.
Enabling the session command history but limiting it to a history of 50
commands allows reconnections for sessions that don't change the state too
often.
As pooled connections will exceed this limit quite fast, they are not able
to reconnect to servers once connections are lost. To solve this problem,
the session command history needs a compaction process that removes
redundant history.
As they are deprecated, they should not be mentioned in the examples. Also
moved the router_options documentation under a Legacy Configuration
heading.
