hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch '2.2' into develop

Browse Source
This commit is contained in:
Johan Wikman
2018-01-02 10:13:57 +02:00
parent e0f5c48c16 cf29430476
commit 810a9d6183
444 changed files with 15589 additions and 6893 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Documentation/About/Limitations.md
View File

@ -130,10 +130,11 @@ can be influenced with the server priority mechanic described in the
### Avrorouter limitations (avrorouter)
The avrorouter does not support the following data types and conversions:
The avrorouter does not support the following data types, conversions or SQL statements:
* BIT
* Fields CAST from integer types to string types
* [CREATE TABLE ... AS SELECT statements](https://mariadb.com/kb/en/library/create-table/#create-select)
The avrorouter does not do any crash recovery. This means that the avro files
need to be truncated to valid block lengths before starting the avrorouter.

4
Documentation/Changelog.md
View File

@ -24,6 +24,8 @@
* KILL CONNECTION can now be used through MaxScale.
* Environment variables can now be used in the MaxScale configuration file.
* By default, MaxScale can no longer be run as root.
* The MySQL Monitor is now capable of performing failover and switchover of
the master. There is also limited capability for rejoining nodes.
For more details, please refer to:
* [MariaDB MaxScale 2.2.0 Release Notes](Release-Notes/MaxScale-2.2.0-Release-Notes.md)
@ -49,6 +51,8 @@ For more details, please refer to:
* MaxScale now supports IPv6
For more details, please refer to:
* [MariaDB MaxScale 2.1.13 Release Notes](Release-Notes/MaxScale-2.1.13-Release-Notes.md)
* [MariaDB MaxScale 2.1.12 Release Notes](Release-Notes/MaxScale-2.1.12-Release-Notes.md)
* [MariaDB MaxScale 2.1.11 Release Notes](Release-Notes/MaxScale-2.1.11-Release-Notes.md)
* [MariaDB MaxScale 2.1.10 Release Notes](Release-Notes/MaxScale-2.1.10-Release-Notes.md)
* [MariaDB MaxScale 2.1.9 Release Notes](Release-Notes/MaxScale-2.1.9-Release-Notes.md)

2
Documentation/Documentation-Contents.md
View File

@ -104,7 +104,7 @@ Module specific documentation.
- [Aurora Monitor](Monitors/Aurora-Monitor.md)
- [Galera Monitor](Monitors/Galera-Monitor.md)
- [Multi-Master Monitor](Monitors/MM-Monitor.md)
- [MySQL Monitor](Monitors/MySQL-Monitor.md)
- [MariaDB Monitor](Monitors/MariaDB-Monitor.md)
- [MySQL Cluster Monitor](Monitors/NDB-Cluster-Monitor.md)
## Protocols

2
Documentation/Getting-Started/Configuration-Guide.md
View File

@ -1448,7 +1448,7 @@ The use of monitors is highly recommended but it is also possible to run MariaDB
MaxScale without a monitor module. In this case an external monitoring system
which sets the status of each server via MaxAdmin is needed.
* [Mysql Monitor](../Monitors/MySQL-Monitor.md)
* [MariaDB Monitor](../Monitors/MariaDB-Monitor.md)
* [Galera Monitor](../Monitors/Galera-Monitor.md)
* [NDBCluster Monitor](../Monitors/NDB-Cluster-Monitor.md)
* [Multi-Master Monitor](../Monitors/MM-Monitor.md)

325
Documentation/Monitors/MySQL-Monitor.md → Documentation/Monitors/MariaDB-Monitor.md
View File

@ -1,24 +1,33 @@
# MySQL Monitor
# MariaDB Monitor
Up until MariaDB MaxScale 2.2.0, this monitor was called _MySQL Monitor_.
## Overview
The MySQL Monitor is a monitoring module for MaxScale that monitors a Master-Slave replication cluster. It assigns master and slave roles inside MaxScale according to the actual replication tree in the cluster.
The MariaDB Monitor is a monitoring module for MaxScale that monitors a Master-Slave
replication cluster. It assigns master and slave roles inside MaxScale according to
the actual replication tree in the cluster.
## Configuration
A minimal configuration for a monitor requires a set of servers for monitoring and a username and a password to connect to these servers.
A minimal configuration for a monitor requires a set of servers for monitoring
and a username and a password to connect to these servers.
```
[MySQL Monitor]
[MyMonitor]
type=monitor
module=mysqlmon
module=mariadbmon
servers=server1,server2,server3
user=myuser
passwd=mypwd
```
Note that from MaxScale 2.2.1 onwards, the module name is `mariadbmon`; up until
MaxScale 2.2.0 it was `mysqlmon`. The name `mysqlmon` has been deprecated but can
still be used, although it will cause a warning to be logged.
The user requires the REPLICATION CLIENT privilege to successfully monitor the state of the servers.
The user requires the REPLICATION CLIENT privilege to successfully monitor the
state of the servers.
```
MariaDB [(none)]> grant replication client on *.* to 'maxscale'@'maxscalehost';
@ -27,11 +36,12 @@ Query OK, 0 rows affected (0.00 sec)
## Common Monitor Parameters
For a list of optional parameters that all monitors support, read the [Monitor Common](Monitor-Common.md) document.
For a list of optional parameters that all monitors support, read the
[Monitor Common](Monitor-Common.md) document.
## MySQL Monitor optional parameters
## MariaDB Monitor optional parameters
These are optional parameters specific to the MySQL Monitor.
These are optional parameters specific to the MariaDB Monitor.
### `detect_replication_lag`
@ -117,13 +127,31 @@ server receive the master status. To do this:
- Manually disable `@@read_only` on the server which should be the master
This functionality is similar to the [Multi-Master Monitor](MM-Monitor.md)
functionality. The only difference is that the MySQL monitor will also detect
functionality. The only difference is that the MariaDB monitor will also detect
traditional Master-Slave topologies.
### `ignore_external_masters`
Ignore any servers that are not monitored by this monitor but are a part of the
replication topology. This option was added in MaxScale 2.1.12 and is disabled
by default.
MaxScale detects if a master server replicates from an external server. When
this is detected, the server is assigned the `Slave` and `Slave of External
Server` labels and will be treated as a slave server. Most of the time this
topology is used when MaxScale is used for read scale-out without master
servers, a Galera cluster with read replicas being a prime example of this
setup. Sometimes this is not the desired behavior and the external master server
should be ignored. Most of the time this is due to multi-source replication.
When this option is enabled, all servers that have the `Master, Slave, Slave of
External Server, Running` labels will instead get the `Master, Running` labels.
### `detect_standalone_master`
Detect standalone master servers. This feature takes a boolean parameter and is
disabled by default. In MaxScale 2.1.0, this parameter was called `failover`.
Detect standalone master servers. This feature takes a boolean parameter and
from MaxScale 2.2.1 onwards is enabled by default. Up until MaxScale 2.2.0 it
was disabled by default. In MaxScale 2.1.0, this parameter was called `failover`.
This parameter is intended to be used with simple, two node master-slave pairs
where the failure of the master can be resolved by "promoting" the slave as the
@ -184,6 +212,10 @@ the master.
The formula for calculating the actual number of milliseconds before the server
is labelled as the master is `monitor_interval * failcount`.
If automatic failover is enabled (`auto_failover=true`), this setting also
controls how many times the master server must fail to respond before failover
begins.
### `allow_cluster_recovery`
Allow recovery after the cluster has dropped down to one server. This feature
@ -201,73 +233,167 @@ external agent that automatically reintegrates failed servers into the
cluster. One of these agents is the _replication-manager_ which automatically
configures the failed servers as new slaves of the current master.
### `allow_external_slaves`
## Failover, switchover and auto-rejoin
Allow the use of external slaves. This option is enabled by default.
Starting with MaxScale 2.2.1, MariaDB Monitor supports replication cluster
modification. The operations implemented are: _failover_ (replacing a failed
master), _switchover_ (swapping a slave with a running master) and _rejoin_
(joining a standalone server to the cluster). The features and the parameters
controlling them are presented in this section.
If a slave server is replicating from a master that is not being monitored by
the MySQL monitor, the slaves will be assigned the _Slave of External Server_
status (a status mainly for informational purposes).
Both failover and switchover can be activated manually through MaxAdmin.
Failover selects the new master server automatically, switchover requires the
user to designate the new master as well as the current master. Example commands
are below:
When the `allow_external_slaves` option is enabled, the server will also be
assigned the _Slave_ status which allows them to be used like normal slave
servers. When the option is disabled, the servers will only receive the _Slave
of External Server_ status and they will not be used.
```
call command mysqlmon failover MyMonitor
call command mysqlmon switchover MyMonitor SlaveServ3 MasterServ
```
### `failover`
Failover can also activate automatically, if `auto_failover` is on. The
activation begins when the master has been down for a number of monitor
iterations defined in `failcount`.
When `auto-rejoin` is active, the monitor will try to rejoin standalone servers
and slaves replicating from the wrong master (any server not the cluster
master). These servers are redirected to replicate from the correct master
server, forcing the replication topology to a 1-master-N-slaves configuration.
All of the three features require that the monitor user (`user`) has the SUPER
privilege. In addition, the monitor needs to know which username and password a
slave should use when starting replication. These are given in
`replication_user` and `replication_password`.
### Limitations
Switchover and failover only understand simple topologies. They will not work if
the cluster has multiple masters, relay masters, or if the topology is circular.
The server cluster is assumed to be well-behaving with no significant
replication lag and all commands that modify the cluster complete in a few
seconds (faster than `backend_read_timeout` and `backend_write_timeout`).
The backends must all use GTID-based replication, and the domain id should not
change during a switchover or failover. Master and slaves must have
well-behaving GTIDs: no extra events on slave servers.
### Configuration parameters
#### `auto_failover`
Enable automated master failover. This parameter expects a boolean value and the
default value is false.
When the failover functionality is enabled, traditional MariaDB Master-Slave
clusters will automatically elect a new master if the old master goes down. The
failover functionality will not take place when MaxScale is configured as a
passive instance. For details on how MaxScale behaves in passive mode, see the
following documentation of `failover_timeout`.
When automatic failover is enabled, traditional MariaDB Master-Slave clusters
will automatically elect a new master if the old master goes down and stays down
a number of iterations given in `failcount`. Failover will not take place when
MaxScale is configured as a passive instance. For details on how MaxScale
behaves in passive mode, see the documentation on `failover_timeout` below.
If an attempt at failover fails or multiple master servers are detected, an
error is logged and the failover functionality is disabled. If this happens, the
cluster must be fixed manually and the failover needs to be re-enabled via the
REST API or MaxAdmin.
error is logged and automatic failover is disabled. If this happens, the cluster
must be fixed manually and the failover needs to be re-enabled via the REST API
or MaxAdmin.
**Note:** The monitor user must have the SUPER privilege if the failover feature
is enabled.
The monitor user must have the SUPER privilege for failover to work.
### `failover_timeout`
#### `auto_rejoin`
The timeout for the cluster failover in seconds. The default value is 90
Enable automatic joining of server to the cluster. This parameter expects a
boolean value and the default value is false.
When enabled, the monitor will attempt to direct standalone servers and servers
replicating from a relay master to the main cluster master server, enforcing a
1-master-N-slaves configuration.
For example, consider the following event series.
1. Slave A goes down
2. Master goes down and a failover is performed, promoting Slave B
3. Slave A comes back
Slave A is still trying to replicate from the downed master, since it wasn't
online during failover. If `auto_rejoin` is on, Slave A will quickly be
redirected to Slave B, the current master.
#### `replication_user` and `replication_password`
The username and password of the replication user. These are given as the values
for `MASTER_USER` and `MASTER_PASSWORD` whenever a `CHANGE MASTER TO` command is
executed.
Both `replication_user` and `replication_password` parameters must be defined if
a custom replication user is used. If neither of the parameters is defined, the
`CHANGE MASTER TO` command will use the monitor credentials for the replication
user.
The credentials used for replication must have the `REPLICATION SLAVE`
privilege.
#### `failover_timeout`
Time limit for the cluster failover in seconds. The default value is 90
seconds.
If no successful failover takes place within the configured time period, a
message is logged and the failover functionality is disabled.
message is logged and automatic failover is disabled.
This parameter also controls how long a MaxScale instance that has transitioned
from passive to active will wait for a failover to take place after an apparent
loss of a master server. If no new master server is detected within the
configured time period, the failover will be initiated again.
configured time period, failover will be initiated again.
### `switchover`
#### `verify_master_failure`
Enable switchover via MaxScale. This parameter expects a boolean value and
the default value is false.
Enable master failure verification for automatic failover. This parameter
expects a boolean value and the feature is enabled by default.
When the switchover functionality is enabled, a REST API endpoint will be
made available, using which switchover may be performed. The endpoint will
be available irrespective of whether MaxScale is in active or passive mode,
but switchover will only be attempted if MaxScale is in active mode and an
error logged if an attempt is made when MaxScale is in passive mode.
Switchover may also be triggered from MaxAdmin and the same rules regarding
active/passive holds.
The failure of a master can be verified by checking whether the slaves are still
connected to the master. The timeout for master failure verification is
controlled by the `master_failure_timeout` parameter.
It is safe to perform switchover even with the failover functionality
enabled, as MaxScale will disable the failover behaviour for the duration
of the switchover.
#### `master_failure_timeout`
Only if the switchover succeeds, will the failover functionality be re-enabled.
Otherwise it will remain disabled and must be turned on manually via the REST
API or MaxAdmin.
This parameter controls the period of time, in seconds, that the monitor must
wait before it can declare that the master has failed. The default value is 10
seconds. For failover to activate, the `failcount` requirement must also be met.
When switchover is iniated via the REST-API, the URL path looks as follows:
The failure of a master is verified by tracking when the last change to the
relay log was done and when the last replication heartbeat was received. If the
period of time between the last received event and the time of the check exceeds
the configured value, the slave's connection to the master is considered to be
broken.
When all slaves of a failed master are no longer connected to the master, the
master failure is verified and the failover can be safely performed.
If the slaves lose their connections to the master before the configured timeout
is exceeded, the failover is performed immediately. This allows a faster
failover when the master server crashes causing immediate disconnection of the
the network connections.
#### `switchover_timeout`
Time limit for cluster switchover in seconds. The default value is 90
seconds.
If no successful switchover takes place within the configured time period, a
message is logged and automatic failover is disabled, even if it was enabled
before the switchover attempt. This prevents further modifications to the
misbehaving cluster.
### Manual switchover and failover
Both failover and switchover can be activated manually through the REST API or
MaxAdmin. The commands are only performed when MaxScale is in active mode.
It is safe to perform switchover or failover even with `auto_failover` on, since
the automatic operation cannot happen simultaneously with the manual one.
If a switchover or failover fails, automatic failover is disabled. It can be
turned on manually via the REST API or MaxAdmin.
When switchover is iniated via the REST-API, the URL path is:
```
/v1/maxscale/mysqlmon/switchover?<monitor-instance>&<new-master>&<current-master>
```
@ -291,95 +417,13 @@ path for making `server4` the new master would be:
/v1/maxscale/mysqlmon/switchover?Cluster1&server4&server2
```
**Note:** The monitor user must have the SUPER privilege if the switchover
feature is enabled.
### `switchover_script`
*NOTE* By default, MariaDB MaxScale uses the MariaDB provided switchover
script, so `switchover_script` need not be specified.
This command will be executed when MaxScale has been told to perform a
switchover, either via MaxAdmin or the REST-API. The parameter should be an
absolute path to a command or the command should be in the executable path.
The user which is used to run MaxScale should have execution rights to the
file itself and the directory it resides in.
The REST-API path for manual failover is similar, although the `<new-master>`
and `<current-master>` fields are left out.
```
script=/home/user/myswitchover.sh current_master=$CURRENT_MASTER new_master=$NEW_MASTER
/v1/maxscale/mysqlmon/failover?Cluster1
```
In addition to the substitutions documented in
[Common Monitor Parameters](./Monitor-Common.md)
the following substitutions will be made to the parameter value:
* `$CURRENT_MASTER` will be replaced with the IP and port of the current
master. If the is no current master, the value will be `none`.
* `$NEW_MASTER` will be replaced with the IP and port of the server that
should be made into the new master.
The script should return 0 for success and a non-zero value for failure.
### `switchover_timeout`
The timeout for the cluster switchover in seconds. The default value is 90
seconds.
If no successful switchover takes place within the configured time period,
a message is logged and the failover (not switchover) functionality will not
be enabled, even if it was enabled before the switchover attempt.
### `replication_user`
The username of the replication user. This is given as the value for
`MASTER_USER` whenever a `CHANGE_MASTER_TO` command is executed.
Both `replication_user` and `replication_password` parameters must be defined if
a custom replication user is used. If neither of the parameters is defined, the
`CHANGE MASTER TO` command will use the monitor credentials for the replication
user.
The credentials used for replication must have the `REPLICATION SLAVE`
privilege.
### `replication_password`
The password of the replication user. This is given as the value for
`MASTER_USER` whenever a `CHANGE_MASTER_TO` command is executed.
See `replication_user` parameter documentation for details about the use of this
parameter.
### `verify_master_failure`
Enable master failure verification for failover. This parameter expects a
boolean value and the feature is enabled by default.
The failure of a master can be verified by checking whether the slaves are still
connected to the master. The timeout for master failure verification is
controlled by the `master_failure_timeout` parameter.
### `master_failure_timeout`
This parameter controls the period of time, in seconds, that the monitor must
wait before it can declare that the master has failed. The default value is 10
seconds.
The failure of a master is verified by tracking when the last change to the
relay log was done and when the last replication heartbeat was received. If the
period of time between the last received event and the time of the check exceeds
the configured value, the slave's connection to the master is considered to be
broken.
When all slaves of a failed master are no longer connected to the master, the
master failure is verified and the failover can be safely performed.
If the slaves lose their connections to the master before the configured timeout
is exceeded, the failover is performed immediately. This allows a faster
failover when the master server crashes causing immediate disconnection of the
the network connections.
## Using the MySQL Monitor With Binlogrouter
## Using the MariaDB Monitor With Binlogrouter
Since MaxScale 2.2 it's possible to detect a replication setup
which includes Binlog Server: the required action is to add the
@ -406,7 +450,8 @@ echo $message|mail -s "The event was $event for server $server." admin@my.org
```
Here is a monitor configuration that only triggers the script when a master or a slave server goes down.
Here is a monitor configuration that only triggers the script when a master
or a slave server goes down.
```
[Database Monitor]

2
Documentation/Reference/MaxAdmin.md
View File

@ -783,7 +783,7 @@ flags; the _set server_ and _clear server_ commands.
|slave |The server is a replication slave or is considered as a read only database |
|synced |The server is a fully fledged member of a Galera cluster |
|maintenance|The server is in maintenance mode. It won't be used by services or monitored by monitors |
|stale |The server is a [stale master server](../Monitors/MySQL-Monitor.md) |
|stale |The server is a [stale master server](../Monitors/MariaDB-Monitor.md) |
All status flags, with the exception of the maintenance flag, will be set by the
monitors that are monitoring the server. If manual control is required the

383
Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md
View File

@ -1,383 +0,0 @@
# MariaDB MaxScale 2.1.0 Release Notes -- 2017-02-16
Release 2.1.0 is a Beta release.
This document describes the changes in release 2.1.0, when compared to
release 2.0.4.
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## License
The license of MaxScale has been changed from MariaDB BSL 1.0 to MariaDB BSL 1.1.
For more information about MariaDB BSL 1.1, please refer to
[MariaDB BSL11](https://www.mariadb.com/bsl11).
## Changed Features
### `router_options` to Parameters
The `router_options` values can also be given as parameters to the service for
the _readwritesplit_, _schemarouter_ and _binlogrouter_ modules.
What this means is that in MaxScale 2.1 the following _readwritesplit_
configration.
```
[RW Split Router]
type=service
router=readwritesplit
servers=server1
user=maxuser
passwd=maxpwd
router_options=slave_selection_criteria=LEAST_ROUTER_CONNECTIONS,max_sescmd_history=10,disable_sescmd_history=false
```
Can also be written in the following form.
```
[RW Split Router]
type=service
router=readwritesplit
servers=server1
user=maxuser
passwd=maxpwd
slave_selection_criteria=LEAST_ROUTER_CONNECTIONS
max_sescmd_history=10
disable_sescmd_history=false
```
### Configuration Files
From 2.1.0 onwards MariaDB MaxScale supports hierarchical configuration
files. When invoked with a configuration file, e.g. `maxscale.cnf`, MariaDB
MaxScale looks for a directory `maxscale.cnf.d` in the same directory as the
configuration file, and reads all `.cnf` files it finds in that directory
hierarchy. All other files will be ignored.
Please see the
[Configuration Guide](../Getting-Started/Configuration-Guide.md#configuration)
for details.
### Readwritesplit `disable_sescmd_history` option
The default value for `disable_sescmd_history` is now true. This new default
value will prevent the excessive memory use of long-lived connections. In
addition to this, it was not optimal to enable this option while the default
value for `max_slave_connections` was 100%, effectively making it useless.
### Module configurations
MaxScale 2.1 introduces a new directory for module configurations. This new
directory can be used to store module specific configuration files.
Any configuration parameter that accepts a path will also support relative
paths. If a relative path is given, the path is interpreted relative to
the module configuration directory. The default value is
_/etc/maxscale.modules.d_.
For example, the `dbfwfilter` rule files could be stored in
_/etc/maxscale.modules.d/my_rules.txt_ and referred to with
`rules=my_rules.txt`.
For more details, refer to the documentation of _module_configdir_ in the
[Configuration Guide](../Getting-Started/Configuration-Guide.md)
### Logging
Before version 2.1.0, MaxScale created in the log directory a log file
maxscaleN.log, where N initially was 1 and then was increased every time
MaxScale was instructed (by sending the signal SIGUSR1 or via maxadmin)
to rotate the log file.
That has now been changed so that the name of the log file is *always*
maxscale.log and when MaxScale is instructed to rotate the log file,
MaxScale simply closes it and then reopens and truncates it.
To retain the existing log entries, you should first move the file to
another name (MaxScale continues writing to it) and then instruct
MaxScale to rotate the the log file.
```
$ mv maxscale.log maxscale1.log
$ # MaxScale continues to write to maxscale1.log
$ kill -SIGUSR1 <maxscale-pid>
$ # MaxScale closes the file (i.e. maxscale1.log) and reopens maxscale.log
```
This behaviour is now compatible with logrotate(8).
Further, if MaxScale is configured to use shared memory for the log file,
the file is created into the directory `/dev/shm/maxscale`. Earlier the
log file was created into the directory `/dev/shm/maxscale.PID`, where PID
was the pid of the MaxScale process.
In addition, there is now a mechanism that prevents the flooding of the log, in
case the same error occurs over and over again. That mechanism, which is enabled
by default, is configured using the new global configuration entry `log_throttling`.
For more information about this configuration entry, please see
[Global Settings](../Getting-Started/Configuration-Guide.md#global-settings).
### Readwritesplit Read Retry
In 2.1, Readwritesplit will retry failed SELECT statements that are
executed outside of transaction and with autocommit enabled. This allows
seamless slave failover and makes it transparent to the client.
Read the [Readwritesplit documentation](../Routers/ReadWriteSplit.md) on
`retry_failed_reads` for more details.
### Persistent Connections
Starting with the 2.1 version of MariaDB MaxScale, when a MySQL protocol
persistent connection is taken from the persistent connection pool, the
state of the MySQL session will be reset when the the connection is used
for the first time. This allows persistent connections to be used with no
functional limitations and makes them behave like normal MySQL
connections.
For more information about persistent connections, please read the
[Administration Tutorial](../Tutorials/Administration-Tutorial.md).
### User data cache
The user data cache stores the cached credentials that are used by some router
modules. In 2.1.0, the authenticator modules are responsible for the persisting
of the user data cache. Currently, only the MySQLAuth module implements user
data caching.
The user data loaded from the backend databases is now stored on a per listener
basis instead of a per service basis. In earlier versions, each service had its own
cache directory in `/var/cache/maxscale`. This directory contains cached user
data which is used there is no connectivity to the backend cluster.
In 2.1.0, each listener has its own sub-directory in the service cache
directory. The old caches in `/var/cache/maxscale` will need to be manually
removed if they are no longer used by older versions of MaxScale.
### Galeramon Monitoring Algorithm
The galeramon monitor will only choose nodes with a _wsrep_local_index_
value of 0 as the master. This allows multiple MaxScales to always choose
the same node as the write master node for the cluster. The old behavior
can be taken into use by disabling the new `root_node_as_master` option.
For more details, read the [Galeramon documentation](../Monitors/Galera-Monitor.md).
### MaxAdmin editing mode
MaxAdmin now defaults to Emacs editing mode instead of VIM. To activate
with VIM-mode start MaxAdmin with option -i.
### Named Server Filter
The source option can now handle wildcards such as:
192.168.%.%
For more details, read the [Named Server Filter documentation](../Filters/Named-Server-Filter.md).
## New Features
### Dynamic configuration
MaxScale 2.1 supports dynamic configuration of servers, monitors and
listeners. A set of new commands were added to maxadmin. See output of
`maxadmin help` and `maxadmin help { create | destroy | alter | add | remove }`
for more details.
#### Dynamic server configuration
MaxScale can now change the servers of a service or a monitor at run-time. New
servers can also be created and they will persisted even after a restart.
- `create server`: Creates a new server
- `destroy server`: Destroys a created server
- `add server`: Adds a server to a service or a monitor
- `remove server`: Removes a server from a service or a monitor
- `alter server`: Alter server configuration
- `alter monitor`: Alter monitor configuration
With these new features, you can start MaxScale without the servers and define
them later.
#### Dynamic listener configuration
New listeners for services can be created and destroyed at runtime. This allows
the services to adapt to changes in client traffic.
- `create listener`: Create a new listener
- `destroy listener`: Destroy a created listener. The listener will stop
handling client requests and will be removed after the next restart of
MaxScale.
In addition to these commands, individual listeners can now be stopped and started.
- `shutdown listener`: Stop a listener
- `restart listener`: Restart a listener
#### Dynamic monitor configuration
New monitors can be created, modified and destroyed at runtime. This allows new
clusters to be added into MaxScale by defining new monitors for them. The
monitor parameters can also be changed at runtime making them more adaptive and
allowing runtime tuning of parameters.
- `create monitor`: Create a new monitor
- `destroy monitor`: Destroy a created monitor
- `alter monitor`: Alter monitor parameters
### Module commands
Introduced in MaxScale 2.1, the module commands are special, module-specific
commands. They allow the modules to expand beyound the capabilities of the
module API. Currently, only MaxAdmin implements an interface to the module
commands.
All registered module commands can be shown with `maxadmin list commands` and
they can be executed with `maxadmin call command <module> <name> ARGS...` where
_<module>_ is the name of the module and _<name>_ is the name of the
command. _ARGS_ is a command specific list of arguments.
Read [Module Commands](../Reference/Module-Commands.md) documentation for more details.
In the 2.1 release of MaxScale, the [_dbfwfilter_}(../Filters/Database-Firewall-Filter.md),
[_avrorouter_](../Routers/Avrorouter.md), [_cache_](../Filters/Cache.md) and
[_masking_](../Filters/Masking.md) modules implement module commands.
### Amazon RDS Aurora monitor
The new [Aurora Monitor](../Monitors/Aurora-Monitor.md) module allows monitoring
of Aurora clusters. The monitor detects which of the nodes are read replicas and
which of them is the real write node and assigns the appropriate status for each
node. This module also supports launchable scripts on monitored events. Read the
[Monitor Common Documentation](../Monitors/Monitor-Common.md) for more details.
### Multi-master mode for MySQL Monitor
The MySQL monitor now detects complex multi-master replication
topologies. This allows the mysqlmon module to be used as a replacement
for the mmmon module. For more details, please read the
[MySQL Monitor Documentation](../Monitors/MySQL-Monitor.md).
### Failover mode for MySQL Monitor
A simple failover mode has been added to the MySQL Monitor. This mode is
aimed for two node master-slave clusters where the slave can act as a
master in case the original master fails. For more details, please read
the [MySQL Monitor Documentation](../Monitors/MySQL-Monitor.md).
### Permissive authentication mode for MySQLAuth
The MySQL authentication module supports the `skip_authentication` option which
allows authentication to always succedd in MaxScale. This option offloads the
actual authentication to the backend server and it can be used to implement a
secure version of a wildcard user.
### Consistent Critical Reads
MaxScale 2.1 comes with a new filter module, _ccrfilter_, which allows critical
reads to be routed to master after inserts. This will make reads after inserts
consistent while still allowing read scaling.
For more information, refer to the [CCRFilter](../Filters/CCRFilter.md)
documentation.
### Database Cache
A new filter module, _cache_, allows MaxScale to cache the results of SELECT
statements. This improves the performance of read-heavy workloads by reducing
the work the backend databases have to perform.
For more information, refer to the [Cache](../Filters/Cache.md) documentation.
### Result set masking
The new _masking_ filter can mask sensitive information from result sets. This
is commonly done to hide sensitive information while still allowing the database
to efficiently process the actual data.
For more information, refer to the [Masking](../Filters/Masking.md)
documentation.
### Result set limiting
The newly added _maxrows_ filter can restrict the maximum size of a returned
result set. This can be used to reduce the negative effects of unexpectedly
large result sets. It can also be used to improve security by preventing access
to large sets of data with a single query.
For more information, refer to the [Maxrows](../Filters/Maxrows.md)
documentation.
### Insert stream filter
The _insertstream_ filter converts bulk inserts into CSV data streams that are
consumed by the backend server via the LOAD DATA LOCAL INFILE mechanism. This
leverages the speed advantage of LOAD DATA LOCAL INFILE over regular inserts
while also reducing the overall network traffic by condensing the inserted
values into CSV.
For more information, refer to the [Insert Stream Filter](../Filters/Insert-Stream-Filter.md)
documentation.
### Galeramon Monitor new option
The `set_donor_nodes` option allows the setting of _global variable_ _wsrep_sst_donor_ with a list the preferred donor nodes (among slave ones).
For more details, read the [Galeramon documentation](../Monitors/Galera-Monitor.md).
### Binlog Server encrypted binlogs
The binlog server can optionally encrypt the events received from the master server: the setup requires MariaDB 10.1 master (with Encryption active) and the `mariadb10-compatibility=1` option set.
For more details, read the [Binlogrouter documentation](../Routers/Binlogrouter.md).
## Bug fixes
[Here is a list of bugs fixed since the release of MaxScale 2.0.4.](https://jira.mariadb.org/browse/MXS-951?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.1.0%20AND%20fixVersion%20!%3D%202.0.1%20AND%20fixVersion%20!%3D%202.0.2%20AND%20fixVersion%20!%3D%202.0.3%20AND%20fixVersion%20!%3D%202.0.4)
* [MXS-1025](https://jira.mariadb.org/browse/MXS-1025) qc_sqlite always reports " Statement was parsed, but not classified"
* [MXS-977](https://jira.mariadb.org/browse/MXS-977) MaxAdmin show monitor output missing formatting
* [MXS-951](https://jira.mariadb.org/browse/MXS-951) Using utf8mb4 on galera hosts stops maxscale connections
* [MXS-889](https://jira.mariadb.org/browse/MXS-889) "Ungrade Test" Jenkins job fails with CeentOS/RHEL 5 and SLES11
* [MXS-887](https://jira.mariadb.org/browse/MXS-887) create_env Jenkin job fails
* [MXS-873](https://jira.mariadb.org/browse/MXS-873) Changing server status via maxadmin is not atomic
* [MXS-832](https://jira.mariadb.org/browse/MXS-832) Problem with Regex filter as readconnroute doesn't wait for complete packets
* [MXS-831](https://jira.mariadb.org/browse/MXS-831) new_master event not triggered by galeramon
* [MXS-828](https://jira.mariadb.org/browse/MXS-828) Remove "Syslog logging is disabled." to stdout when starting without syslog
* [MXS-825](https://jira.mariadb.org/browse/MXS-825) --execdir option does not work
* [MXS-805](https://jira.mariadb.org/browse/MXS-805) Server weights don't work with LEAST_BEHIND_MASTER
* [MXS-804](https://jira.mariadb.org/browse/MXS-804) Grants for user@IP/Netmask doesn't work
* [MXS-799](https://jira.mariadb.org/browse/MXS-799) fatal signal 11 when socket could not be opened
* [MXS-769](https://jira.mariadb.org/browse/MXS-769) Malloc return value must be checked.
* [MXS-711](https://jira.mariadb.org/browse/MXS-711) All service ports use the same user data
* [MXS-650](https://jira.mariadb.org/browse/MXS-650) Connection attempt w/o SSL to SSL service gives confusing error
* [MXS-626](https://jira.mariadb.org/browse/MXS-626) Don't log anything to maxlog until it is known whether that is wanted.
* [MXS-590](https://jira.mariadb.org/browse/MXS-590) MaxScale doesn't log an error when .secrets file is not owned by current user
* [MXS-586](https://jira.mariadb.org/browse/MXS-586) Tee filter hangs when using range
* [MXS-576](https://jira.mariadb.org/browse/MXS-576) Maxscale does not generate warning/error if incorrect values is set for persistpoolmax
* [MXS-397](https://jira.mariadb.org/browse/MXS-397) Unsafe handling of dcb_readqueue
* [MXS-390](https://jira.mariadb.org/browse/MXS-390) Lack of checks of dynamic memory allocation
* [MXS-350](https://jira.mariadb.org/browse/MXS-350) Return value of realloc must not be assigned to provided pointer.
* [MXS-348](https://jira.mariadb.org/browse/MXS-348) Incorrect use of strncat
* [MXS-253](https://jira.mariadb.org/browse/MXS-253) Use of strncpy is dangerous
* [MXS-126](https://jira.mariadb.org/browse/MXS-126) debug assert in TEE filter test
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is X.Y.Z. Further, *master* always refers to the latest released non-beta version.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

103
Documentation/Release-Notes/MaxScale-2.1.1-Release-Notes.md
View File

@ -1,103 +0,0 @@
# MariaDB MaxScale 2.1.1 Release Notes -- 2017-03-14
Release 2.1.1 is a Beta release.
This document describes the changes in release 2.1.1, when compared to
release [2.1.0](MaxScale-2.1.0-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Changed Features
### Cache
* The cache will now _also_ be used and populated in a transaction that is
_not_ explicitly read only, but only until the first statement that modifies
the database is encountered.
* SELECT statements that refer to user or system variables are not cached.
* SELECT statements using functions whose result depend upon the current
user or context are not cached. Examples of such functions are `USER()`,
`RAND()` or `CURRENT_TIME()`.
### Firewall Filter
* Prepared statements are now treated exactly like non-prepared statements.
* Statements can now be accepted/rejected based upon function usage.
*NOTE* Both of these features were available already in _2.1.0_.
## Dropped Features
### MaxAdmin
The following deprecated commands have been removed:
* `enable log [debug|trace|message]`
* `disable log [debug|trace|message]`
* `enable sessionlog [debug|trace|message]`
* `disable sessionlog [debug|trace|message]`
The following commands have been deprecated:
* `enable sessionlog-priority <session-id> [debug|info|notice|warning]`
* `disable sessionlog-priority <session-id> [debug|info|notice|warning]`
The commands can be issued, but have no effect.
## New Features
### Failover Recovery for MySQL Monitor
The `failover_recovery` option allows the failed nodes to rejoin the cluster
after a failover has been triggered. This makes it possible for external actors
to recover the failed nodes without having to manually clear the maintenance
mode.
For more information about the failover mode and how it works, please read the
[MySQL Monitor](../Monitors/MySQL-Monitor.md) documentation.
### GSSAPI
_GASSAPI_ based authentication can now be used with MaxScale.
For more information, please read the
[GSSAPI Authentication](../Authenticators/GSSAPI-Authenticator.md) documentation.
NOTE This feature was available already in _2.1.0_.
## Bug fixes
[Here is a list of bugs fixed since the release of MaxScale 2.1.0.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.1.1%20AND%20fixVersion%20NOT%20IN%20(2.1.0))
* [MXS-1178](https://jira.mariadb.org/browse/MXS-1178) master_accept_reads doesn't work with detect_replication_lag
* [MXS-1165](https://jira.mariadb.org/browse/MXS-1165) MaxInfo eat too much memory when getting list of session and client.
* [MXS-1143](https://jira.mariadb.org/browse/MXS-1143) Add support for new MariaDB 10.2 flags
* [MXS-1130](https://jira.mariadb.org/browse/MXS-1130) Unexpected length encoding 'ff' encountered
* [MXS-1081](https://jira.mariadb.org/browse/MXS-1081) Avro data file corruption
* [MXS-1077](https://jira.mariadb.org/browse/MXS-1077) Resource Leak
* [MXS-759](https://jira.mariadb.org/browse/MXS-759) Starting MaxScale from command line fails on CentOS 7
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is X.Y.Z. Further, *master* always refers to the latest released non-beta version.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

66
Documentation/Release-Notes/MaxScale-2.1.10-Release-Notes.md
View File

@ -1,66 +0,0 @@
# MariaDB MaxScale 2.1.10 Release Notes -- 2017-10-30
Release 2.1.10 is a GA release.
This document describes the changes in release 2.1.10, when compared
to release [2.1.9](MaxScale-2.1.9-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
* [2.1.9](./MaxScale-2.1.9-Release-Notes.md)
* [2.1.8](./MaxScale-2.1.8-Release-Notes.md)
* [2.1.7](./MaxScale-2.1.7-Release-Notes.md)
* [2.1.6](./MaxScale-2.1.6-Release-Notes.md)
* [2.1.5](./MaxScale-2.1.5-Release-Notes.md)
* [2.1.4](./MaxScale-2.1.4-Release-Notes.md)
* [2.1.3](./MaxScale-2.1.3-Release-Notes.md)
* [2.1.2](./MaxScale-2.1.2-Release-Notes.md)
* [2.1.1](./MaxScale-2.1.1-Release-Notes.md)
* [2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug report at
[Jira](https://jira.mariadb.org).
## Changed Features
### Internal Query Retries
The internal SQL queries that MaxScale executes to load database users as well
as monitor the database itself can now be automatically retried if they are
interrupted. The new global parameter, `query_retries` controls the number of
retry attempts each query will receive if it fails due to a network problem.
The `query_retry_timeout` global parameter controls the total timeout for the
retries.
To enable this functionality, add `query_retries=<number-of-retries>` under the
`[maxscale]` section where _<number-of-retries>_ is a positive integer.
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.10.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.10)
* [MXS-1497](https://jira.mariadb.org/browse/MXS-1497) Don't skip events with LOG_EVENT_IGNORABLE_F flag
* [MXS-1468](https://jira.mariadb.org/browse/MXS-1468) Using dynamic commands to create readwritesplit configs fail after restart
* [MXS-1459](https://jira.mariadb.org/browse/MXS-1459) Binlog checksum default value is wrong if a slave connects with checksum = NONE before master registration or master is not accessible at startup
* [MXS-1457](https://jira.mariadb.org/browse/MXS-1457) Deleted servers are not ignored when users are loaded
* [MXS-1456](https://jira.mariadb.org/browse/MXS-1456) OOM when script variable is empty
* [MXS-1451](https://jira.mariadb.org/browse/MXS-1451) Password is not stored with skip_authentication=true
* [MXS-1450](https://jira.mariadb.org/browse/MXS-1450) Maxadmin commands with a leading space are silently ignored
* [MXS-1449](https://jira.mariadb.org/browse/MXS-1449) Database change not allowed
* [MXS-1163](https://jira.mariadb.org/browse/MXS-1163) Log flood using binlog server on Ubuntu Yakkety Yak
## Packaging
RPM and Debian packages are provided for the Linux distributions supported by
MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

27
Documentation/Release-Notes/MaxScale-2.1.11-Release-Notes.md → Documentation/Release-Notes/MaxScale-2.1.13-Release-Notes.md
View File

@ -1,13 +1,15 @@
# MariaDB MaxScale 2.1.11 Release Notes -- 2017-11-21
# MariaDB MaxScale 2.1.13 Release Notes
Release 2.1.11 is a GA release.
Release 2.1.13 is a GA release.
This document describes the changes in release 2.1.11, when compared
to release [2.1.10](MaxScale-2.1.10-Release-Notes.md).
This document describes the changes in release 2.1.13, when compared
to release [2.1.12](MaxScale-2.1.12-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
* [2.1.12](./MaxScale-2.1.12-Release-Notes.md)
* [2.1.11](./MaxScale-2.1.11-Release-Notes.md)
* [2.1.10](./MaxScale-2.1.10-Release-Notes.md)
* [2.1.9](./MaxScale-2.1.9-Release-Notes.md)
* [2.1.8](./MaxScale-2.1.8-Release-Notes.md)
@ -23,20 +25,15 @@ release notes:
For any problems you encounter, please consider submitting a bug report at
[Jira](https://jira.mariadb.org).
## Changed Features
### Peer Certificate Verification
The SSL peer certificate verification can now be disabled for servers and
listeners by adding `ssl_verify_peer_certificate=false` to the respective
definitions.
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.11.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.11)
[Here is a list of bugs fixed in MaxScale 2.1.13.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.13)
* [MXS-1518](https://jira.mariadb.org/browse/MXS-1518) Wrong parameter name for ssl_cert_verify_depth
* [MXS-1500](https://jira.mariadb.org/browse/MXS-1500) Invalid characters in real_type schema field
* [MXS-1585](https://jira.mariadb.org/browse/MXS-1585) Crash in MaxScale 2.1.12
* [MXS-1582](https://jira.mariadb.org/browse/MXS-1582) Maxscale leaving socket behind after shutdown
* [MXS-1581](https://jira.mariadb.org/browse/MXS-1581) CREATE TABLE AS not supported
* [MXS-1580](https://jira.mariadb.org/browse/MXS-1580) Invalid handling of BIT values
* [MXS-1527](https://jira.mariadb.org/browse/MXS-1527) SELECT with session var is not supported
## Packaging

91
Documentation/Release-Notes/MaxScale-2.1.2-Release-Notes.md
View File

@ -1,91 +0,0 @@
# MariaDB MaxScale 2.1.2 Release Notes -- 2017-04-03
Release 2.1.2 is a Beta release.
This document describes the changes in release 2.1.2, when compared to
release [2.1.1](MaxScale-2.1.1-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Changed Features
### Formatting of IP Addresses and Ports
All messaging that contains both the address and the port are now printed in an
IPv6 compatible format. The output uses the format defined in
[RFC 3986] (https://www.ietf.org/rfc/rfc3986.txt) and
[STD 66] (https://www.rfc-editor.org/std/std66.txt).
In practice this means that the address is enclosed by brackets. The port is
separated from the address by a colon. Here is an example of the new format:
```
[192.168.0.201]:3306
[fe80::fa16:54ff:fe8f:7e56]:3306
[localhost]:3306
```
The first is an IPv4 address, the second an IPv6 address and the last one is a
hostname. All of the addresses use port 3306.
### Cache
* The storage `storage_inmemory` is now the default, so the parameter
`storage` no longer need to be set explicitly.
### Improved Wildcard Matching
The MySQLAuth module now supports all types of wildcards for both IP addresses
as well as hostnames.
### Configurable Connector-C Plugin Directory
The Connector-C used by MaxScale can now be configured to load authentication
plugins from a specific directory with the new `connector_plugindir`
parameter. Read the [Configuration Guide](../Getting-Started/Configuration-Guide.md)
for more details about this new parameter.
## New Features
### IPv6 Support
MaxScale now supports IPv6 connections on both the client and backend side as
well as being able to listen on IPv6 addresses.
### ReadWriteSplit Connection Keepalive
The _readwritesplit_ module now implements a `connection_keepalive`
feature which allows sending of keepalive pings to idle connections. For
more details, read the [ReadWriteSplit documentation](../Routers/ReadWriteSplit.md).
## Bug fixes
[Here is a list of bugs fixed since the release of MaxScale 2.1.1.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.1.2%20AND%20fixVersion%20NOT%20IN%20(2.1.1))
* [MXS-1032](https://jira.mariadb.org/browse/MXS-1032) missing mysql_clear_password.so plugin
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is X.Y.Z. Further, *master* always refers to the latest released non-beta version.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

72
Documentation/Release-Notes/MaxScale-2.1.3-Release-Notes.md
View File

@ -1,72 +0,0 @@
# MariaDB MaxScale 2.1.3 Release Notes -- 2017-05-23
Release 2.1.3 is a GA release.
This document describes the changes in release 2.1.3, when compared to
release [2.1.2](MaxScale-2.1.2-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## MariaDB 10.2
MaxScale 2.1 has not been extended to understand all new features that
MariaDB 10.2 introduces. Please see
[Support for 10.2](../About/Support-for-10.2.md)
for details.
## Changed Features
### Cache
* The storage `storage_rocksdb` is no longer built by default and is
not included in the MariaDB MaxScale package.
### Maxrows
* It can now be specified whether the _maxrows_ filter should return an
empty resultset, an error packet or an ok packet, when the limit has
been reached.
Please refer to the
[maxrows documentation](../Filters/Maxrows.md)
for details.
## Bug fixes
[Here is a list of bugs fixed since the release of MaxScale 2.1.2.](https://jira.mariadb.org/browse/MXS-1212?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.1.3)
* [MXS-1263](https://jira.mariadb.org/browse/MXS-1263) broken TCP connections are not always cleaned properly
* [MXS-1244](https://jira.mariadb.org/browse/MXS-1244) MySQL monitor "detect_replication_lag=true" doesn't work with "mysql51_replication=true"
* [MXS-1227](https://jira.mariadb.org/browse/MXS-1227) Nagios Plugins broken by change in output of "show monitors" in 2.1
* [MXS-1221](https://jira.mariadb.org/browse/MXS-1221) Nagios plugin scripts does not process -S option properly
* [MXS-1213](https://jira.mariadb.org/browse/MXS-1213) Improve documentation of dynamic configuration changes
* [MXS-1212](https://jira.mariadb.org/browse/MXS-1212) Excessive execution time when maxrows limit has been reached
* [MXS-1202](https://jira.mariadb.org/browse/MXS-1202) maxadmin "show service" counters overflow
* [MXS-1200](https://jira.mariadb.org/browse/MXS-1200) config file lines limited to ~1024 chars
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

66
Documentation/Release-Notes/MaxScale-2.1.4-Release-Notes.md
View File

@ -1,66 +0,0 @@
# MariaDB MaxScale 2.1.4 Release Notes -- 2017-07-03
Release 2.1.4 is a GA release.
This document describes the changes in release 2.1.4, when compared to
release [2.1.3](MaxScale-2.1.3-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.3](./MaxScale-2.1.3-Release-Notes.md)
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Changed Features
### Masking
* The masking filter now has a default fill character `X`, which
is used if only a _value_ has been specified and the length of
the value does not match the length of the value received from
the server.
Please refer to the
[masking documentation](../Filters/Masking.md)
for details.
### maxadmin
* Error message for failed login attempt has been improved.
## Bug fixes
[Here is a list of bugs fixed since the release of MaxScale 2.1.3.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.4)
* [MXS-1308](https://jira.mariadb.org/browse/MXS-1308) Crash with multimaster=true in mysqlmon
* [MXS-1304](https://jira.mariadb.org/browse/MXS-1304) Invalid write in gw_str_xor
* [MXS-1299](https://jira.mariadb.org/browse/MXS-1299) CREATE TABLE LIKE fails with avrorouter
* [MXS-1296](https://jira.mariadb.org/browse/MXS-1296) Lowercase start transaction is not detected
* [MXS-1294](https://jira.mariadb.org/browse/MXS-1294) cdc_schema.py uses Python 3
* [MXS-1287](https://jira.mariadb.org/browse/MXS-1287) Slaves of external servers can't be used as slaves
* [MXS-1279](https://jira.mariadb.org/browse/MXS-1279) Runtime changes to monitor credentials expect wrong parameter names
* [MXS-1271](https://jira.mariadb.org/browse/MXS-1271) cdc.py consuming 100% of CPU and never sending to kafka
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

100
Documentation/Release-Notes/MaxScale-2.1.5-Release-Notes.md
View File

@ -1,100 +0,0 @@
# MariaDB MaxScale 2.1.5 Release Notes -- 2017-07-31
Release 2.1.5 is a GA release.
This document describes the changes in release 2.1.5, when compared to
release [2.1.4](MaxScale-2.1.4-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.4](./MaxScale-2.1.4-Release-Notes.md)
[2.1.3](./MaxScale-2.1.3-Release-Notes.md)
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Changed Features
### SSL CA Certificates
Before MaxScale 2.1.5, MaxScale would only use the first certificate file found
in the CA certificate file. In MaxScale 2.1.5, the first certificate is loaded
and the rest of the certificates on the file are stored in the chain store.
This change should not cause any changes in MaxScale's behavior.
### `root_node_as_master`
The galeramon parameter `root_node_as_master` is now disabled by default. The
option should be enabled when it is of great importance to know that all
MaxScale instances treat a shared Galera cluster in the same way.
### Schemarouter
Starting with MaxScale 2.1.5, the _schemarouter_ will prioritize the current
database over an explicit database if tables in the the current database are
used in a query.
### Dbfwfilter
The function type rule will now accept backtick quoted values. This allows
keywords such as `insert` and `function` to be used as values for a function
rule.
## New Features
### Schemarouter
A new parameter for the _schemarouter_ was added that allows deterministic
resolution of database mapping conflicts (i.e. the database exists on more than
one backend server).
The new `preferred_server` parameter takes a server name as its value. If a
database mapping conflict occurs, the server given as the parameter will have
preference. In practice, this means that databases on a central server can be
replicated to the shards for doing JOINs but writes to the replicate database
will still go to the central database.
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.5.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.5)
* [MXS-1335](https://jira.mariadb.org/browse/MXS-1335) root_node_as_master should not be enabled by default
* [MXS-1330](https://jira.mariadb.org/browse/MXS-1330) insertstream attempts to parse all buffers
* [MXS-1329](https://jira.mariadb.org/browse/MXS-1329) Using filters with SSL and keep alive can cause errors
* [MXS-1328](https://jira.mariadb.org/browse/MXS-1328) Strange behavior with routes between master / slaves
* [MXS-1326](https://jira.mariadb.org/browse/MXS-1326) Upgrade error on Ubuntu Xenial
* [MXS-1324](https://jira.mariadb.org/browse/MXS-1324) MaxScale 2.1.4 compiled without the avrorouter?
* [MXS-1323](https://jira.mariadb.org/browse/MXS-1323) Maxscale2.1.3 coredump
* [MXS-1319](https://jira.mariadb.org/browse/MXS-1319) Maxscale selecting extra whitespace while loading users
* [MXS-1318](https://jira.mariadb.org/browse/MXS-1318) Use SSL_CTX_use_certificate_chain_file in Maxscale to use CA signed certificates
* [MXS-1316](https://jira.mariadb.org/browse/MXS-1316) error using Kafka with binlog router
* [MXS-1313](https://jira.mariadb.org/browse/MXS-1313) Character set is not updated if servers are down
* [MXS-1312](https://jira.mariadb.org/browse/MXS-1312) Rule with only on_queries do not work
* [MXS-1311](https://jira.mariadb.org/browse/MXS-1311) Function type rule that blocks function results in syntax error
* [MXS-1310](https://jira.mariadb.org/browse/MXS-1310) schemarouter ignores local copy of duplicate schemas on JOIN
* [MXS-1309](https://jira.mariadb.org/browse/MXS-1309) ALTER TABLE detection is broken
* [MXS-1285](https://jira.mariadb.org/browse/MXS-1285) cannot stat `/usr/share/maxscale/upstart/maxscale.conf': No such file or directory
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

52
Documentation/Release-Notes/MaxScale-2.1.6-Release-Notes.md
View File

@ -1,52 +0,0 @@
# MariaDB MaxScale 2.1.6 Release Notes -- 2017-08-14
Release 2.1.6 is a GA release.
This document describes the changes in release 2.1.6, when compared to
release [2.1.5](MaxScale-2.1.5-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.5](./MaxScale-2.1.5-Release-Notes.md)
[2.1.4](./MaxScale-2.1.4-Release-Notes.md)
[2.1.3](./MaxScale-2.1.3-Release-Notes.md)
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.6.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.6)
* [MXS-1352](https://jira.mariadb.org/browse/MXS-1352) Not all query failures in monitors are reported
* [MXS-1351](https://jira.mariadb.org/browse/MXS-1351) Partially authenticated connections are put into the connection pool
* (MXS-1343)[https://jira.mariadb.org/browse/MXS-1343] MaxScale's binlogrouter does not send hostname to its master
* [MXS-1338](https://jira.mariadb.org/browse/MXS-1338) Buffer objects are bound to indiviudual buffers
## New Features
* It is now possible to configure the binlog router to identify itself
to the master using a custom hostname: [MXS-1343](https://jira.mariadb.org/browse/MXS-1343)
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.
For more information, please refer to the [Limitations](../About/Limitations.md) document.
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

74
Documentation/Release-Notes/MaxScale-2.1.7-Release-Notes.md
View File

@ -1,74 +0,0 @@
# MariaDB MaxScale 2.1.7 Release Notes -- 2017-09-11
Release 2.1.7 is a GA release.
This document describes the changes in release 2.1.7, when compared to
release [2.1.6](MaxScale-2.1.6-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.6](./MaxScale-2.1.6-Release-Notes.md)
[2.1.5](./MaxScale-2.1.5-Release-Notes.md)
[2.1.4](./MaxScale-2.1.4-Release-Notes.md)
[2.1.3](./MaxScale-2.1.3-Release-Notes.md)
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Changed Features
### Persistent connection statistics
The output of `show servers` now shows the number of times a connection was
taken from a server's pool as well as the ratio of connections taken from the
pool versus newly created connections.
### Logging
When known, the session id will be included in all logged messages. This allows
a range of logged messages related to a particular session (that is, client) to
be bound together, and makes it easier to investigate problems. In practice this
is visible so that if a logged message earlier looked like
```
2017-08-30 12:20:49 warning: [masking] The rule ...
```
it will now look like
```
2017-08-30 12:20:49 warning: (4711) [masking] The rule ...
```
where `4711` is the session id.
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.7.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.7)
* (MXS-1396)[https://jira.mariadb.org/browse/MXS-1396] Persistent connections hang with Percona Server 5.6.37-82.2-log
* (MXS-1395)[https://jira.mariadb.org/browse/MXS-1395] SELECT NAMES FROM TABLE is not parsed completely
* (MXS-1385)[https://jira.mariadb.org/browse/MXS-1385] Monitor script arguments can be truncated
* (MXS-1384)[https://jira.mariadb.org/browse/MXS-1384] maxscale.cnf script field length limitation
* (MXS-1380)[https://jira.mariadb.org/browse/MXS-1380] UNION is partially parsed
* (MXS-1379)[https://jira.mariadb.org/browse/MXS-1379] Undefined outcome on schemarouter query conflict
* (MXS-1375)[https://jira.mariadb.org/browse/MXS-1375] Reused connections get multiple replies to COM_CHANGE_USER
* (MXS-1374)[https://jira.mariadb.org/browse/MXS-1374] Persistent connections can't be altered at runtime
* (MXS-1366)[https://jira.mariadb.org/browse/MXS-1366] Abrupt disconnections with persistent connections
* (MXS-1365)[https://jira.mariadb.org/browse/MXS-1365] Write to invalid memory in avrorouter
* (MXS-1363)[https://jira.mariadb.org/browse/MXS-1363] Servers with zero weight aren't used by readconnroute
* (MXS-1341)[https://jira.mariadb.org/browse/MXS-1341] binlog checksums break avrorouter processing
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

48
Documentation/Release-Notes/MaxScale-2.1.8-Release-Notes.md
View File

@ -1,48 +0,0 @@
# MariaDB MaxScale 2.1.8 Release Notes -- 2017-09-20
Release 2.1.8 is a GA release.
This document describes the changes in release 2.1.8, when compared to
release [2.1.7](MaxScale-2.1.7-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following
release notes:
[2.1.7](./MaxScale-2.1.7-Release-Notes.md)
[2.1.6](./MaxScale-2.1.6-Release-Notes.md)
[2.1.5](./MaxScale-2.1.5-Release-Notes.md)
[2.1.4](./MaxScale-2.1.4-Release-Notes.md)
[2.1.3](./MaxScale-2.1.3-Release-Notes.md)
[2.1.2](./MaxScale-2.1.2-Release-Notes.md)
[2.1.1](./MaxScale-2.1.1-Release-Notes.md)
[2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.8.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.8)
* [MXS-1421](https://jira.mariadb.org/browse/MXS-1421) Even though limit is reached, maxrows continues to buffer resultset.
* [MXS-1418](https://jira.mariadb.org/browse/MXS-1418) remove server does not drain node
* [MXS-1414](https://jira.mariadb.org/browse/MXS-1414) About Presistent Connection Mysql Gone away
* [MXS-1412](https://jira.mariadb.org/browse/MXS-1412) Performance issue with MaxRows filter
* [MXS-1411](https://jira.mariadb.org/browse/MXS-1411) error : (46) [maxrows] Received data from the backend although we were expecting nothing.
* [MXS-1409](https://jira.mariadb.org/browse/MXS-1409) maxadmin socket with port results in help
* [MXS-1400](https://jira.mariadb.org/browse/MXS-1400) Crash with OpenSSL 1.1
* [MXS-1396](https://jira.mariadb.org/browse/MXS-1396) Persistent connections hang with Percona Server 5.6.37-82.2-log
## Packaging
RPM and Debian packages are provided for the Linux distributions supported
by MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

45
Documentation/Release-Notes/MaxScale-2.1.9-Release-Notes.md
View File

@ -1,45 +0,0 @@
# MariaDB MaxScale 2.1.9 Release Notes -- 2017-09-25
Release 2.1.9 is a GA release.
This document describes the changes in release 2.1.9, when compared to release
[2.1.8](MaxScale-2.1.8-Release-Notes.md).
If you are upgrading from release 2.0, please also read the following release
notes:
* [2.1.8](./MaxScale-2.1.8-Release-Notes.md)
* [2.1.7](./MaxScale-2.1.7-Release-Notes.md)
* [2.1.6](./MaxScale-2.1.6-Release-Notes.md)
* [2.1.5](./MaxScale-2.1.5-Release-Notes.md)
* [2.1.4](./MaxScale-2.1.4-Release-Notes.md)
* [2.1.3](./MaxScale-2.1.3-Release-Notes.md)
* [2.1.2](./MaxScale-2.1.2-Release-Notes.md)
* [2.1.1](./MaxScale-2.1.1-Release-Notes.md)
* [2.1.0](./MaxScale-2.1.0-Release-Notes.md)
For any problems you encounter, please consider submitting a bug report at
[Jira](https://jira.mariadb.org).
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.1.9.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.1.9)
* [MXS-1435](https://jira.mariadb.org/browse/MXS-1435) Persistent connections can hang on COM_QUIT
* [MXS-1377](https://jira.mariadb.org/browse/MXS-1377) maxscale doesn't cleanup pid file on startup error
* [MXS-1295](https://jira.mariadb.org/browse/MXS-1295) MaxScale's readwritesplit router does not take into account the fact that stored procedure call may change the value of a user variable
## Packaging
RPM and Debian packages are provided for the Linux distributions supported by
MariaDB Enterprise.
Packages can be downloaded [here](https://mariadb.com/resources/downloads).
## Source Code
The source code of MaxScale is tagged at GitHub with a tag, which is identical
with the version of MaxScale. For instance, the tag of version X.Y.Z of MaxScale
is maxscale-X.Y.Z.
The source code is available [here](https://github.com/mariadb-corporation/MaxScale).

78
Documentation/Release-Notes/MaxScale-2.2.1-Release-Notes.md
View File

@ -8,6 +8,12 @@ release 2.2.0.
For any problems you encounter, please consider submitting a bug
report at [Jira](https://jira.mariadb.org).
## Update from 2.2.0
Since version 2.2.0 MaxScale binlog server can accept GTID
slave registration from MariaDB 10.X slaves and can also
register to Master server MariaDB 10.x using GTID.
## Changed Features
### Process identity
@ -29,18 +35,72 @@ root@host:~# maxscale --user=root ...
* The `mariadb10_slave_gtid` parameter was removed and slave connections can now
always register with MariaDB 10 GTID.
This means the gtid_maps SQLite database is always updated.
* The `binlog_structure` parameter was removed and the binlogs are stored
automatically in 'tree' mode when `mariadb10_master_gtid` is enabled.
automatically in 'tree' mode when `mariadb10_master_gtid` is enabled
(GTID registration to master).
* If `mariadb10_master_gtid` is enabled, the `transaction_safety` is
automatically enabled. In MaxScale 2.2.0, if `transaction_safety` was disabled
when `mariadb10_master_gtid` was enabled MaxScale would refuse to start.
### MySQL Monitor
Renamed to [MariaDB Monitor](../Monitors/MariaDB-Monitor.md).
Note that this affects the module name as well. Up until MaxScale 2.2.0
a configuration section referring to this monitor would look like
```
[MyMonitor]
type=monitor
module=mysqlmon
...
```
but from MaxScale 2.2.1 onwards it should look like
```
[MyMonitor]
type=monitor
module=mariadbmon
...
```
The name `mysqlmon` has been deprecated but can still be used, although it will
cause a warning to be logged.
### MariaDB Monitor
The default value of the configuration parameter `detect_standalone_master` has
been changed from `false` to `true`.
### ReadWritesplit
The default value of `strict_multi_stmt` was changed to `false` to make
usage of atomic compound statements and multi-statement queries less
restrictive and to align it with the default value of `strict_sp_calls`.
Most cases where the functionality of `strict_multi_stmt` was triggered
were cases where the added safety of locking a session to the master did
more harm than it did good.
The only case where `strict_multi_stmt` should be enabled is when a
multi-statement or a compound statement modifies the state of the
session. This is not a good practice and a change in the client side
behavior is advised.
## Dropped Features
## New Features
### MariaDB Monitor
MariaDB Monitor can now perform *failover* (replace a dead master), *switchover*
(replace a running master) and *rejoin* (join a standalone node to the
master-slave cluster). All of these features only work with a simple 1-master
N-slaves cluster using Gtid replication. Failover and switchover can be
activated through maxadmin or the REST-API. Failover and rejoin can be set to
activate automatically. For more information, see the
[MariaDB Monitor documentation](../Monitors/MariaDB-Monitor.md).
### REST API Relationship Endpoints
The _servers_, _monitors_ and _services_ types now support direct updating of
@ -69,10 +129,26 @@ and the configuration value is replaced with the value of the environment
variable. For more information please consult the
[Configuration Guide](../Getting-Started/Configuration-Guide.md).
### Cache behaviour in transactions
It can now be specified how the cache should be behave when a transaction
is active. Please refer to the [documentation](../Filters/Cache.md)
for details.
## Bug fixes
[Here is a list of bugs fixed in MaxScale 2.2.1.](https://jira.mariadb.org/issues/?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Closed%20AND%20fixVersion%20%3D%202.2.1)
* [MXS-1545](https://jira.mariadb.org/browse/MXS-1545) Fix GTID connecting slave error detections
* [MXS-1525](https://jira.mariadb.org/browse/MXS-1525) Firewall filter does not check exact match for host
* [MXS-1519](https://jira.mariadb.org/browse/MXS-1519) Firewall instances can interfere with each other
* [MXS-1517](https://jira.mariadb.org/browse/MXS-1517) Retain stale master status even if the master goes down
* [MXS-1499](https://jira.mariadb.org/browse/MXS-1499) Add missing fields to SHOW ALL SLAVES STATUS
* [MXS-1486](https://jira.mariadb.org/browse/MXS-1486) The cache does not always update the cached entry even if it could
* [MXS-1461](https://jira.mariadb.org/browse/MXS-1461) NOT operation needed for firewall rule
* [MXS-1408](https://jira.mariadb.org/browse/MXS-1408) maxadmin not working in latest version
* [MXS-1327](https://jira.mariadb.org/browse/MXS-1327) set log-priority by maxadmin
## Known Issues and Limitations
There are some limitations and known issues within this version of MaxScale.

1
Documentation/Routers/Binlogrouter.md
View File

@ -362,7 +362,6 @@ follows.
[Replication]
type=service
router=binlogrouter
servers=masterdb
user=maxscale
passwd=maxpwd
server_id=3

24
Documentation/Routers/ReadWriteSplit.md
View File

@ -220,21 +220,23 @@ router_options=master_accept_reads=true
### `strict_multi_stmt`
When a client executes a multi-statement query, all queries after that will be
routed to the master to guarantee a consistent session state. This behavior can
be controlled with the **`strict_multi_stmt`** router option. This option is
enabled by default.
This option is disabled by default since MaxScale 2.2.1. In older versions, this
option was enabled by default.
If set to false, queries are routed normally after a multi-statement query.
When a client executes a multi-statement query, it will be treated as if it were
a DML statement and routed to the master. If the option is enabled, all queries
after a multi-statement query will be routed to the master to guarantee a
consistent session state.
**Warning:** this can cause false data to be read from the slaves if the
multi-statement query modifies the session state. Only disable the strict mode
if you know that no changes to the session state will be made inside the
multi-statement queries.
If the feature is disabled, queries are routed normally after a multi-statement
query.
**Warning:** Enable the strict mode only if you know that the clients will send
statements that cause inconsistencies in the session state.
```
# Disable strict multi-statement mode
router_options=strict_multi_stmt=false
# Enable strict multi-statement mode
router_options=strict_multi_stmt=true
```
### `strict_sp_calls`

10
Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md
View File

@ -372,6 +372,11 @@ Examples with SSL options:
Binlog Router Plugin is compatible with MariaDB 5.5, 10.0, 10.1 and 10.2 as well
as MySQL 5.6 and 5.7.
Note: When using MariaDB 10.2 or MySQL 5.7 the `send_slave_heartbeat` option
must be set to On as the slave servers request the hearbeat to MaxScale.
As an alternative use `CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD=0` in
the slave server in order to disable the heartbeat request.
## Enabling MariaDB 10 compatibility
MariaDB 10 has different slave registration phase so an extra option is required:
@ -396,6 +401,11 @@ with MySQL 5.7 slaves the `send_slave_heartbeat` option must be set to on.
Binlog Router currently does not work for MySQL 5.5 due to missing
*@@global.binlog_checksum* variable.
## MariaDB Limitations
Starting from version 10.2 there are new replication events related
to binlog event compression: these new events are not supported yet.
Be sure that `log_bin_compress` is not set in any MariaDB 10.2 server.
# MariaDB MaxScale Replication Diagnostics
The binlog router module of MariaDB MaxScale produces diagnostic output that can

2
Documentation/Upgrading/Upgrading-To-MaxScale-2.1.md
View File

@ -7,6 +7,8 @@ For more information about MariaDB MaxScale 2.1, please refer to the
[ChangeLog](../Changelog.md).
For a complete list of changes in MaxScale 2.1, refer to the
* [MaxScale 2.1.13 Release Notes](../Release-Notes/MaxScale-2.1.13-Release-Notes.md)
* [MaxScale 2.1.12 Release Notes](../Release-Notes/MaxScale-2.1.12-Release-Notes.md)
* [MaxScale 2.1.11 Release Notes](../Release-Notes/MaxScale-2.1.11-Release-Notes.md)
* [MaxScale 2.1.10 Release Notes](../Release-Notes/MaxScale-2.1.10-Release-Notes.md)
* [MaxScale 2.1.9 Release Notes](../Release-Notes/MaxScale-2.1.9-Release-Notes.md).

8
Documentation/Upgrading/Upgrading-To-MaxScale-2.2.md
View File

@ -6,7 +6,8 @@ This document describes possible issues upgrading MariaDB MaxScale from version
For more information about MariaDB MaxScale 2.2, please refer to the
[ChangeLog](../Changelog.md).
For a complete list of changes in MaxScale 2.2.0, refer to the
For a complete list of changes in MaxScale 2.2, refer to the
[MaxScale 2.2.1 Release Notes](../Release-Notes/MaxScale-2.2.1-Release-Notes.md).
[MaxScale 2.2.0 Release Notes](../Release-Notes/MaxScale-2.2.0-Release-Notes.md).
Before starting the upgrade, we recommend you back up your current configuration
@ -24,3 +25,8 @@ Modules may now use a built-in regular expression string parameter type instead
of a normal string when accepting patterns. The modules that use the new regex
parameter type are *qlafilter* and *tee*. When inputting pattern, enclose the
string in slashes, e.g. `match=/^select/` defines the pattern `^select`.
### Binlog Server
Binlog server automatically accepts GTID connection from MariaDB 10 slave servers
by saving all incoming GTIDs into a SQLite map database.