All changes 2.0.0...develop
973b983 Merge branch 'release-2.0.0' into develop 255dd23 Make spinlock functions take const argument 6e23bab Fix bitmask reallocation 338c189 Rename and clean up slavelag filter 3ea8f28 Fix possible NULL pointer dereference bfe6738 MXS-830: Add module information to logged messages 1fad962 Fix strncat usage d38997a Adjust log throttling policy 0be4e4b Add hashtable_item_strcasecmp 726100e Take hashtable convenience functions into use 5e7744a Fix typo in maxadmin.md c5778c8 Merge branch 'release-2.0.0' into develop b5762af Move from tmpnam to mkstemp d6f2c71 Add convenience functions to hashtable 359058a MXS-825: Add support for --execdir 636347c Enable runtime reconfiguration of log throttling ef9fba9 Improve log throttling documentation aef917a Implement log throttling e3a5349 Remove shardrouter.c 8051e80 Remove custom qc_sqlite allocation functions fd34d60 Initial implementation of the learning firewall a8752a8 Removed "filestem option" from example 1ef2519 Removed "filestem option" from example 0815cc8 Cleanup spinlock.h ab4dc99 Clean up hashtable.h ef2c078 Add prototypes for hashtable copy and free functions fb5cfaf Add 'log_throttling' configuration entry 300d823 Add proper prototypes for hashtable hash and cmp functions 1c649aa qc_mysqlembedded: Include skygw_...h without path. d276160 Add missing RPM scripts e70e644 Fix HTTPAuth installation 1b2b389 Combine utils into the server directory 3ff9913 Add missing utils headers to devel package 407efb2 Fix minor packaging problems 99aa6ad Split MaxScale into core, experimental and devel packages 1290386 Merge branch 'develop' of ssh://github.com/mariadb-corporation/maxscale-new into develop e59f148 Make scripts POSIX sh compatible 7319266 Fixed SHOW SLAVE STATUS in bonlog router f8d760a Update Binlogrouter.md 0a904ed Update Replication-Proxy-Binlog-Router-Tutorial.md 75d4202 Update Replication-Proxy-Binlog-Router-Tutorial.md b8651fc Add missing newline in listmanager.h c7ad047 Add note about user data caches to release notes 70ccc2b Merge branch 'release-2.0.0' into develop 575d1b6 Mistake - dummy session needs list markers set. 8364508 Merge branch 'develop' into binlog_server_semisync 868b902 Update MaxScale limitations 2c8b327 Store listener caches in separate directories 6e183ec Create unique user data caches for each listeners f643685 Don't free orphaned tee filter sessions 4179afa Allow binlogrouter to be used without a listener 7ad79af Add function for freeing a listener 677a0a2 Move authentication data from services to listeners 4f12af7 Merge remote-tracking branch 'origin/MXS-677' into develop 1419b81 Semi-Sync support to binlog server: code review updtate 0ea0f01 Semi-Sync support to binlog server: added missing routine 4aad909 Semi-Sync support to binlog server b824e1e Add authenticator support to httpd.c 705a688 Change tabs to spaces d0c419e Change method of adding list fields to e.g. DCB 25504fc Document the changed routing priority of hints 41666d1 Remove use_ssl_if_enabled global option a3584e9 Make routing hints have highest priority 34a1d24 Updated document with new binlog router option 01eedc5 Updated documentation with SSL usage 8a4c0f6 Update Replication-Proxy-Binlog-Router-Tutorial.md 4e374aa Update Replication-Proxy-Binlog-Router-Tutorial.md f3f3c57 Update Replication-Proxy-Binlog-Router-Tutorial.md 617b79f Binlog Server: error messages typo fix fa8dfae Binlog Server: error messages review 1b8819c Fix freeing of schemarouter session memory 07f49e1 MXS-788: new code review fix 1fd3b09 MXS-788: show services now displays SSL info 6ca2584 MXS-788 code review fix ae6a7d0 MXS-788 code review 43d3474 Master server SSL connection 90b2377 Use correct variable in listmanager pre-allocation 9a5b238 Fix listmanager pre-allocation 9c78625 Fix a memory leak when backend authentication fails e59a966 Fix hang in list_find_free ff30223 Fix freeing of shared data in schemarouter fc8f9d3 Add missing include in luafilter ecf7f53 Add missing NULL value to filter parameter array 636d849 Update memory allocation approach f0d1d38 Add new allocation functions 97d00a0 Fix writing of uninitialized data to logs e72c9b2 Merge branch 'release-2.0.0' into develop cf2b712 Merge branch 'release-2.0.0' into develop 8917c5c Change the logic behind valid list entry checks c10deff Improve documentation about version_string f59f1f7 Merge branch 'develop' of ssh://github.com/mariadb-corporation/maxscale-new into develop c88edb3 Backend authentication failure improvement abd5bee Revert "Backend authentication failure improvement" 5bb3107 Backend authentication failure improvement b7f434a Add new allocation functions 3f022fa Fix stupid mistake 99c4317 Merge remote-tracking branch 'origin/MXS-677' into develop 3c1ded6 Added connection/authentication failure error reporting in SHOW SLAVE STATUS 0a60f7b Tidy up and deal with review points. ba103ff blr_slave.c: Update strncpy usage 467331e blr_master.c: Strncpy usage updates d2b7c0c Merge remote-tracking branch 'origin/develop-nullauth-merge' into develop 5a8c1d0 qc: Measure execution time at the right place. bccdb93 Merge branch 'NullAuthDeny' into develop 2e6511c Add 5.5.5 prefix to all version strings that lack it 314655a Improve DCB and session initialization and list handling e1c43f0 MXS-655: Make MaxScale logging logrotate(8) compatible ce36afd MXS-626: Don't log a header unless maxlog enabled dcd47a7 blr_file.c: Replace uses of strncpy 6b8f576 bls_slave.c: Replace strncpy with memcpy 68a0039 Add list preallocation, tidy up, simplify init. cb37d1b Fix copyright etc headers. 11a400d Tidy; comment; fix bad copies and mistakes. 7e36ec4 Add list manager files. c4794e3 Initial code for list manager. 1b42e25 Merge remote-tracking branch 'origin/MXS-765' into develop d50f617 Fix problems, extend tests, respond to review. dcb4a91 Filter test folder removed 0b60dbe Add a couple of comments. 83cdba0 Fix overwriting problem. ba5d353 Fix overwriting problem. 53671cb Small fixes in response to review. 173d049 blr.c: Review strncpy usage 4ff6ef2 binlog_common.c: Replace strncpy with memcpy f238e03 maxbinlogcheck.s: Replace strncpy 9807f8d harness: Replace unnecessary use of strncpy 8c7fe6a avro: Modify strncpy usage 9b8008e Small improvements. b7f784f Fix mistakes in testqueuemanager.c cc26962 Restore missing poll.c code; add testqueuemanager.c. 2e91806 Format the filter harness 22059e6 Initial implementation connection queueing. c604dc2 readwritesplit.c: Improve COM_INIT_DB handling 454d920 schemarouter.c: Replace strncpy with strcpy 8e85d66 sharding_common.c: Too long a database name handled explicitly 77f4446 Astyle schemarouter 491f7c2 maxinfo.c: Replace strncpy with memcpy 6b98105 maxinfo: Reformat with astyle c1dbf08 Handle oversize user and database names 5fa4a0f Merge branch 'develop' of ssh://github.com/mariadb-corporation/maxscale-new into develop 706963b BLR_DBUSERS_TAIL new var in blr.h d75b9af Tweak comments, remove trailing blanks. ab2400a Optimise statistics gathering by inline & simpler fns. fb59ddc Remove unnecessary strncpy/strncat usage in Binlog Server bdcd551 resultset.c: Change strncpy to memcpy c6b1c5e Reject rather than cut too long a path 6d8f112 Remove unnecessary strncpy/strncat usage 18bf5ed Remove unnecessary strncpy usage dc0e2db Make maxpasswd more userfriendly c9c8695 Fix calculation of padded_len in encryptPassword 2cfd2c6 dbusers.c: Check strncpy usage 7ab9342 Make more thorough checks in secrets_readKeys be7d593 Format cli.c debugcli.c testroute.c webserver.c 1ee5efb config.c: Check usage of strncpy 3043b12 gq_utils.c: Unnecessary use of strncpy removed 77874ac Add help to maxkeys 38392a3 Update secrets_writeKeys documentation 2d1325c Make SSL optional in MaxScale's own communication bda00da Fix avro build failures b2cb31a Add more OOM macros 41ccf17 Fix strdup usage a48f732 Fix realloc calls 20771f6 Add forgotten extern "C" block 8faf35a Add maxscale allocation functions bb47890 Add macros for OOM logging afea388 Fix silly mistakes. 6dafd22 Make deny default for null auth; move code from common to auth.
This commit is contained in:
Johan Wikman
@ -12,20 +12,6 @@ limitations to the components which illustrate them.
|
||||
This section describes the limitations that are common to all
|
||||
configuration of plugins with MariaDB MaxScale.
|
||||
|
||||
### Crash if one of several listeners for a Service fails as startup
|
||||
|
||||
If a service has multiple listeners and one of those listeners fails
|
||||
at startup, MariaDB MaxScale will crash.
|
||||
|
||||
A typical reason for a listener to fail is that it has been configured
|
||||
with a non-existing socket path or a port that MariaDB MaxScale is not allowed
|
||||
to use.
|
||||
|
||||
Workaround: Ensure that socket paths and ports are valid.
|
||||
|
||||
Issues [MXS-710](https://jira.mariadb.org/browse/MXS-710) and
|
||||
[MXS-711](https://jira.mariadb.org/browse/MXS-711) relate to this.
|
||||
|
||||
## Limitations with MySQL Protocol support
|
||||
|
||||
Compression is not included in MySQL server handshake
|
||||
|
||||
@ -84,6 +84,7 @@ Here are detailed documents about the filters MariaDB MaxScale offers. They cont
|
||||
- [Database Firewall Filter](Filters/Database-Firewall-Filter.md)
|
||||
- [RabbitMQ Filter](Filters/RabbitMQ-Filter.md)
|
||||
- [Named Server Filter](Filters/Named-Server-Filter.md)
|
||||
- [Gatekeeper - Adaptive Firewall](Filters/Gatekeeper.md)
|
||||
|
||||
## Monitors
|
||||
|
||||
|
||||
70
Documentation/Filters/CCRFilter.md
Normal file
70
Documentation/Filters/CCRFilter.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Consistent Critical Read Filter
|
||||
|
||||
## Overview
|
||||
|
||||
The Consistent Critical Read (CCR) filter allows consistent critical reads to be
|
||||
done through MaxScale while still allowing scaleout of non-critical reads.
|
||||
|
||||
When the filter detects a statement that would modify the database, it attaches a
|
||||
routing hint to all following statements. This routing hint guides the routing
|
||||
module to route the statement to the master server where data is guaranteed to be
|
||||
in a up-to-date state.
|
||||
|
||||
## Filter Options
|
||||
|
||||
The CCR filter accepts the following options.
|
||||
|
||||
|Option |Description |
|
||||
|-----------|--------------------------------------------|
|
||||
|ignorecase |Use case-insensitive matching (default) |
|
||||
|case |Use case-sensitive matching |
|
||||
|extended |Use extended regular expression syntax (ERE)|
|
||||
|
||||
To use multiple filter options, list them in a comma-separated list.
|
||||
|
||||
```
|
||||
options=case,extended
|
||||
```
|
||||
|
||||
## Filter Parameters
|
||||
|
||||
The CCR filter has no mandatory parameters.
|
||||
|
||||
### `time`
|
||||
|
||||
The time window in seconds during which queries are routed to the master. The
|
||||
default value for this parameter is 60 seconds.
|
||||
|
||||
When a data modifying SQL statement is processed, a timer is set to the value of
|
||||
_time_. Once the timer has elapsed, all statements are routed normally. If a new
|
||||
data modifying SQL statement is processed within the time window, the timer is
|
||||
reset to the value of _time_.
|
||||
|
||||
Enabling this parameter in combination with the _count_ parameter causes both the
|
||||
time window and number of queries to be inspected. If either of the two
|
||||
conditions are met, the query is re-routed to the master.
|
||||
|
||||
### `count`
|
||||
|
||||
The number of SQL statements to route to master after detecting a data modifying
|
||||
SQL statement. This feature is disabled by default.
|
||||
|
||||
After processing a data modifying SQL statement, a counter is set to the value of
|
||||
_count_ and all statements are routed to the master. Each executed statement
|
||||
after a data modifying SQL statement cause the counter to be decremented. Once
|
||||
the counter reaches zero, the statements are routed normally. If a new data
|
||||
modifying SQL statement is processed, the counter is reset to the value of
|
||||
_count_.
|
||||
|
||||
### `match`
|
||||
|
||||
An optional parameter that can be used to control which statements trigger the
|
||||
statement re-routing. The parameter value is a regular expression that is used to
|
||||
match against the SQL text. Only non-SELECT statements are inspected.
|
||||
|
||||
### `ignore`
|
||||
|
||||
An optional parameter that can be used to control which statements don't trigger
|
||||
the statement re-routing. This does the opposite of the _match_ parameter. The
|
||||
parameter value is a regular expression that is used to match against the SQL
|
||||
text. Only non-SELECT statements are inspected.
|
||||
53
Documentation/Filters/Gatekeeper.md
Normal file
53
Documentation/Filters/Gatekeeper.md
Normal file
@ -0,0 +1,53 @@
|
||||
# Gatekeeper Filter
|
||||
|
||||
# Overview
|
||||
|
||||
This filter will learn from input data read during a learning phase. After
|
||||
learning the characteristics of the input, the filter can then be set into
|
||||
the enforcing mode. In this mode the filter will block any queries that do
|
||||
not conform to the training set. This is a simple yet effective way to prevent
|
||||
unwanted queries from being executed in the database.
|
||||
|
||||
When the filter receives a query in the learning mode, the filter converts it
|
||||
into a canonicalized form i.e. creates a query digest. The query digest is then
|
||||
stored for later use.
|
||||
|
||||
When the filter is started in enforcing mode, the list of stored query digests
|
||||
is used as a master list of allowed queries. The filter calculates a query
|
||||
digest for all incoming queries and compares it to the master list. If the
|
||||
query digest is in the master list, the query is executed normally. If it
|
||||
isn't found from the list, the query is not executed, an error is returned
|
||||
to the client and a warning message is logged.
|
||||
|
||||
# Configuration
|
||||
|
||||
## Filter Parameters
|
||||
|
||||
### `mode`
|
||||
|
||||
This is a mandatory parameter for the filter which controls the filter's operation.
|
||||
|
||||
Accepted values are _learn_ and _enforce_. _learn_ sets the filter into the
|
||||
learning mode, where the query digests are calculated and stored at the end of
|
||||
each session. _enforce_ sets the filter into the enforcement mode where incoming
|
||||
queries are compared to the previously calculated list of query digests.
|
||||
|
||||
### `datadir`
|
||||
|
||||
This is an optional parameter which controls where the calculated query digests
|
||||
are stored. This parameter takes an absolute path to a directory as its argument.
|
||||
|
||||
## Example Configuration
|
||||
|
||||
Here is an example configuration of the filter with both the mandatory _mode_
|
||||
and the optional _datadir_ parameters defined. The filter is in learning mode
|
||||
and after collecting enough samples, the filter is should be set into enforcing
|
||||
mode. The filter stores the gathered query digests in `/var/lib/maxscale/gatekeeper/`.
|
||||
|
||||
```
|
||||
[Smart Firewall]
|
||||
type=filter
|
||||
module=gatekeeper
|
||||
mode=learn
|
||||
datadir=/var/lib/maxscale/gatekeeper/
|
||||
```
|
||||
@ -141,14 +141,13 @@ which allows us to build packages. The `-DCMAKE_INSTALL_PREFIX` was removed sinc
|
||||
we aren't installing MariaDB MaxScale, only packaging it.
|
||||
|
||||
```
|
||||
cmake ../MaxScale -DPACKAGE=Y -DBUILD_TESTS=Y
|
||||
cmake ../MaxScale -DPACKAGE=Y
|
||||
```
|
||||
|
||||
Next step is to test and build the package.
|
||||
Next step is to build the package.
|
||||
|
||||
```
|
||||
make
|
||||
make test
|
||||
make package
|
||||
```
|
||||
|
||||
@ -163,3 +162,35 @@ the LD_LIBRARY_PATH environment variable.
|
||||
make
|
||||
LD_LIBRARY_PATH=$PWD/server/core/ make package
|
||||
```
|
||||
|
||||
## Installing and packaging optional components
|
||||
|
||||
MaxScale is split into multiple components. The main component is the core MaxScale
|
||||
package which contains MaxScale and all the modules. This is the default component
|
||||
that is build, installed and packaged. There exist two other components, the _experimental_
|
||||
and the _devel_ components. The former contains all experimental modules which are
|
||||
not considered as part of the core MaxScale package and they can be alpha or beta
|
||||
quality modules. The latter of the optional components, _devel_, contains the
|
||||
development files required for MaxScale module development.
|
||||
|
||||
The component which is build is controlled by the TARGET_COMPONENT CMake variable.
|
||||
The default value for this is _core_ which build the core MaxScale package.
|
||||
|
||||
To build the experimental modules, you will need to set value of the TARGET_COMPONENT
|
||||
CMake variable to the component name you wish to install or package.
|
||||
|
||||
For example, to package the experimental module component, invoke CMake with
|
||||
_-DTARGET_COMPONENT=experimental_:
|
||||
|
||||
```
|
||||
cmake ../MaxScale -DPACKAGE=Y DTARGET_COMPONENT=experimental
|
||||
make package
|
||||
```
|
||||
|
||||
If you wish to create a monolithic package with all the components, set the value to an
|
||||
empty string and build the package:
|
||||
|
||||
```
|
||||
cmake ../MaxScale -DPACKAGE=Y DTARGET_COMPONENT=""
|
||||
make package
|
||||
```
|
||||
|
||||
@ -242,6 +242,41 @@ log_augmentation=1
|
||||
|
||||
To disable the augmentation use the value 0 and to enable it use the value 1.
|
||||
|
||||
#### `log_throttling`
|
||||
|
||||
In some circumstances it is possible that a particular error (or warning) is logged
|
||||
over and over again, if the cause for the error persistently remains. To prevent the log
|
||||
from flooding, it is possible to specify how many times a particular error may be logged
|
||||
within a time period, before the logging of that error is suppressed for a while.
|
||||
|
||||
```
|
||||
# A valid value looks like
|
||||
# log_throttling = X, Y, Z
|
||||
#
|
||||
# where each value is a positive integer and X means the number of times a specific
|
||||
# error may be logged within a time period of Y milliseconds, before the logging of
|
||||
# that error is suppressed for Z milliseconds.
|
||||
log_throttling=8, 2000, 15000
|
||||
```
|
||||
|
||||
In the example above, the logging of a particular error will be suppressed for 15 seconds
|
||||
if the error has been logged 8 times in 2 seconds.
|
||||
|
||||
The default is `10, 1000, 10000`, which means that if the same error is logged 10
|
||||
times in one second, the logging of that error is suppressed for the following
|
||||
10 seconds.
|
||||
|
||||
To disable log throttling, add an entry with an empty value
|
||||
```
|
||||
log_throttling=
|
||||
```
|
||||
or one where any of the integers is 0.
|
||||
```
|
||||
log_throttling=0, 0, 0
|
||||
```
|
||||
|
||||
Note that *notice*, *info* and *debug* messages are never throttled.
|
||||
|
||||
#### `logdir`
|
||||
|
||||
Set the directory where the logfiles are stored. The folder needs to be both readable and writable by the user running MariaDB MaxScale.
|
||||
@ -475,7 +510,8 @@ This parameter enables matching of "127.0.0.1" (localhost) against "%" wildcard
|
||||
|
||||
#### `version_string`
|
||||
|
||||
This parameter sets a custom version string that is sent in the MySQL Handshake from MariaDB MaxScale to clients.
|
||||
This parameter sets a custom version string that is sent in the MySQL Handshake
|
||||
from MariaDB MaxScale to clients.
|
||||
|
||||
Example:
|
||||
|
||||
@ -483,7 +519,11 @@ Example:
|
||||
version_string=5.5.37-MariaDB-RWsplit
|
||||
```
|
||||
|
||||
If not set, the default value is the server version of the embedded MySQL/MariaDB library. Example: 5.5.35-MariaDB
|
||||
If not set, the default value is `5.5.5-10.0.0 MaxScale <MaxScale version>`
|
||||
where `<MaxScale version>` is the version of MaxScale. If the provided string
|
||||
does not start with the number 5, a 5.5.5- prefix will be added to it. This
|
||||
means that a _version_string_ value of _MaxScale-Service_ would result in a
|
||||
_5.5.5-MaxScale-Service_ being sent to the client.
|
||||
|
||||
#### `weightby`
|
||||
|
||||
|
||||
@ -807,7 +807,14 @@ MariaDB MaxScale can log messages to syslog, to a log file or to both. The appro
|
||||
|
||||
## Rotating the log file
|
||||
|
||||
MariaDB MaxScale logs messages to a log file in the log directory of MariaDB MaxScale. As the log file grows continuously, it is recommended to periodically rotate it. When rotated, the current log file will be closed and a new one with a new name opened. The log file name contain a sequence number, which is incremented each time the log is rotated.
|
||||
MariaDB MaxScale logs messages to a log file in the log directory of MariaDB MaxScale. As the log file grows continuously, it is recommended to periodically rotate it. When rotated, the current log file will be closed and a new one with the *same* name opened.
|
||||
|
||||
To retain the ealier log entries, you need to first rename the log file and then instruct MaxScale to rotate it.
|
||||
|
||||
$ 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
|
||||
|
||||
There are two ways for rotating the log - *flush log maxscale* and *flush logs* - and the result is identical. The two alternatives are due to historical reasons; earlier MariaDB MaxScale had several different log files.
|
||||
|
||||
@ -827,6 +834,23 @@ From version 1.3 onwards, MariaDB MaxScale has a single log file where messages
|
||||
|
||||
Please note that changes made via this interface will not persist across restarts of MariaDB MaxScale. To make a permanent change edit the maxscale.cnf file.
|
||||
|
||||
## Adjusting the Log Throttling
|
||||
|
||||
From 2.0 onwards, MariaDB MaxScale will throttle messages that are logged too frequently, which typically is a sign that MaxScale encounters some error that just keeps on repeating. The aim is to prevent the log from flooding. The configuration specifies how many times a particular error may be logged during a period of a specified length, before it is suppressed for a period of a specified other length.
|
||||
|
||||
The current log throttling configuration can be queried with
|
||||
|
||||
MaxScale> show log_throttling
|
||||
10 1000 100000
|
||||
|
||||
where the numbers are the count, the length (in milliseconds) of the period during which the counting is made, and the length (in milliseconds) of the period the message is subsequently suppressed.
|
||||
|
||||
The configuration can be set with
|
||||
|
||||
MaxScale> set log_throttling 10 1000 10000
|
||||
|
||||
where numbers are specified in the same order as in the *show* case. Setting any of the values to 0, disables the throttling.
|
||||
|
||||
## Reloading The Configuration
|
||||
|
||||
A command, _reload config_, is available that will cause MariaDB MaxScale to reload the maxscale.cnf configuration file.
|
||||
|
||||
85
Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md
Normal file
85
Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md
Normal file
@ -0,0 +1,85 @@
|
||||
# MariaDB MaxScale 2.1.0 Release Notes
|
||||
|
||||
Release 2.1.0 is a Beta release.
|
||||
|
||||
This document describes the changes in release 2.1.0, when compared to
|
||||
release 2.0.X.
|
||||
|
||||
For any problems you encounter, please consider submitting a bug
|
||||
report at [Jira](https://jira.mariadb.org).
|
||||
|
||||
## Changes Features
|
||||
|
||||
### 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 instructued (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).
|
||||
|
||||
### User data cache
|
||||
|
||||
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.
|
||||
|
||||
## New Features
|
||||
|
||||
|
||||
## Bug fixes
|
||||
|
||||
[Here is a list of bugs fixed since the release of MaxScale 2.0.X.](https://jira.mariadb.org/browse/MXS-739?jql=project%20%3D%20MXS%20AND%20issuetype%20%3D%20Bug%20AND%20resolution%20in%20(Fixed%2C%20Done)%20AND%20fixVersion%20%3D%202.0.0)
|
||||
|
||||
|
||||
## 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-bsl).
|
||||
@ -91,6 +91,21 @@ The default value is off, set transaction_safety=on to enable the incomplete tra
|
||||
|
||||
This defines whether (on | off) MariaDB MaxScale sends to the slave the heartbeat packet when there are no real binlog events to send. The default value if 'off', no heartbeat event is sent to slave server. If value is 'on' the interval value (requested by the slave during registration) is reported in the diagnostic output and the packet is send after the time interval without any event to send.
|
||||
|
||||
### `semisync`
|
||||
|
||||
This parameter controls whether binlog server could ask Master server to start the Semi-Synchronous replication.
|
||||
In order to get semi-sync working the Master server must have the *rpl_semi_sync_master* plugin installed.
|
||||
The available plugin and the value of GLOBAL VARIABLE *rpl_semi_sync_master_enabled* are checked in the Master registration phase: if plugin is installed in the Master database the binlog server then requests the semi-sync option.
|
||||
Note:
|
||||
- the network replication stream from Master has two additional bytes before each binlog event.
|
||||
- the Semi-Sync protocol requires an acknoledge packet to be sent back to Master only when requested: the semi-sync flag will have value of 1.
|
||||
This flag is set only if *rpl_semi_sync_master_enabled=1* in the Master, otherwise it will always have value of 0 and no ack packet is sent back.
|
||||
|
||||
Please note that semi-sync replication is only related to binlog server to Master communication.
|
||||
### `ssl_cert_verification_depth`
|
||||
|
||||
This parameter sets the maximum length of the certificate authority chain that will be accepted. Legal values are positive integers. This applies to SSL connection to master server that could be acivated either by writing options in master.ini or later via CHANGE MASTER TO. This parameter cannot be modified at runtime, default is 9.
|
||||
|
||||
A complete example of a service entry for a binlog router service would be as follows.
|
||||
```
|
||||
[Replication]
|
||||
@ -100,7 +115,7 @@ A complete example of a service entry for a binlog router service would be as fo
|
||||
version_string=5.6.17-log
|
||||
user=maxscale
|
||||
passwd=Mhu87p2D
|
||||
router_options=uuid=f12fcb7f-b97b-11e3-bc5e-0401152c4c22,server-id=3,user=repl,password=slavepass,master-id=1,heartbeat=30,binlogdir=/var/binlogs,transaction_safety=1,master_version=5.6.19-common,master_hostname=common_server,master_uuid=xxx-fff-cccc-common,master-id=999,mariadb10-compatibility=1,send_slave_heartbeat=1
|
||||
router_options=uuid=f12fcb7f-b97b-11e3-bc5e-0401152c4c22,server-id=3,user=repl,password=slavepass,master-id=1,heartbeat=30,binlogdir=/var/binlogs,transaction_safety=1,master_version=5.6.19-common,master_hostname=common_server,master_uuid=xxx-fff-cccc-common,master-id=999,mariadb10-compatibility=1,send_slave_heartbeat=1,ssl_cert_verification_depth=9,semisync=1
|
||||
```
|
||||
|
||||
The minimum set of router options that must be given in the configuration are are server-id and master-id, default values may be used for all other options.
|
||||
@ -108,3 +123,6 @@ The minimum set of router options that must be given in the configuration are ar
|
||||
## Examples
|
||||
|
||||
The [Replication Proxy](../Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md) tutorial will show you how to configure and administrate a binlogrouter installation.
|
||||
|
||||
|
||||
Tutorial also includes SSL communication setup to the master server and SSL client connections setup to MaxScale Binlog Server
|
||||
|
||||
@ -4,7 +4,7 @@ This document provides a short overview of the **readwritesplit** router module
|
||||
|
||||
## Overview
|
||||
|
||||
The **readwritesplit** router is designed to increase the read-only processing capability of a cluster while maintaining consistency. This is achieved by splitting the query load into read and write queries. Read queries, which do not modify data, are spread across multiple nodes while all write queries will be sent to a single node.
|
||||
The **readwritesplit** router is designed to increase the read-only processing capability of a cluster while maintaining consistency. This is achieved by splitting the query load into read and write queries. Read queries, which do not modify data, are spread across multiple nodes while all write queries will be sent to a single node.
|
||||
|
||||
The router is designed to be used with a traditional Master-Slave replication cluster. It automatically detects changes in the master server and will use the current master server of the cluster. With a Galera cluster, one can achieve a resilient setup and easy master failover by using one of the Galera nodes as a Write-Master node, where all write queries are routed, and spreading the read load over all the nodes.
|
||||
|
||||
@ -150,7 +150,14 @@ reconnecting to MariaDB MaxScale once a new master is available.
|
||||
|
||||
## Routing hints
|
||||
|
||||
The readwritesplit router supports routing hints. For a detailed guide on hint syntax and functionality, please read [this](../Reference/Hint-Syntax.md) document.
|
||||
The readwritesplit router supports routing hints. For a detailed guide on hint
|
||||
syntax and functionality, please read [this](../Reference/Hint-Syntax.md) document.
|
||||
|
||||
**Note**: Routing hints will always have the highest priority when a routing
|
||||
decision is made. This means that it is possible to cause inconsistencies in
|
||||
the session state and the actual data in the database by adding routing hints
|
||||
to DDL/DML statements which are then directed to slave servers. Only use routing
|
||||
hints when you are sure that they can cause no harm.
|
||||
|
||||
## Limitations
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
# MariaDB MaxScale as a Binlog Server
|
||||
MariaDB MaxScale is a database proxy that sits between a database layer and the clients of that database, the binlog router described here is somewhat different to that original concept, moving MariaDB MaxScale down to play a role within the database layer itself.
|
||||
MariaDB MaxScale is a dynamic data routing platform that sits between a database layer and the clients of that database, the binlog router described here is somewhat different to that original concept, moving MariaDB MaxScale down to play a role within the database layer itself.
|
||||
|
||||
In a traditional MySQL replication setup a single master server is created and a set of slaves MySQL instances are configured to pull the binlog files from that master to the slaves. There are some problems, however, in this setup; when the number of slaves grows an increasing load is placed on the master, to serve the binlogs to each slave. When the master server fails, some action must be performed on every slave server before a new server can become the master server.
|
||||
|
||||
@ -127,6 +127,25 @@ When MariaDB MaxScale starts an error message may appear if current binlog file
|
||||
During normal operations binlog events are not distributed to the slaves until a *COMMIT* is seen.
|
||||
The default value is off, set *transaction_safety=on* to enable the incomplete transactions detection.
|
||||
|
||||
### semisync
|
||||
|
||||
This parameter controls whether binlog server could ask Master server to start the Semi-Synchronous replication.
|
||||
In order to get semi-sync working the Master server must have the *rpl_semi_sync_master* plugin installed.
|
||||
The available plugin and the value of GLOBAL VARIABLE *rpl_semi_sync_master_enabled* are checked in the Master registration phase: if plugin is installed in the Master database the binlog server then requests the semi-sync option.
|
||||
Note:
|
||||
- the network replication stream from Master has two additional bytes before each binlog event.
|
||||
- the Semi-Sync protocol requires an acknoledge packet to be sent back to Master only when requested: the semi-sync flag will have value of 1.
|
||||
This flag is set only if *rpl_semi_sync_master_enabled=1* in the Master, otherwise it will always have value of 0 and no ack packet is sent back.
|
||||
|
||||
Please note that semi-sync replication is only related to binlog server to Master communication.
|
||||
|
||||
|
||||
### ssl_cert_verification_depth
|
||||
|
||||
This parameter sets the maximum length of the certificate authority chain that will be accepted. Legal values are positive integers.
|
||||
This applies to SSL connection to master server that could be acivated either by writing options in master.ini or later via CHANGE MASTER TO.
|
||||
This parameter cannot be modified at runtime, default is 9.
|
||||
|
||||
A complete example of a service entry for a binlog router service would be as follows.
|
||||
|
||||
```
|
||||
@ -137,7 +156,7 @@ A complete example of a service entry for a binlog router service would be as fo
|
||||
version_string=5.6.17-log
|
||||
user=maxscale
|
||||
passwd=Mhu87p2D
|
||||
router_options=uuid=f12fcb7f-b97b-11e3-bc5e-0401152c4c22,server-id=3,user=repl,password=slavepass,master-id=1,heartbeat=30,binlogdir=/var/binlogs,transaction_safety=1,master_version=5.6.19-common,master_hostname=common_server,master_uuid=xxx-fff-cccc-common,master-id=999,mariadb10-compatibility=1
|
||||
router_options=uuid=f12fcb7f-b97b-11e3-bc5e-0401152c4c22,server-id=3,user=repl,password=slavepass,master-id=1,heartbeat=30,binlogdir=/var/binlogs,transaction_safety=1,master_version=5.6.19-common,master_hostname=common_server,master_uuid=xxx-fff-cccc-common,master-id=999,mariadb10-compatibility=1,ssl_cert_verification_depth=9,semisync=1
|
||||
```
|
||||
|
||||
The minimum set of router options that must be given in the configuration are are *server-id* and *master-id*, default values may be used for all other options.
|
||||
@ -154,6 +173,21 @@ As per any service in MariaDB MaxScale a listener section is required to define
|
||||
|
||||
The protocol used by slaves for connection to MariaDB MaxScale is the same *MySQLClient* protocol that is used for client applications to connect to databases, therefore the same MariaDB MaxScale protocol module can be used.
|
||||
|
||||
It's also possible to enable SSL from clients (MySQL clients or Slave servers) by adding SSL options in the listener, or in a new one:
|
||||
```
|
||||
[Replication Listener_SSL]
|
||||
type=listener
|
||||
service=Replication
|
||||
protocol=MySQLClient
|
||||
port=5309
|
||||
ssl=required
|
||||
ssl_key=/path_to/key.pem
|
||||
ssl_cert=/path_to/cert.pem
|
||||
ssl_ca_cert=/path_to/ca-cert.pem
|
||||
#ssl_version=TLSv10
|
||||
```
|
||||
Check the [Configuration-Guide](../Getting-Started/Configuration-Guide.md) for SSL options details.
|
||||
|
||||
# MariaDB MaxScale replication diagnostics
|
||||
|
||||
The binlog router module of MariaDB MaxScale produces diagnostic output that can be viewed via the `maxadmin` client application. Running the maxadmin command and issuing a show service command will produce a considerable amount of output that will show both the master connection status and statistics and also a block for each of the slaves currently connected.
|
||||
@ -232,7 +266,67 @@ The binlog router module of MariaDB MaxScale produces diagnostic output that can
|
||||
Users data: 0x156c030
|
||||
Total connections: 2
|
||||
Currently connected: 2
|
||||
-bash-4.1$
|
||||
```
|
||||
If a slave is connected to MaxScale with SSL, an entry will be present in the Slave report:
|
||||
```
|
||||
Slaves:
|
||||
Server-id: 106
|
||||
Hostname: SBslave6
|
||||
Slave UUID: 00019686-7777-7777-7777-777777777777
|
||||
Slave_host_port: 188.165.213.5:40365
|
||||
Username: massi
|
||||
Slave DCB: 0x7fc01be3ba88
|
||||
Slave connected with SSL: Established
|
||||
|
||||
```
|
||||
|
||||
Another Binlog Server diagnostic output comes from SHOW SLAVE STATUS MySQL command
|
||||
|
||||
```
|
||||
MySQL [(none)]> show slave status\G
|
||||
*************************** 1. row ***************************
|
||||
Slave_IO_State: Binlog Dump
|
||||
Master_Host: 88.26.197.94
|
||||
Master_User: repl
|
||||
Master_Port: 3306
|
||||
Connect_Retry: 60
|
||||
Master_Log_File: mysql-bin.003140
|
||||
Read_Master_Log_Pos: 16682679
|
||||
Relay_Log_File: mysql-bin.003140
|
||||
Relay_Log_Pos: 16682679
|
||||
Relay_Master_Log_File: mysql-bin.003140
|
||||
Slave_IO_Running: Yes
|
||||
Slave_SQL_Running: Yes
|
||||
Replicate_Do_DB:
|
||||
Replicate_Ignore_DB:
|
||||
Replicate_Do_Table:
|
||||
Replicate_Ignore_Table:
|
||||
Replicate_Wild_Do_Table:
|
||||
Replicate_Wild_Ignore_Table:
|
||||
Last_Errno: 0
|
||||
Last_Error:
|
||||
Skip_Counter: 0
|
||||
Exec_Master_Log_Pos: 16682679
|
||||
Relay_Log_Space: 16682679
|
||||
Until_Condition: None
|
||||
Until_Log_File:
|
||||
Until_Log_Pos: 0
|
||||
Master_SSL_Allowed: Yes
|
||||
Master_SSL_CA_File: /home/maxscale/packages/certificates/client/ca.pem
|
||||
Master_SSL_CA_Path:
|
||||
Master_SSL_Cert: /home/maxscale/packages/certificates/client/client-cert.pem
|
||||
Master_SSL_Cipher:
|
||||
Master_SSL_Key: /home/maxscale/packages/certificates/client/client-key.pem
|
||||
Seconds_Behind_Master: 0
|
||||
Master_SSL_Verify_Server_Cert: No
|
||||
Last_IO_Errno: 0
|
||||
Last_IO_Error:
|
||||
Last_SQL_Errno: 0
|
||||
Last_SQL_Error:
|
||||
Replicate_Ignore_Server_Ids:
|
||||
Master_Server_Id: 1111
|
||||
Master_UUID: 6aae714e-b975-11e3-bc33-0401152c3d01
|
||||
Master_Info_File: /home/maxscale/binlog/first/binlogs/master.ini
|
||||
```
|
||||
|
||||
# Binlog router compatibility
|
||||
@ -261,6 +355,12 @@ Please note that is such condition the only user for MySQL protocol connection t
|
||||
master_user=repl
|
||||
master_password=somepass
|
||||
filestem=repl-bin
|
||||
# Master SSL communication options
|
||||
master_ssl=0
|
||||
master_ssl_key=/home/mpinto/packages/certificates/client/client-key.pem
|
||||
master_ssl_cert=/home/mpinto/packages/certificates/client/client-cert.pem
|
||||
master_ssl_ca=/home/mpinto/packages/certificates/client/ca.pem
|
||||
#master_tls_version=TLSv12
|
||||
|
||||
Enabling replication from a master server requires:
|
||||
|
||||
@ -306,6 +406,15 @@ The supported options are:
|
||||
MASTER_LOG_FILE
|
||||
MASTER_LOG_POS
|
||||
|
||||
and SSL options as well:
|
||||
MASTER_SSL (0|1)
|
||||
MASTER_SSL_CERT (path to certificate file)
|
||||
MASTER_SSL_KEY (path to key file)
|
||||
MASTER_SSL_CA (path to CA cerificate file)
|
||||
MASTER_TLS_VERSION (allowed level of encryption used)
|
||||
|
||||
Further details about level of encryption or certificates could be found here [Configuration Guuide](../Getting-Started/Configuration-Guide.md)
|
||||
|
||||
There are some constraints related to *MASTER_LOG_FILE* and *MASTER_LOG_POS*:
|
||||
|
||||
*MASTER_LOG_FILE* could be changed to next binlog in sequence with *MASTER_LOG_POS=4* or to current one at current position.
|
||||
@ -348,6 +457,53 @@ This command removes *master.ini* file, blanks all master configuration in memor
|
||||
|
||||
Note: existing binlog files are not touched by this command.
|
||||
|
||||
Examples with SSL options:
|
||||
|
||||
MySQL [(none)]> CHANGE MASTER TO MASTER_SSL = 1, MASTER_SSL_CERT='/home/maxscale/packages/certificates/client/client-cert.pem', MASTER_SSL_CA='/home/maxscale/packages/certificates/client/ca.pem', MASTER_SSL_KEY='/home/maxscale/packages/certificates/client/client-key.pem', MASTER_TLS_VERSION='TLSv12';
|
||||
|
||||
MySQL [(none)]> CHANGE MASTER TO MASTER_TLS_VERSION='TLSv12';
|
||||
|
||||
MySQL [(none)]> CHANGE MASTER TO MASTER_SSL = 0;
|
||||
|
||||
|
||||
#### Some constraints:
|
||||
- In order to enable/re-enable Master SSL comunication the MASTER_SSL=1 option is required and all certificate options must be explicitey set in the same CHANGE MASTER TO command.
|
||||
- New certificate options changes take effect after maxScale restart or after MASTER_SSL=1 with the new options.
|
||||
|
||||
Note:
|
||||
- SHOW SLAVE STATUS displays all the options but MASTER_TLS_VERSION value.
|
||||
- Maxadmin, 'show services' or 'show service $binlog_service' displays all the options when SSL is on.
|
||||
- STOP SLAVE is required for CHANGE MASTER TO command (any option)
|
||||
- START SLAVE will use new SSL options for Master SSL communication setup.
|
||||
|
||||
Examples:
|
||||
mysql client
|
||||
|
||||
MySQL> SHOW SLAVE STATUS\G
|
||||
|
||||
Master_SSL_Allowed: Yes
|
||||
Master_SSL_CA_File: /home/mpinto/packages/certificates/client/ca.pem
|
||||
Master_SSL_CA_Path:
|
||||
Master_SSL_Cert: /home/mpinto/packages/certificates/client/client-cert.pem
|
||||
Master_SSL_Cipher:
|
||||
Master_SSL_Key: /home/mpinto/packages/certificates/client/client-key.pem
|
||||
|
||||
maxadmin client
|
||||
|
||||
MaxScale>'show service BinlogServer'
|
||||
|
||||
Service: BinlogServer
|
||||
Router: binlogrouter (0x7fd8c3002b40)
|
||||
State: Started
|
||||
Master connection DCB: 0x7fd8c8fce228
|
||||
Master SSL is ON:
|
||||
Master SSL CA cert: /home/mpinto/packages/certificates/client/ca.pem
|
||||
Master SSL Cert: /home/mpinto/packages/certificates/client/client-cert.pem
|
||||
Master SSL Key: /home/mpinto/packages/certificates/client/client-key.pem
|
||||
Master SSL tls_ver: TLSv12
|
||||
|
||||
|
||||
|
||||
### Slave servers setup
|
||||
|
||||
Examples of *CHANGE MASTER TO* command issued on a slave server that wants to gets replication events from MariaDB MaxScale binlog router:
|
||||
|
||||
@ -1,28 +1,27 @@
|
||||
#!/bin/bash
|
||||
#
|
||||
# Copyright (c) 2016 MariaDB Corporation Ab
|
||||
#
|
||||
# Use of this software is governed by the Business Source License included
|
||||
# in the LICENSE.TXT file and at www.mariadb.com/bsl.
|
||||
#
|
||||
# Change Date: 2019-01-01
|
||||
# Change Date: 2019-07-01
|
||||
#
|
||||
# On the date above, in accordance with the Business Source License, use
|
||||
# of this software will be governed by version 2 or later of the General
|
||||
# Public License.
|
||||
#
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
# Check that all links to Markdown format files point to existing local files
|
||||
|
||||
homedir=$(pwd)
|
||||
|
||||
for file in $(find . -name '*.md')
|
||||
find . -name '*.md'|while read file
|
||||
do
|
||||
cd "$(dirname $file)"
|
||||
for i in `grep -o '\[.*\]([^#].*[.]md)' $(basename $file)| sed -e 's/\[.*\](\(.*\))/\1/'`
|
||||
cd "$(dirname "$file")"
|
||||
grep -o '\[.*\]([^#].*[.]md)' "$(basename "$file")"| sed -e 's/\[.*\](\(.*\))/\1/'|while read i
|
||||
do
|
||||
if [ ! -f $i ]
|
||||
if [ ! -f "$i" ]
|
||||
then
|
||||
echo "Link $i in $file is not correct!"
|
||||
fi
|
||||
|
||||
Reference in New Issue
Block a user