hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
d65c15d6f28690fe6119f05503a80042dac403f2
MaxScale/Documentation/Release-Notes/MaxScale-2.2.1-Release-Notes.md
Markus Mäkelä d4aeca0d24 Change strict_multi_stmt default value 
The default value for strict_multi_stmt prevents compound statements and
atomic multi-statement commands from being executed without completely
disabling load balancing. As the new default value will have no practical
effect on all correct uses of readwritesplit, this is a relatively safe
thing to change.
2017-12-21 10:48:07 +02:00

6.1 KiB
Raw Blame History

MariaDB MaxScale 2.2.1 Release Notes

Release 2.2.1 is a Beta release.

This document describes the changes in release 2.2.1, when compared to release 2.2.0.

For any problems you encounter, please consider submitting a bug report at Jira.

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

By default, MaxScale can no longer be run as root, but must be run as some other user. However, it is possible to start MaxScale as root, as long as the user to run MaxScale as is provided as a command line argument:

root@host:~# maxscale --user=maxuser ...

If it is imperative to run MaxScale as root, e.g. in a Docker container, it can be achieved by invoking MaxScale as root and by explicitly specifying the user to also be root:

root@host:~# maxscale --user=root ...

Binlog server

  • 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 (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

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

MySQL Monitor

MySQL 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 MySQL Monitor documentation.

REST API Relationship Endpoints

The servers, monitors and services types now support direct updating of relationships via the relationships endpoints. This conforms to the JSON API specification on updating resource relationships.

For more information, refer to the REST API documentation. An example of this can be found in the Server Resource documentation.

PL/SQL Comaptibility

The parser of MaxScale has been extended to support the PL/SQL compatibility features of the upcoming 10.3 release. For more information on how to enable this mode, please refer to the configuration guide.

This functionality was available already in MaxScale 2.2.0.

Environment Variables in the configuration file

If the global configuration entry substitute_variables is set to true, then if the first character of a value in the configuration file is a $ then everything following that is interpreted as an environment variable and the configuration value is replaced with the value of the environment variable. For more information please consult the Configuration Guide.

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 for details.

Bug fixes

Here is a list of bugs fixed in MaxScale 2.2.1.

  • MXS-1545 Fix GTID connecting slave error detections
  • MXS-1525 Firewall filter does not check exact match for host
  • MXS-1519 Firewall instances can interfere with each other
  • MXS-1517 Retain stale master status even if the master goes down
  • MXS-1499 Add missing fields to SHOW ALL SLAVES STATUS
  • MXS-1486 The cache does not always update the cached entry even if it could
  • MXS-1461 NOT operation needed for firewall rule
  • MXS-1408 maxadmin not working in latest version
  • MXS-1327 set log-priority by maxadmin

Known Issues and Limitations

There are some limitations and known issues within this version of MaxScale. For more information, please refer to the Limitations document.

Packaging

RPM and Debian packages are provided for the Linux distributions supported by MariaDB Enterprise.

Packages can be downloaded here.

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.