Additional documentation cleanup for 2.1
Mostly just reflow text (=linebreaks) for better diffs. Some small changes. Remove Debug-And-Diagnostic-Support.md.
This commit is contained in:
Esa Korhonen
parent
2cc3382a46
commit
f1efe72f66
@ -7,10 +7,10 @@ This filter was introduced in MariaDB MaxScale 2.1.
|
||||
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 an up-to-date state.
|
||||
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 an up-to-date state.
|
||||
|
||||
## Filter Options
|
||||
|
||||
@ -42,8 +42,8 @@ _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
|
||||
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`
|
||||
@ -51,8 +51,8 @@ conditions are met, the query is re-routed to the master.
|
||||
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 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
|
||||
@ -61,8 +61,8 @@ _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.
|
||||
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.
|
||||
|
||||
```
|
||||
match=.*INSERT.*
|
||||
|
||||
@ -2,13 +2,25 @@
|
||||
|
||||
## Overview
|
||||
|
||||
This filter is designed to extract queries and transform them into a canonical form e.g. `INSERT INTO database.table VALUES ("John Doe", "Downtown",100,50.0);` turns into `INSERT INTO database.table VALUES ("?", "?",?,?);`. The filter pushes these canonized queries and their replies into a RabbitMQ broker where they can later be retrieved from. The retrieval can be done with a custom application or the [RabbitMQ Consumer Client](RabbitMQ-Consumer-Client.md) utility tool, which reads the messages from the broker and sends the contents of those messages as SQL queries to a database.
|
||||
This filter is designed to extract queries and transform them into a canonical
|
||||
form e.g. `INSERT INTO database.table VALUES ("John Doe", "Downtown",100,50.0);`
|
||||
turns into `INSERT INTO database.table VALUES ("?", "?",?,?);`. The filter
|
||||
pushes these canonized queries and their replies into a RabbitMQ broker where
|
||||
they can later be retrieved from. The retrieval can be done with a custom
|
||||
application or the [RabbitMQ Consumer Client](RabbitMQ-Consumer-Client.md)
|
||||
utility tool, which reads the messages from the broker and sends the contents of
|
||||
those messages as SQL queries to a database.
|
||||
|
||||
## Configuration
|
||||
|
||||
The configuration block for the **mqfilter** filter requires the minimal filter options in it’s section within the maxscale.cnf file, stored in /etc/maxscale.cnf. Although the filter will start, it will use the default values which only work with a freshly installed RabbitMQ server and use its default values. This setup is mostly intended for testing the filter.
|
||||
The configuration block for the **mqfilter** requires the minimal filter options
|
||||
in its section within the MaxScale configuration file. Although the filter will
|
||||
start, it will use the default values which only work with a freshly installed
|
||||
RabbitMQ server and use its default values. This setup is mostly intended for
|
||||
testing the filter.
|
||||
|
||||
The following is an example of a mqfilter configuration in the maxscale.cnf file used for actual logging of queries to a RabbitMQ broker on a different host.
|
||||
The following is an example of an mqfilter configuration used for actual logging
|
||||
of queries to a RabbitMQ broker on a different host.
|
||||
|
||||
```
|
||||
[RabbitMQ]
|
||||
@ -42,7 +54,10 @@ The mqfilter filter does not support any filter options.
|
||||
|
||||
### Filter Parameters
|
||||
|
||||
The RabbitMQ filter has parameters to control which queries are logged based on either the attributes of the user or the query itself. These can be combined to to only log queries targeting a certain table in a certain database from a certain user from a certain network address.
|
||||
The RabbitMQ filter has parameters to control which queries are logged based on
|
||||
either the attributes of the user or the query itself. These can be combined to
|
||||
to only log queries targeting a certain table in a certain database from a
|
||||
certain user from a certain network address.
|
||||
|
||||
|
||||
Option | Description | Accepted Values | Default |
|
||||
|
||||
@ -2,11 +2,16 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The tee filter is a "plumbing" fitting in the MariaDB MaxScale filter toolkit. It can be used in a filter pipeline of a service to make copies of requests from the client and send the copies to another service within MariaDB MaxScale.
|
||||
The tee filter is a "plumbing" fitting in the MariaDB MaxScale filter toolkit.
|
||||
It can be used in a filter pipeline of a service to make copies of requests from
|
||||
the client and send the copies to another service within MariaDB MaxScale.
|
||||
|
||||
## Configuration
|
||||
|
||||
The configuration block for the TEE filter requires the minimal filter parameters in it’s section within the maxscale.cnf file, stored in /etc/maxscale.cnf, that defines the filter to load and the service to send the duplicates to. Currently the tee filter does not support multi-statements.
|
||||
The configuration block for the TEE filter requires the minimal filter
|
||||
parameters in its section within the MaxScale configuration file. The service to
|
||||
send the duplicates to must be defined. Currently the tee filter does not
|
||||
support multi-statements.
|
||||
|
||||
```
|
||||
[DataMartFilter]
|
||||
@ -41,31 +46,45 @@ options=case,extended
|
||||
|
||||
## Filter Parameters
|
||||
|
||||
The tee filter requires a mandatory parameter to define the service to replicate statements to and accepts a number of optional parameters.
|
||||
The tee filter requires a mandatory parameter to define the service to replicate
|
||||
statements to and accepts a number of optional parameters.
|
||||
|
||||
### Match
|
||||
|
||||
An optional parameter used to limit the queries that will be replicated by the tee filter. The parameter value is a regular expression that is used to match against the SQL text. Only SQL statements that matches the text passed as the value of this parameter will be sent to the service defined in the filter section.
|
||||
An optional parameter used to limit the queries that will be replicated by the
|
||||
tee filter. The parameter value is a regular expression that is used to match
|
||||
against the SQL text. Only SQL statements that matches the text passed as the
|
||||
value of this parameter will be sent to the service defined in the filter
|
||||
section.
|
||||
|
||||
```
|
||||
match=insert.*into.*order*
|
||||
```
|
||||
|
||||
All regular expressions are evaluated with the option to ignore the case of the text, therefore a match option of select will match both insert, INSERT and any form of the word with upper or lowercase characters.
|
||||
All regular expressions are evaluated with the option to ignore the case of the
|
||||
text, therefore a match option of select will match both insert, INSERT and any
|
||||
form of the word with upper or lowercase characters.
|
||||
|
||||
### Exclude
|
||||
|
||||
An optional parameter used to limit the queries that will be replicated by the tee filter. The parameter value is a regular expression that is used to match against the SQL text. SQL statements that match the text passed as the value of this parameter will be excluded from the replication stream.
|
||||
An optional parameter used to limit the queries that will be replicated by the
|
||||
tee filter. The parameter value is a regular expression that is used to match
|
||||
against the SQL text. SQL statements that match the text passed as the value of
|
||||
this parameter will be excluded from the replication stream.
|
||||
|
||||
```
|
||||
exclude=select
|
||||
```
|
||||
|
||||
All regular expressions are evaluated with the option to ignore the case of the text, therefore an exclude option of select will exclude statements that contain both select, SELECT or any form of the word with upper or lowercase characters.
|
||||
All regular expressions are evaluated with the option to ignore the case of the
|
||||
text, therefore an exclude option of select will exclude statements that contain
|
||||
both select, SELECT or any form of the word with upper or lowercase characters.
|
||||
|
||||
### Source
|
||||
|
||||
The optional source parameter defines an address that is used to match against the address from which the client connection to MariaDB MaxScale originates. Only sessions that originate from this address will be replicated.
|
||||
The optional source parameter defines an address that is used to match against
|
||||
the address from which the client connection to MariaDB MaxScale originates.
|
||||
Only sessions that originate from this address will be replicated.
|
||||
|
||||
```
|
||||
source=127.0.0.1
|
||||
@ -73,7 +92,9 @@ source=127.0.0.1
|
||||
|
||||
### User
|
||||
|
||||
The optional user parameter defines a user name that is used to match against the user from which the client connection to MariaDB MaxScale originates. Only sessions that are connected using this username are replicated.
|
||||
The optional user parameter defines a user name that is used to match against
|
||||
the user from which the client connection to MariaDB MaxScale originates. Only
|
||||
sessions that are connected using this username are replicated.
|
||||
|
||||
```
|
||||
user=john
|
||||
@ -83,9 +104,17 @@ user=john
|
||||
|
||||
### Example 1 - Replicate all inserts into the orders table
|
||||
|
||||
Assume an order processing system that has a table called orders. You also have another database server, the datamart server, that requires all inserts into orders to be replicated to it. Deletes and updates are not, however, required.
|
||||
Assume an order processing system that has a table called orders. You also have
|
||||
another database server, the datamart server, that requires all inserts into
|
||||
orders to be replicated to it. Deletes and updates are not, however, required.
|
||||
|
||||
Set up a service in MariaDB MaxScale, called Orders, to communicate with the order processing system with the tee filter applied to it. Also set up a service to talk to the datamart server, using the DataMart service. The tee filter would have as it’s service entry the DataMart service, by adding a match parameter of "insert into orders" would then result in all requests being sent to the order processing system, and insert statements that include the orders table being additionally sent to the datamart server.
|
||||
Set up a service in MariaDB MaxScale, called Orders, to communicate with the
|
||||
order processing system with the tee filter applied to it. Also set up a service
|
||||
to talk to the datamart server, using the DataMart service. The tee filter would
|
||||
have as it’s service entry the DataMart service, by adding a match parameter of
|
||||
"insert into orders" would then result in all requests being sent to the order
|
||||
processing system, and insert statements that include the orders table being
|
||||
additionally sent to the datamart server.
|
||||
|
||||
```
|
||||
[Orders]
|
||||
|
||||
@ -2,11 +2,10 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
This document describes how to configure MariaDB MaxScale
|
||||
and presents some possible usage scenarios. MariaDB
|
||||
MaxScale is designed with flexibility in mind, and consists of an event
|
||||
processing core with various support functions and plugin modules that tailor
|
||||
the behavior of the program.
|
||||
This document describes how to configure MariaDB MaxScale and presents some
|
||||
possible usage scenarios. MariaDB MaxScale is designed with flexibility in mind,
|
||||
and consists of an event processing core with various support functions and
|
||||
plugin modules that tailor the behavior of the program.
|
||||
|
||||
# Table of Contents
|
||||
|
||||
@ -48,7 +47,7 @@ The MariaDB MaxScale configuration is read from a file that MariaDB MaxScale
|
||||
will look for in the following places:
|
||||
|
||||
1. By default, the file `maxscale.cnf` in the directory `/etc`
|
||||
1. The location given with the `--configdir=<path>` command line argument.
|
||||
2. The location given with the `--configdir=<path>` command line argument.
|
||||
|
||||
MariaDB MaxScale will further look for a directory with the same name as the
|
||||
configuration file, followed by `.d` (for instance `/etc/maxscale.cnf.d`) and
|
||||
@ -62,10 +61,10 @@ separate configuration files for _servers_, _filters_, etc.
|
||||
|
||||
The configuration file itself is based on the
|
||||
[.ini](https://en.wikipedia.org/wiki/INI_file) file format and consists of
|
||||
various sections that are used to build the configuration; these sections
|
||||
define services, servers, listeners, monitors and global settings. Parameters,
|
||||
which expect a comma-separated list of values can be defined on multiple
|
||||
lines. The following is an example of a multi-line definition.
|
||||
various sections that are used to build the configuration; these sections define
|
||||
services, servers, listeners, monitors and global settings. Parameters, which
|
||||
expect a comma-separated list of values can be defined on multiple lines. The
|
||||
following is an example of a multi-line definition.
|
||||
|
||||
```
|
||||
[MyService]
|
||||
@ -76,18 +75,18 @@ servers=server1,
|
||||
server3
|
||||
```
|
||||
|
||||
The values of the parameter that are not on the first line need to have at
|
||||
least one whitespace character before them in order for them to be recognized
|
||||
as a part of the multi-line parameter.
|
||||
The values of the parameter that are not on the first line need to have at least
|
||||
one whitespace character before them in order for them to be recognized as a
|
||||
part of the multi-line parameter.
|
||||
|
||||
### Sizes
|
||||
|
||||
Where _specifically noted_, a number denoting a size can be suffixed by a subset of
|
||||
the IEC binary prefixes or the SI prefixes. In the former case the number will be
|
||||
interpreted as a certain multiple of 1024 and in the latter case as a certain multiple
|
||||
of 1000. The supported IEC binary suffixes are `Ki`, `Mi`, `Gi` and `Ti` and the
|
||||
supported SI suffixes are `k`, `M`, `G` and `T`. In both cases, the matching is
|
||||
case insensitive.
|
||||
Where _specifically noted_, a number denoting a size can be suffixed by a subset
|
||||
of the IEC binary prefixes or the SI prefixes. In the former case the number
|
||||
will be interpreted as a certain multiple of 1024 and in the latter case as a
|
||||
certain multiple of 1000. The supported IEC binary suffixes are `Ki`, `Mi`, `Gi`
|
||||
and `Ti` and the supported SI suffixes are `k`, `M`, `G` and `T`. In both cases,
|
||||
the matching is case insensitive.
|
||||
|
||||
For instance, the following entries
|
||||
```
|
||||
@ -133,9 +132,9 @@ used for systems dedicated for running MariaDB MaxScale.
|
||||
threads=1
|
||||
```
|
||||
|
||||
Additional threads will be created to execute other
|
||||
internal services within MariaDB MaxScale. This setting is used to configure the
|
||||
number of threads that will be used to manage the user connections.
|
||||
Additional threads will be created to execute other internal services within
|
||||
MariaDB MaxScale. This setting is used to configure the number of threads that
|
||||
will be used to manage the user connections.
|
||||
|
||||
#### `auth_connect_timeout`
|
||||
|
||||
@ -212,8 +211,7 @@ By default logging to *syslog* is enabled.
|
||||
syslog=1
|
||||
```
|
||||
|
||||
To enable logging to syslog use the value 1 and to disable use
|
||||
the value 0.
|
||||
To enable logging to syslog use the value 1 and to disable use the value 0.
|
||||
|
||||
#### `maxlog`
|
||||
|
||||
@ -232,15 +230,15 @@ disable use the value 0.
|
||||
|
||||
#### `log_to_shm`
|
||||
|
||||
Enable or disable the writing of the *maxscale.log* file to shared memory.
|
||||
If enabled, then the actual log file will be created under `/dev/shm` and
|
||||
a symbolic link to that file will be created in the *MaxScale* log directory.
|
||||
Enable or disable the writing of the *maxscale.log* file to shared memory. If
|
||||
enabled, then the actual log file will be created under `/dev/shm` and a
|
||||
symbolic link to that file will be created in the *MaxScale* log directory.
|
||||
|
||||
Logging to shared memory may be appropriate if *log_info* and/or *log_debug*
|
||||
are enabled, as logging to a regular file may in that case cause performance
|
||||
degradation, due to the amount of data logged. However, as shared memory is
|
||||
a scarce resource, logging to shared memory should be used only temporarily
|
||||
and not regularly.
|
||||
Logging to shared memory may be appropriate if *log_info* and/or *log_debug* are
|
||||
enabled, as logging to a regular file may in that case cause performance
|
||||
degradation, due to the amount of data logged. However, as shared memory is a
|
||||
scarce resource, logging to shared memory should be used only temporarily and
|
||||
not regularly.
|
||||
|
||||
Since *MariaDB MaxScale* can log to both file and *syslog* an approach that
|
||||
provides maximum flexibility is to enable *syslog* and *log_to_shm*, and to
|
||||
@ -257,8 +255,8 @@ By default, logging to shared memory is disabled.
|
||||
log_to_shm=1
|
||||
```
|
||||
|
||||
To enable logging to shared memory use the value 1 and to disable use
|
||||
the value 0.
|
||||
To enable logging to shared memory use the value 1 and to disable use the value
|
||||
0.
|
||||
|
||||
#### `log_warning`
|
||||
|
||||
@ -276,8 +274,8 @@ To disable these messages use the value 0 and to enable them use the value 1.
|
||||
#### `log_notice`
|
||||
|
||||
Enable or disable the logging of messages whose syslog priority is *notice*.
|
||||
Messages of this priority provide information about the functioning of
|
||||
MariaDB MaxScale and are enabled by default.
|
||||
Messages of this priority provide information about the functioning of MariaDB
|
||||
MaxScale and are enabled by default.
|
||||
|
||||
```
|
||||
# Valid options are:
|
||||
@ -289,12 +287,12 @@ To disable these messages use the value 0 and to enable them use the value 1.
|
||||
|
||||
#### `log_info`
|
||||
|
||||
Enable or disable the logging of messages whose syslog priority is *info*.
|
||||
These messages provide detailed information about the internal workings of
|
||||
MariaDB MaxScale and should not, due to their frequency, be enabled, unless there
|
||||
is a specific reason for that. For instance, from these messages it will be
|
||||
evident, e.g., why a particular query was routed to the master instead of
|
||||
to a slave. These informational messages are disabled by default.
|
||||
Enable or disable the logging of messages whose syslog priority is *info*. These
|
||||
messages provide detailed information about the internal workings of MariaDB
|
||||
MaxScale and should not, due to their frequency, be enabled, unless there is a
|
||||
specific reason for that. For instance, from these messages it will be evident,
|
||||
e.g., why a particular query was routed to the master instead of to a slave.
|
||||
These informational messages are disabled by default.
|
||||
|
||||
```
|
||||
# Valid options are:
|
||||
@ -306,9 +304,9 @@ To disable these messages use the value 0 and to enable them use the value 1.
|
||||
|
||||
#### `log_debug`
|
||||
|
||||
Enable or disable the logging of messages whose syslog priority is *debug*.
|
||||
This kind of messages are intended for development purposes and are disabled
|
||||
by default. Note that if MariaDB MaxScale has been built in release mode, then
|
||||
Enable or disable the logging of messages whose syslog priority is *debug*. This
|
||||
kind of messages are intended for development purposes and are disabled by
|
||||
default. Note that if MariaDB MaxScale has been built in release mode, then
|
||||
debug messages are excluded from the build and this setting will not have any
|
||||
effect.
|
||||
|
||||
@ -345,11 +343,11 @@ To disable the augmentation use the value 0 and to enable it use the value 1.
|
||||
|
||||
#### `log_throttling`
|
||||
|
||||
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.
|
||||
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
|
||||
@ -392,9 +390,9 @@ logdir=/tmp/
|
||||
|
||||
#### `datadir`
|
||||
|
||||
Set the directory where the data files used by MariaDB MaxScale are
|
||||
stored. Modules can write to this directory and for example the binlogrouter
|
||||
uses this folder as the default location for storing binary logs.
|
||||
Set the directory where the data files used by MariaDB MaxScale are stored.
|
||||
Modules can write to this directory and for example the binlogrouter uses this
|
||||
folder as the default location for storing binary logs.
|
||||
|
||||
```
|
||||
datadir=/home/user/maxscale_data/
|
||||
@ -414,9 +412,9 @@ libdir=/home/user/lib64/
|
||||
#### `cachedir`
|
||||
|
||||
Configure the directory MariaDB MaxScale uses to store cached data. An example
|
||||
of cached data is the authentication data fetched from the backend
|
||||
servers. MariaDB MaxScale stores this in case a connection to the backend server
|
||||
is not possible.
|
||||
of cached data is the authentication data fetched from the backend servers.
|
||||
MariaDB MaxScale stores this in case a connection to the backend server is not
|
||||
possible.
|
||||
|
||||
```
|
||||
cachedir=/tmp/maxscale_cache/
|
||||
@ -493,21 +491,23 @@ language=/home/user/lang/
|
||||
|
||||
The module used by MariaDB MaxScale for query classification. The information
|
||||
provided by this module is used by MariaDB MaxScale when deciding where a
|
||||
particular statement should be sent. The default query classifier
|
||||
is _qc_sqlite_.
|
||||
particular statement should be sent. The default query classifier is
|
||||
_qc_sqlite_.
|
||||
|
||||
#### `query_classifier_args`
|
||||
|
||||
Arguments for the query classifier. What arguments are accepted depends
|
||||
on the particular query classifier being used. The default query
|
||||
classifier - _qc_sqlite_ - supports the following arguments:
|
||||
Arguments for the query classifier. What arguments are accepted depends on the
|
||||
particular query classifier being used. The default query classifier -
|
||||
_qc_sqlite_ - supports the following arguments:
|
||||
|
||||
##### `log_unrecognized_statements`
|
||||
|
||||
An integer argument taking the following values:
|
||||
* 0: Nothing is logged. This is the default.
|
||||
* 1: Statements that cannot be parsed completely are logged. They may have been partially parsed, or classified based on keyword matching.
|
||||
* 2: Statements that cannot even be partially parsed are logged. They may have been classified based on keyword matching.
|
||||
* 1: Statements that cannot be parsed completely are logged. They may have been
|
||||
partially parsed, or classified based on keyword matching.
|
||||
* 2: Statements that cannot even be partially parsed are logged. They may have
|
||||
been classified based on keyword matching.
|
||||
* 3: Statements that cannot even be classified by keyword matching are logged.
|
||||
|
||||
```
|
||||
@ -515,8 +515,8 @@ query_classifier=qc_sqlite
|
||||
query_classifier_args=log_unrecognized_statements=1
|
||||
```
|
||||
|
||||
This will log all statements that cannot be parsed completely. This
|
||||
may be useful if you suspect that MariaDB MaxScale routes statements to the wrong
|
||||
This will log all statements that cannot be parsed completely. This may be
|
||||
useful if you suspect that MariaDB MaxScale routes statements to the wrong
|
||||
server (e.g. to a slave instead of to a master).
|
||||
|
||||
### Service
|
||||
@ -529,12 +529,12 @@ statements or route connections to those backend servers.
|
||||
A service may be considered as a virtual database server that MariaDB MaxScale
|
||||
makes available to its clients.
|
||||
|
||||
Several different services may be defined using the same set of backend
|
||||
servers. For example a connection based routing service might be used by clients
|
||||
that already performed internal read/write splitting, whilst a different
|
||||
statement based router may be used by clients that are not written with this
|
||||
functionality in place. Both sets of applications could access the same data in
|
||||
the same databases.
|
||||
Several different services may be defined using the same set of backend servers.
|
||||
For example a connection based routing service might be used by clients that
|
||||
already performed internal read/write splitting, whilst a different statement
|
||||
based router may be used by clients that are not written with this functionality
|
||||
in place. Both sets of applications could access the same data in the same
|
||||
databases.
|
||||
|
||||
A service is identified by a service name, which is the name of the
|
||||
configuration file section and a type parameter of service.
|
||||
@ -580,9 +580,9 @@ router is included with the documentation of the router itself.
|
||||
|
||||
#### `router_options`
|
||||
|
||||
Option string given to the router module. The value of this parameter
|
||||
should be a comma-separated list of key-value pairs. See router specific
|
||||
documentation for more details.
|
||||
Option string given to the router module. The value of this parameter should be
|
||||
a comma-separated list of key-value pairs. See router specific documentation for
|
||||
more details.
|
||||
|
||||
#### `filters`
|
||||
|
||||
@ -756,9 +756,10 @@ control the load balancing applied in the router in use by the service. This
|
||||
allows varying weights to be applied to each server to create a non-uniform
|
||||
distribution of the load amongst the servers.
|
||||
|
||||
An example of this might be to define a parameter for each server that represents
|
||||
the amount of resource available on the server, we could call this serversize.
|
||||
Every server should then have a serversize parameter set for the server.
|
||||
An example of this might be to define a parameter for each server that
|
||||
represents the amount of resource available on the server, we could call this
|
||||
serversize. Every server should then have a serversize parameter set for the
|
||||
server.
|
||||
|
||||
```
|
||||
serversize=10
|
||||
@ -766,8 +767,8 @@ serversize=10
|
||||
|
||||
The service would then have the parameter `weightby=serversize`. If there are 4
|
||||
servers defined in the service (serverA, serverB, serverC and serverD) with the
|
||||
serversize set as shown in the table below, the connections would balanced
|
||||
using the percentages in this table.
|
||||
serversize set as shown in the table below, the connections would balanced using
|
||||
the percentages in this table.
|
||||
|
||||
Server |serversize|% connections
|
||||
---------|----------|-------------
|
||||
@ -780,8 +781,8 @@ _**Note**: If the value of the weighting parameter of an individual server is
|
||||
zero or the relative weight rounds down to zero, no queries will be routed to
|
||||
that server as long as a server with a positive weight is available._
|
||||
|
||||
Here is an excerpt from an example configuration with the `serv_weight` parameter
|
||||
used as the weighting parameter.
|
||||
Here is an excerpt from an example configuration with the `serv_weight`
|
||||
parameter used as the weighting parameter.
|
||||
|
||||
```
|
||||
[server1]
|
||||
@ -806,19 +807,19 @@ weightby=serv_weight
|
||||
```
|
||||
|
||||
With this configuration and a heavy query load, the server _server1_ will get
|
||||
most of the connections and about a third of the remaining queries are routed
|
||||
to the second server. With server weights, you can assign secondary servers
|
||||
that are only used when the primary server is under heavy load.
|
||||
most of the connections and about a third of the remaining queries are routed to
|
||||
the second server. With server weights, you can assign secondary servers that
|
||||
are only used when the primary server is under heavy load.
|
||||
|
||||
Without the weightby parameter, each connection counts as a single connection.
|
||||
With a weighting parameter, a single connection received its weight from
|
||||
the server's own weighting parameter divided by the sum of all weighting
|
||||
parameters in all the configured servers.
|
||||
With a weighting parameter, a single connection received its weight from the
|
||||
server's own weighting parameter divided by the sum of all weighting parameters
|
||||
in all the configured servers.
|
||||
|
||||
If we use the previous configuration as an example, the sum of the `serv_weight`
|
||||
parameter is 4. _Server1_ would receive a weight of `3/4=75%` and _server2_ would get
|
||||
`1/4=25%`. This means that _server1_ would get 75% of the connections and _server2_
|
||||
would get 25% of the connections.
|
||||
parameter is 4. _Server1_ would receive a weight of `3/4=75%` and _server2_
|
||||
would get `1/4=25%`. This means that _server1_ would get 75% of the connections
|
||||
and _server2_ would get 25% of the connections.
|
||||
|
||||
#### `auth_all_servers`
|
||||
|
||||
@ -832,9 +833,9 @@ servers.
|
||||
The strip_db_esc parameter strips escape characters from database names of
|
||||
grants when loading the users from the backend server.
|
||||
|
||||
This parameter takes a boolean value and when enabled, will strip all backslash
|
||||
(`\`) characters from the database names. The default value for this parameter
|
||||
is true since MaxScale 2.0.1. In previous version, the default value was false.
|
||||
This parameter takes a boolean value and when enabled, will strip all backslash (`\`)
|
||||
characters from the database names. The default value for this parameter is true
|
||||
since MaxScale 2.0.1. In previous version, the default value was false.
|
||||
|
||||
Some visual database management tools automatically escape some characters and
|
||||
this might cause conflicts when MariaDB MaxScale tries to authenticate users.
|
||||
@ -978,10 +979,9 @@ able to accept SSL connections.
|
||||
#### `ssl`
|
||||
|
||||
This enables SSL connections to the server, when set to `required`. If that is
|
||||
done, the three certificate files mentioned below must also be
|
||||
supplied. MaxScale connections to this server will then be encrypted with
|
||||
SSL. If this is not possible, client connection attempts that rely on the server
|
||||
will fail.
|
||||
done, the three certificate files mentioned below must also be supplied.
|
||||
MaxScale connections to this server will then be encrypted with SSL. If this is
|
||||
not possible, client connection attempts that rely on the server will fail.
|
||||
|
||||
#### `ssl_key`
|
||||
|
||||
@ -1020,10 +1020,10 @@ should be used.
|
||||
|
||||
#### `ssl_cert_verification_depth`
|
||||
|
||||
The maximum length of the certificate authority chain that will be
|
||||
accepted. Legal values are positive integers. Note that if the client is to
|
||||
submit an SSL certificate, the `ssl_cert_verification_depth` parameter must not
|
||||
be 0. If no value is specified, the default is 9.
|
||||
The maximum length of the certificate authority chain that will be accepted.
|
||||
Legal values are positive integers. Note that if the client is to submit an SSL
|
||||
certificate, the `ssl_cert_verification_depth` parameter must not be 0. If no
|
||||
value is specified, the default is 9.
|
||||
|
||||
```
|
||||
# Example
|
||||
@ -1068,9 +1068,9 @@ The network socket where the listener listens will have a backlog of
|
||||
connections. The size of this backlog is controlled by the
|
||||
net.ipv4.tcp_max_syn_backlog and net.core.somaxconn kernel parameters.
|
||||
|
||||
Increasing the size of the backlog by modifying the kernel parameters
|
||||
helps with sudden connection spikes and rejected connections. For more
|
||||
information see [listen(2)](http://man7.org/linux/man-pages/man2/listen.2.html).
|
||||
Increasing the size of the backlog by modifying the kernel parameters helps with
|
||||
sudden connection spikes and rejected connections. For more information see
|
||||
[listen(2)](http://man7.org/linux/man-pages/man2/listen.2.html).
|
||||
|
||||
```
|
||||
[<Listener name>]
|
||||
@ -1117,14 +1117,14 @@ on both the specific IP address and the Unix socket.
|
||||
#### `authenticator`
|
||||
|
||||
The authenticator module to use. Each protocol module defines a default
|
||||
authentication module which is used if no `authenticator` parameter is
|
||||
found from the configuration.
|
||||
authentication module which is used if no `authenticator` parameter is found
|
||||
from the configuration.
|
||||
|
||||
#### `authenticator_options`
|
||||
|
||||
Option string given to the authenticator module. The value of this
|
||||
parameter should be a comma-separated list of key-value pairs. See
|
||||
authenticator specific documentation for more details.
|
||||
Option string given to the authenticator module. The value of this parameter
|
||||
should be a comma-separated list of key-value pairs. See authenticator specific
|
||||
documentation for more details.
|
||||
|
||||
#### Available Protocols
|
||||
|
||||
@ -1173,9 +1173,9 @@ SSL/TLS encryption method and the various certificate files involved in it. To
|
||||
enable SSL from client to MaxScale, you must configure the `ssl` parameter to
|
||||
the value `required` and provide the three files for `ssl_cert`, `ssl_key` and
|
||||
`ssl_ca_cert`. After this, MySQL connections to this listener will be encrypted
|
||||
with SSL. Attempts to connect to the listener with a non-SSL client will
|
||||
fail. Note that the same service can have an SSL listener and a non-SSL listener
|
||||
if you wish, although they must be on different ports.
|
||||
with SSL. Attempts to connect to the listener with a non-SSL client will fail.
|
||||
Note that the same service can have an SSL listener and a non-SSL listener if
|
||||
you wish, although they must be on different ports.
|
||||
|
||||
#### `ssl`
|
||||
|
||||
@ -1223,10 +1223,10 @@ TLS 1.2 is also available. MAX will use the best available version.
|
||||
|
||||
#### `ssl_cert_verification_depth`
|
||||
|
||||
The maximum length of the certificate authority chain that will be
|
||||
accepted. Legal values are positive integers. Note that if the client is to
|
||||
submit an SSL certificate, the `ssl_cert_verification_depth` parameter must not
|
||||
be 0. If no value is specified, the default is 9.
|
||||
The maximum length of the certificate authority chain that will be accepted.
|
||||
Legal values are positive integers. Note that if the client is to submit an SSL
|
||||
certificate, the `ssl_cert_verification_depth` parameter must not be 0. If no
|
||||
value is specified, the default is 9.
|
||||
|
||||
```
|
||||
# Example
|
||||
@ -1256,7 +1256,6 @@ also specifies that TLSv1.2 should be used as the encryption method. The paths
|
||||
to the server certificate files and the Certificate Authority file are also
|
||||
provided.
|
||||
|
||||
|
||||
## Routing Modules
|
||||
|
||||
The main task of MariaDB MaxScale is to accept database connections from client
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,8 +1,13 @@
|
||||
# Maxbinlogcheck, the MySQL/MariaDB binlog check utility
|
||||
# Maxbinlogcheck, the MySQL/MariaDB binlog check utility
|
||||
|
||||
# Overview
|
||||
|
||||
Maxbinlogcheck is a command line utility for checking binlogfiles. The files may have been downloaded by the MariaDB MaxScale binlog router or they may be MySQL/MariaDB binlog files stored in a database server acting as a master in a replication environment. Maxbinlogcheck checks the binlog files against any corruption and stored incomplete transactions and reports a transaction summary after reading all the events. It may optionally truncate the binlog file.
|
||||
Maxbinlogcheck is a command line utility for checking binlogfiles. The files may
|
||||
have been downloaded by the MariaDB MaxScale binlog router or they may be
|
||||
MySQL/MariaDB binlog files stored in a database server acting as a master in a
|
||||
replication environment. Maxbinlogcheck checks the binlog files against any
|
||||
corruption and stored incomplete transactions and reports a transaction summary
|
||||
after reading all the events. It may optionally truncate the binlog file.
|
||||
|
||||
Maxbinlogcheck supports:
|
||||
|
||||
@ -26,9 +31,8 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<td>Description</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-f</td>
|
||||
<td>--fix</td>
|
||||
<td>If set the binlog file will be truncated at last safe transaction pos in case of any error</td>
|
||||
<td>-f</td> <td>--fix</td> <td>If set the binlog file will be truncated at
|
||||
last safe transaction pos in case of any error</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-M</td>
|
||||
@ -38,7 +42,8 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<tr>
|
||||
<td>-d</td>
|
||||
<td>--debug</td>
|
||||
<td>Sets the debug mode. If set the FD Events, Rotate events and opening/closing transactions are displayed.</td>
|
||||
<td>Sets the debug mode. If set the FD Events, Rotate events and
|
||||
opening/closing transactions are displayed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-?</td>
|
||||
@ -58,7 +63,8 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<tr>
|
||||
<td>-A</td>
|
||||
<td>--aes_algo</td>
|
||||
<td>AES Algorithm for MariaDB 10.1 binlog file decryption (default=AES_CBC, AES_CTR)</td>
|
||||
<td>AES Algorithm for MariaDB 10.1 binlog file decryption (default=AES_CBC,
|
||||
AES_CTR)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-H</td>
|
||||
@ -167,7 +173,7 @@ The maxbinlogcheck command accepts a number of switches
|
||||
This file is corrupted, as reported by the utility:
|
||||
|
||||
```
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002
|
||||
2015-09-08 10:03:16 maxbinlogcheck 1.0.0
|
||||
2015-09-08 10:03:16 Checking /servers/binlogs/new-trx/bin.000002 (bin.000002), size 109498 bytes
|
||||
2015-09-08 10:03:16 Event size error: size 0 at 290.
|
||||
@ -197,7 +203,7 @@ Use -f option for fix with debug:
|
||||
Check it again, last pos will be 245 and no errors will be reported:
|
||||
|
||||
```
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002 -d
|
||||
[root@maxscale-02 build]# /usr/local/bin/maxbinlogcheck /servers/binlogs/new-trx/bin.000002 -d
|
||||
2015-09-08 09:56:56 maxbinlogcheck 1.0.0
|
||||
2015-09-08 09:56:56 Checking /servers/binlogs/new-trx/bin.000002 (bin.000002), size 245 bytes
|
||||
2015-09-08 09:56:56 - Format Description event FDE @ 4, size 241
|
||||
@ -275,7 +281,8 @@ And finally big transaction is now done.
|
||||
|
||||
**Note**
|
||||
|
||||
With current maxbinlogcheck it's not possible to fix a binlog with incomplete transaction and no other errors
|
||||
With current maxbinlogcheck it's not possible to fix a binlog with incomplete
|
||||
transaction and no other errors
|
||||
|
||||
If that is really desired it will be possible with UNIX command line:
|
||||
|
||||
@ -356,8 +363,8 @@ Check result:
|
||||
Key File content example: /var/binlogs/key_file.txt
|
||||
|
||||
First two bytes are: the encryption scheme, it must be 1, and the ';' separator.
|
||||
Following bytes are the HEX representation of the key (length must be 16, 24 or 32).
|
||||
The example shows a 32 bytes key in HEX format (64 bytes):
|
||||
Following bytes are the HEX representation of the key (length must be 16, 24 or
|
||||
32). The example shows a 32 bytes key in HEX format (64 bytes):
|
||||
|
||||
```
|
||||
1;666f6f62617220676f657320746f207468652062617220666f7220636f66666565
|
||||
|
||||
@ -1,14 +1,13 @@
|
||||
# Module commands
|
||||
|
||||
Introduced in MaxScale 2.1, the module commands are special, module-specific
|
||||
commands. They allow the modules to expand beyond the capabilities of the
|
||||
module API. Currently, only MaxAdmin implements an interface to the module
|
||||
commands.
|
||||
commands. They allow the modules to expand beyond 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.
|
||||
_<module>_ is the name of the module and _<name>_ is the name of the command.
|
||||
_ARGS_ is a command specific list of arguments.
|
||||
|
||||
## Developer reference
|
||||
|
||||
@ -16,7 +15,8 @@ The module command API is defined in the _modulecmd.h_ header. It consists of
|
||||
various functions to register and call module commands. Read the function
|
||||
documentation in the header for more details.
|
||||
|
||||
The following example registers the module command _my_command_ for module _my_module_.
|
||||
The following example registers the module command _my_command_ for module
|
||||
_my_module_.
|
||||
|
||||
```
|
||||
#include <maxscale/modulecmd.h>
|
||||
@ -53,8 +53,9 @@ int main(int argc, char **argv)
|
||||
}
|
||||
```
|
||||
|
||||
The array _my_args_ of type _modulecmd_arg_type_t_ is used to tell what kinds of arguments
|
||||
the command expects. The first argument is a boolean and the second argument is an optional string.
|
||||
The array _my_args_ of type _modulecmd_arg_type_t_ is used to tell what kinds of
|
||||
arguments the command expects. The first argument is a boolean and the second
|
||||
argument is an optional string.
|
||||
|
||||
Arguments are passed to the parsing function as an array of void pointers. They
|
||||
are interpreted as the types the command expects.
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
# CLI
|
||||
|
||||
The command line interface as used by `maxadmin`. The _CLI_ router requires the use
|
||||
of the `maxscaled` protocol.
|
||||
The command line interface as used by `maxadmin`. The _CLI_ router requires the
|
||||
use of the `maxscaled` protocol.
|
||||
|
||||
## Configuration
|
||||
|
||||
Two components are required to run the command line interface for
|
||||
_maxadmin_; a service and a listener. The listener may either use a Unix domain socket
|
||||
or an internet socket.
|
||||
Two components are required to run the command line interface for _maxadmin_; a
|
||||
service and a listener. The listener may either use a Unix domain socket or an
|
||||
internet socket.
|
||||
|
||||
The default entries required are shown below.
|
||||
|
||||
@ -33,18 +33,18 @@ port=6603
|
||||
```
|
||||
|
||||
In the example above, two listeners have been specified; one that listens on the
|
||||
default Unix domain socket and one that listens on the default port. In the latter
|
||||
case, if the `address=` entry is removed, connections are allowed from any machine
|
||||
on your network.
|
||||
default Unix domain socket and one that listens on the default port. In the
|
||||
latter case, if the `address=` entry is removed, connections are allowed from
|
||||
any machine on your network.
|
||||
|
||||
In the former case, if the value of `socket` is changed and in the latter case,
|
||||
if the value of `port` is changed, _maxadmin_ must be invoked with the `-S` and
|
||||
`-P` options, respectively.
|
||||
|
||||
If Unix domain sockets are used, the connection is secure, but _maxadmin_
|
||||
can only be used on the same host where MariaDB MaxScale runs. If internet sockets
|
||||
are used, the connection is _inherently insecure_ but _maxadmin_ can be used from
|
||||
another host than the one where MariaDB MaxScale runs.
|
||||
If Unix domain sockets are used, the connection is secure, but _maxadmin_ can
|
||||
only be used on the same host where MariaDB MaxScale runs. If internet sockets
|
||||
are used, the connection is _inherently insecure_ but _maxadmin_ can be used
|
||||
from another host than the one where MariaDB MaxScale runs.
|
||||
|
||||
Note that the latter approach is **deprecated** and will be removed in a future
|
||||
version of MariaDB MaxScale.
|
||||
|
||||
@ -1,52 +1,78 @@
|
||||
# Readwritesplit
|
||||
|
||||
This document provides a short overview of the **readwritesplit** router module and its intended use case scenarios. It also displays all router configuration parameters with their descriptions. A list of current limitations of the module is included and use examples are provided.
|
||||
This document provides a short overview of the **readwritesplit** router module
|
||||
and its intended use case scenarios. It also displays all router configuration
|
||||
parameters with their descriptions. A list of current limitations of the module
|
||||
is included and use examples are provided.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
## Configuration
|
||||
|
||||
Readwritesplit router-specific settings are specified in the configuration file of MariaDB MaxScale in its specific section. The section can be freely named but the name is used later as a reference in a listener section.
|
||||
Readwritesplit router-specific settings are specified in the configuration file
|
||||
of MariaDB MaxScale in its specific section. The section can be freely named but
|
||||
the name is used later as a reference in a listener section.
|
||||
|
||||
For more details about the standard service parameters, refer to the [Configuration Guide](../Getting-Started/Configuration-Guide.md).
|
||||
For more details about the standard service parameters, refer to the
|
||||
[Configuration Guide](../Getting-Started/Configuration-Guide.md).
|
||||
|
||||
## Optional parameters
|
||||
|
||||
### `max_slave_connections`
|
||||
|
||||
**`max_slave_connections`** sets the maximum number of slaves a router session uses at any moment. The default is to use all available slaves.
|
||||
**`max_slave_connections`** sets the maximum number of slaves a router session
|
||||
uses at any moment. The default is to use all available slaves.
|
||||
|
||||
max_slave_connections=<max. number, or % of available slaves>
|
||||
|
||||
### `max_slave_replication_lag`
|
||||
|
||||
**`max_slave_replication_lag`** specifies how many seconds a slave is allowed to be behind the master. If the lag is bigger than the configured value a slave can't be used for routing.
|
||||
**`max_slave_replication_lag`** specifies how many seconds a slave is allowed to
|
||||
be behind the master. If the lag is bigger than the configured value a slave
|
||||
can't be used for routing.
|
||||
|
||||
This feature is disabled by default.
|
||||
|
||||
max_slave_replication_lag=<allowed lag in seconds>
|
||||
|
||||
This applies to Master/Slave replication with MySQL monitor and `detect_replication_lag=1` options set. max_slave_replication_lag must be greater than the monitor interval.
|
||||
This applies to Master/Slave replication with MySQL monitor and
|
||||
`detect_replication_lag=1` options set. max_slave_replication_lag must be
|
||||
greater than the monitor interval.
|
||||
|
||||
This option only affects Master-Slave clusters. Galera clusters do not have a concept of slave lag even if the application of write sets might have lag.
|
||||
This option only affects Master-Slave clusters. Galera clusters do not have a
|
||||
concept of slave lag even if the application of write sets might have lag.
|
||||
|
||||
### `use_sql_variables_in`
|
||||
|
||||
**`use_sql_variables_in`** specifies where should queries, which read session variable, be routed. The syntax for `use_sql_variable_in` is:
|
||||
**`use_sql_variables_in`** specifies where should queries, which read session
|
||||
variable, be routed. The syntax for `use_sql_variable_in` is:
|
||||
|
||||
use_sql_variables_in=[master|all]
|
||||
|
||||
The default is to use SQL variables in all servers.
|
||||
|
||||
When value `all` is used, queries reading session variables can be routed to any available slave (depending on selection criteria). Queries modifying session variables are routed to all backend servers by default, excluding write queries with embedded session variable modifications, such as:
|
||||
When value `all` is used, queries reading session variables can be routed to any
|
||||
available slave (depending on selection criteria). Queries modifying session
|
||||
variables are routed to all backend servers by default, excluding write queries
|
||||
with embedded session variable modifications, such as:
|
||||
|
||||
INSERT INTO test.t1 VALUES (@myid:=@myid+1)
|
||||
|
||||
In above-mentioned case the user-defined variable would only be updated in the master where the query would be routed to due to the `INSERT` statement.
|
||||
In above-mentioned case the user-defined variable would only be updated in the
|
||||
master where the query would be routed to due to the `INSERT` statement.
|
||||
|
||||
**Note:** As of version 2.1 of MaxScale, all of the router options can also be
|
||||
defined as parameters. The values defined in _router_options_ will have priority
|
||||
@ -65,15 +91,19 @@ master_failure_mode=fail_on_write
|
||||
|
||||
## Router options
|
||||
|
||||
**`router_options`** may include multiple **readwritesplit**-specific options. All the options are parameter-value pairs. All parameters listed in this section must be configured as a value in `router_options`.
|
||||
**`router_options`** may include multiple **readwritesplit**-specific options.
|
||||
All the options are parameter-value pairs. All parameters listed in this section
|
||||
must be configured as a value in `router_options`.
|
||||
|
||||
Multiple options can be defined as a comma-separated list of parameter-value pairs.
|
||||
Multiple options can be defined as a comma-separated list of parameter-value
|
||||
pairs.
|
||||
|
||||
```
|
||||
router_options=<option>,<option>
|
||||
```
|
||||
|
||||
For example, to set **`slave_selection_criteria`** and **`disable_sescmd_history`**, write
|
||||
For example, to set **`slave_selection_criteria`** and
|
||||
**`disable_sescmd_history`**, write
|
||||
|
||||
```
|
||||
router_options=slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS,disable_sescmd_history=true
|
||||
@ -81,7 +111,10 @@ router_options=slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS,disable_sescmd_
|
||||
|
||||
### `slave_selection_criteria`
|
||||
|
||||
This option controls how the readwritesplit router chooses the slaves it connects to and how the load balancing is done. The default behavior is to route read queries to the slave server with the lowest amount of ongoing queries i.e. `LEAST_CURRENT_OPERATIONS`.
|
||||
This option controls how the readwritesplit router chooses the slaves it
|
||||
connects to and how the load balancing is done. The default behavior is to route
|
||||
read queries to the slave server with the lowest amount of ongoing queries i.e.
|
||||
`LEAST_CURRENT_OPERATIONS`.
|
||||
|
||||
The option syntax:
|
||||
|
||||
@ -96,9 +129,12 @@ Where `<criteria>` is one of the following values.
|
||||
* `LEAST_BEHIND_MASTER`, the slave with smallest replication lag
|
||||
* `LEAST_CURRENT_OPERATIONS` (default), the slave with least active operations
|
||||
|
||||
The `LEAST_GLOBAL_CONNECTIONS` and `LEAST_ROUTER_CONNECTIONS` use the connections from MariaDB MaxScale to the server, not the amount of connections reported by the server itself.
|
||||
The `LEAST_GLOBAL_CONNECTIONS` and `LEAST_ROUTER_CONNECTIONS` use the
|
||||
connections from MariaDB MaxScale to the server, not the amount of connections
|
||||
reported by the server itself.
|
||||
|
||||
`LEAST_BEHIND_MASTER` does not take server weights into account when choosing a server.
|
||||
`LEAST_BEHIND_MASTER` does not take server weights into account when choosing a
|
||||
server.
|
||||
|
||||
#### Interaction Between `slave_selection_criteria` and `max_slave_connections`
|
||||
|
||||
@ -106,29 +142,33 @@ Depending on the value of `max_slave_connections`, the slave selection criteria
|
||||
behave in different ways. Here are a few example cases of how the different
|
||||
criteria work with different amounts of slave connections.
|
||||
|
||||
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` and `max_slave_connections=1`, each session picks
|
||||
one slave and one master
|
||||
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` and
|
||||
`max_slave_connections=1`, each session picks one slave and one master
|
||||
|
||||
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` and `max_slave_connections=100%`, each session
|
||||
picks one master and as many slaves as possible
|
||||
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` and
|
||||
`max_slave_connections=100%`, each session picks one master and as many slaves
|
||||
as possible
|
||||
|
||||
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` each read is load balanced based on how many
|
||||
queries are active on a particular slave
|
||||
|
||||
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` each read is sent to the slave with the least
|
||||
amount of connections
|
||||
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` each read is load
|
||||
balanced based on how many queries are active on a particular slave
|
||||
|
||||
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` each read is sent to
|
||||
the slave with the least amount of connections
|
||||
|
||||
### `max_sescmd_history`
|
||||
|
||||
**`max_sescmd_history`** sets a limit on how many session commands each session can execute before the session command history is disabled. The default is an unlimited number of session commands.
|
||||
**`max_sescmd_history`** sets a limit on how many session commands each session
|
||||
can execute before the session command history is disabled. The default is an
|
||||
unlimited number of session commands.
|
||||
|
||||
```
|
||||
# Set a limit on the session command history
|
||||
router_options=max_sescmd_history=1500
|
||||
```
|
||||
|
||||
When a limitation is set, it effectively creates a cap on the session's memory consumption. This might be useful if connection pooling is used and the sessions use large amounts of session commands.
|
||||
When a limitation is set, it effectively creates a cap on the session's memory
|
||||
consumption. This might be useful if connection pooling is used and the sessions
|
||||
use large amounts of session commands.
|
||||
|
||||
### `disable_sescmd_history`
|
||||
|
||||
@ -141,9 +181,8 @@ This option is only intended to be enabled if the value of
|
||||
`max_slave_connections` is lowered below the default value. This will allow a
|
||||
failed slave to be replaced with a standby slave server.
|
||||
|
||||
In versions 2.0 and older, the session command history is enabled by
|
||||
default. Starting with version 2.1, the session command history is disabled by
|
||||
default.
|
||||
In versions 2.0 and older, the session command history is enabled by default.
|
||||
Starting with version 2.1, the session command history is disabled by default.
|
||||
|
||||
```
|
||||
# Disable the session command history
|
||||
@ -152,7 +191,9 @@ router_options=disable_sescmd_history=true
|
||||
|
||||
### `master_accept_reads`
|
||||
|
||||
**`master_accept_reads`** allows the master server to be used for reads. This is a useful option to enable if you are using a small number of servers and wish to use the master for reads as well.
|
||||
**`master_accept_reads`** allows the master server to be used for reads. This is
|
||||
a useful option to enable if you are using a small number of servers and wish to
|
||||
use the master for reads as well.
|
||||
|
||||
By default, no reads are sent to the master.
|
||||
|
||||
@ -163,15 +204,17 @@ 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.
|
||||
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.
|
||||
|
||||
If set to false, queries are routed normally after a multi-statement query.
|
||||
|
||||
**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.
|
||||
**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.
|
||||
|
||||
```
|
||||
# Disable strict multi-statement mode
|
||||
@ -183,18 +226,18 @@ router_options=strict_multi_stmt=false
|
||||
This option controls how the failure of a master server is handled. By default,
|
||||
the router will close the client connection as soon as the master is lost.
|
||||
|
||||
The following table describes the values for this option and how they treat
|
||||
the loss of a master server.
|
||||
The following table describes the values for this option and how they treat the
|
||||
loss of a master server.
|
||||
|
||||
|Value |Description|
|
||||
| Value | Description|
|
||||
|--------------|-----------|
|
||||
|fail_instantly|When the failure of the master server is detected, the connection will be closed immediately.|
|
||||
|fail_on_write |The client connection is closed if a write query is received when no master is available.|
|
||||
|error_on_write|If no master is available and a write query is received, an error is returned stating that the connection is in read-only mode.|
|
||||
|fail_instantly | When the failure of the master server is detected, the connection will be closed immediately.|
|
||||
|fail_on_write | The client connection is closed if a write query is received when no master is available.|
|
||||
|error_on_write | If no master is available and a write query is received, an error is returned stating that the connection is in read-only mode.|
|
||||
|
||||
These also apply to new sessions created after the master has failed. This means
|
||||
that in _fail_on_write_ or _error_on_write_ mode, connections are accepted as long
|
||||
as slave servers are available.
|
||||
that in _fail_on_write_ or _error_on_write_ mode, connections are accepted as
|
||||
long as slave servers are available.
|
||||
|
||||
**Note:** If _master_failure_mode_ is set to _error_on_write_ and the connection
|
||||
to the master is lost, clients will not be able to execute write queries without
|
||||
@ -202,18 +245,19 @@ reconnecting to MariaDB MaxScale once a new master is available.
|
||||
|
||||
### `retry_failed_reads`
|
||||
|
||||
This option controls whether autocommit selects are retried in case of
|
||||
failure. This option is enabled by default.
|
||||
This option controls whether autocommit selects are retried in case of failure.
|
||||
This option is enabled by default.
|
||||
|
||||
When a simple autocommit select is being executed outside of a transaction
|
||||
and the slave server where the query is being executed fails,
|
||||
readwritesplit can retry the read on a replacement server. This makes the
|
||||
failure of a slave transparent to the client.
|
||||
When a simple autocommit select is being executed outside of a transaction and
|
||||
the slave server where the query is being executed fails, readwritesplit can
|
||||
retry the read on a replacement server. This makes the failure of a slave
|
||||
transparent to the client.
|
||||
|
||||
## 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.
|
||||
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
|
||||
@ -223,19 +267,23 @@ hints when you are sure that they can cause no harm.
|
||||
|
||||
## Limitations
|
||||
|
||||
For a list of readwritesplit limitations, please read the [Limitations](../About/Limitations.md) document.
|
||||
For a list of readwritesplit limitations, please read the
|
||||
[Limitations](../About/Limitations.md) document.
|
||||
|
||||
## Examples
|
||||
|
||||
Examples of the readwritesplit router in use can be found in the [Tutorials](../Tutorials) folder.
|
||||
Examples of the readwritesplit router in use can be found in the
|
||||
[Tutorials](../Tutorials) folder.
|
||||
|
||||
## Readwritesplit routing decisions
|
||||
|
||||
Here is a small explanation which shows what kinds of queries are routed to which type of server.
|
||||
Here is a small explanation which shows what kinds of queries are routed to
|
||||
which type of server.
|
||||
|
||||
### Routing to Master
|
||||
|
||||
Routing to master is important for data consistency and because majority of writes are written to binlog and thus become replicated to slaves.
|
||||
Routing to master is important for data consistency and because majority of
|
||||
writes are written to binlog and thus become replicated to slaves.
|
||||
|
||||
The following operations are routed to master:
|
||||
|
||||
@ -247,31 +295,51 @@ The following operations are routed to master:
|
||||
* `EXECUTE` (prepared) statements
|
||||
* all statements using temporary tables
|
||||
|
||||
In addition to these, if the **readwritesplit** service is configured with the `max_slave_replication_lag` parameter, and if all slaves suffer from too much replication lag, then statements will be routed to the _Master_. (There might be other similar configuration parameters in the future which limit the number of statements that will be routed to slaves.)
|
||||
In addition to these, if the **readwritesplit** service is configured with the
|
||||
`max_slave_replication_lag` parameter, and if all slaves suffer from too much
|
||||
replication lag, then statements will be routed to the _Master_. (There might be
|
||||
other similar configuration parameters in the future which limit the number of
|
||||
statements that will be routed to slaves.)
|
||||
|
||||
### Routing to Slaves
|
||||
|
||||
The ability to route some statements to *Slave*s is important because it also decreases the load targeted to master. Moreover, it is possible to have multiple slaves to share the load in contrast to single master.
|
||||
The ability to route some statements to slaves is important because it also
|
||||
decreases the load targeted to master. Moreover, it is possible to have multiple
|
||||
slaves to share the load in contrast to single master.
|
||||
|
||||
Queries which can be routed to slaves must be auto committed and belong to one of the following group:
|
||||
Queries which can be routed to slaves must be auto committed and belong to one
|
||||
of the following group:
|
||||
|
||||
* read-only database queries,
|
||||
* read-only queries to system, or user-defined variables,
|
||||
* `SHOW` statements, and
|
||||
* `SHOW` statements
|
||||
* system function calls.
|
||||
|
||||
### Routing to every session backend
|
||||
|
||||
A third class of statements includes those which modify session data, such as session system variables, user-defined variables, the default database, etc. We call them session commands, and they must be replicated as they affect the future results of read and write operations, so they must be executed on all servers that could execute statements on behalf of this client.
|
||||
A third class of statements includes those which modify session data, such as
|
||||
session system variables, user-defined variables, the default database, etc. We
|
||||
call them session commands, and they must be replicated as they affect the
|
||||
future results of read and write operations. They must be executed on all
|
||||
servers that could execute statements on behalf of this client.
|
||||
|
||||
Session commands include for example:
|
||||
|
||||
* `SET` statements
|
||||
* `USE `*`<dbname>`*
|
||||
* system/user-defined variable assignments embedded in read-only statements, such as `SELECT (@myvar := 5)`
|
||||
* system/user-defined variable assignments embedded in read-only statements, such
|
||||
as `SELECT (@myvar := 5)`
|
||||
* `PREPARE` statements
|
||||
* `QUIT`, `PING`, `STMT RESET`, `CHANGE USER`, etc. commands
|
||||
|
||||
**NOTE: if variable assignment is embedded in a write statement it is routed to _Master_ only. For example, `INSERT INTO t1 values(@myvar:=5, 7)` would be routed to _Master_ only.**
|
||||
**NOTE**: if variable assignment is embedded in a write statement it is routed
|
||||
to _Master_ only. For example, `INSERT INTO t1 values(@myvar:=5, 7)` would be
|
||||
routed to _Master_ only.
|
||||
|
||||
The router stores all of the executed session commands so that in case of a slave failure, a replacement slave can be chosen and the session command history can be repeated on that new slave. This means that the router stores each executed session command for the duration of the session. Applications that use long-running sessions might cause MariaDB MaxScale to consume a growing amount of memory unless the sessions are closed. This can be solved by setting a connection timeout on the application side.
|
||||
The router stores all of the executed session commands so that in case of a
|
||||
slave failure, a replacement slave can be chosen and the session command history
|
||||
can be repeated on that new slave. This means that the router stores each
|
||||
executed session command for the duration of the session. Applications that use
|
||||
long-running sessions might cause MariaDB MaxScale to consume a growing amount
|
||||
of memory unless the sessions are closed. This can be solved by setting a
|
||||
connection timeout on the application side.
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
# MariaDB MaxScale Administration Tutorial
|
||||
|
||||
## Common Administration Tasks
|
||||
|
||||
The purpose of this tutorial is to introduce the MariaDB MaxScale Administrator to a few of the common administration tasks. This is intended to be an introduction for administrators who are new to MariaDB MaxScale and not a reference to all the tasks that may be performed.
|
||||
The purpose of this tutorial is to introduce the MariaDB MaxScale Administrator
|
||||
to a few of the common administration tasks. This is intended to be an
|
||||
introduction for administrators who are new to MariaDB MaxScale and not a
|
||||
reference to all the tasks that may be performed.
|
||||
|
||||
- [Starting MariaDB MaxScale](#starting)
|
||||
- [Stopping MariaDB MaxScale](#stopping)
|
||||
@ -13,51 +14,86 @@ The purpose of this tutorial is to introduce the MariaDB MaxScale Administrator
|
||||
- [Taking A Database Server Out Of Use](#outofuse)
|
||||
|
||||
<a name="starting"></a>
|
||||
### Starting MariaDB MaxScale
|
||||
## Starting MariaDB MaxScale
|
||||
|
||||
There are several ways to start MariaDB MaxScale, the most convenient mechanism
|
||||
is probably using the Linux service interface. When a MariaDB MaxScale package
|
||||
is installed, the package manager will also install a script in /etc/init.d
|
||||
which may be used to start and stop MariaDB MaxScale either directly or via the
|
||||
service interface.
|
||||
|
||||
There are several ways to start MariaDB MaxScale, the most convenient mechanism is probably using the Linux service interface. When a MariaDB MaxScale package is installed, the package manager will also install a script in /etc/init.d which may be used to start and stop MariaDB MaxScale either directly or via the service interface.
|
||||
```
|
||||
$ service maxscale start
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
$ /etc/init.d/maxscale start
|
||||
```
|
||||
It is also possible to start MariaDB MaxScale by executing the maxscale command itself. Running the executable /usr/bin/maxscale will result in MariaDB MaxScale running as a daemon process, unattached to the terminal in which it was started and using configuration files that it finds in the /etc directory.
|
||||
|
||||
Options may be passed to the MariaDB MaxScale binary that alter this default behavior. For a full list of all parameters, refer to the MariaDB MaxScale help output by executing `maxscale --help`.
|
||||
It is also possible to start MariaDB MaxScale by executing the maxscale command
|
||||
itself. Running the executable /usr/bin/maxscale will result in MariaDB MaxScale
|
||||
running as a daemon process, unattached to the terminal in which it was started
|
||||
and using configuration files that it finds in the /etc directory.
|
||||
|
||||
Additional command line arguments can be passed to MariaDB MaxScale with a configuration file placed at `/etc/sysconfig/maxscale` on RPM installations and `/etc/default/maxscale` file on DEB installations. Set the arguments in a variable called `MAXSCALE_OPTIONS` and remember to surround the arguments with quotes. The file should only contain environment variable declarations.
|
||||
Options may be passed to the MariaDB MaxScale binary that alter this default
|
||||
behavior. For a full list of all parameters, refer to the MariaDB MaxScale help
|
||||
output by executing `maxscale --help`.
|
||||
|
||||
Additional command line arguments can be passed to MariaDB MaxScale with a
|
||||
configuration file placed at `/etc/sysconfig/maxscale` on RPM installations and
|
||||
`/etc/default/maxscale` file on DEB installations. Set the arguments in a
|
||||
variable called `MAXSCALE_OPTIONS` and remember to surround the arguments with
|
||||
quotes. The file should only contain environment variable declarations.
|
||||
|
||||
```
|
||||
MAXSCALE_OPTIONS="--logdir=/home/maxscale/logs --piddir=/tmp --syslog=no"
|
||||
```
|
||||
|
||||
<a name="stopping"></a>
|
||||
### Stopping MariaDB MaxScale
|
||||
## Stopping MariaDB MaxScale
|
||||
|
||||
There are numerous ways in which MariaDB MaxScale can be stopped; using the service interface, killing the process or by using the maxadmin utility.
|
||||
There are numerous ways in which MariaDB MaxScale can be stopped; using the
|
||||
service interface, killing the process or by using the maxadmin utility.
|
||||
|
||||
Stopping MariaDB MaxScale with the service interface is simply a case of using
|
||||
the service stop command or calling the init.d script with the stop argument.
|
||||
|
||||
Stopping MariaDB MaxScale with the service interface is simply a case of using the service stop command or calling the init.d script with the stop argument.
|
||||
```
|
||||
$ service maxscale stop
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
$ /etc/init.d/maxscale stop
|
||||
```
|
||||
MariaDB MaxScale will also stop gracefully if it received a terminate signal, to find the process id of the MariaDB MaxScale server use the ps command or read the contents of the maxscale.pid file located in the /var/run/maxscale directory.
|
||||
|
||||
MariaDB MaxScale will also stop gracefully if it received a terminate signal, to
|
||||
find the process id of the MariaDB MaxScale server use the ps command or read
|
||||
the contents of the maxscale.pid file located in the /var/run/maxscale
|
||||
directory.
|
||||
|
||||
```
|
||||
$ kill `cat /var/run/maxscale/maxscale.pid`
|
||||
```
|
||||
In order to shutdown MariaDB MaxScale using the maxadmin command you may either connect with maxadmin in interactive mode or pass the "shutdown maxscale" command you wish to execute as an argument to maxadmin.
|
||||
|
||||
In order to shutdown MariaDB MaxScale using the maxadmin command you may either
|
||||
connect with maxadmin in interactive mode or pass the "shutdown maxscale"
|
||||
command you wish to execute as an argument to maxadmin.
|
||||
|
||||
```
|
||||
$ maxadmin shutdown maxscale
|
||||
```
|
||||
<a name="checking"></a>
|
||||
### Checking The Status Of The MariaDB MaxScale Services
|
||||
|
||||
It is possible to use the maxadmin command to obtain statistics about the services that are running within MaxScale. The maxadmin command "list services" will give very basic information regarding services. This command may be either run in interactive mode or passed on the maxadmin command line.
|
||||
<a name="checking"></a>
|
||||
## Checking The Status Of The MariaDB MaxScale Services
|
||||
|
||||
It is possible to use the maxadmin command to obtain statistics about the
|
||||
services that are running within MaxScale. The maxadmin command "list services"
|
||||
will give very basic information regarding services. This command may be either
|
||||
run in interactive mode or passed on the maxadmin command line.
|
||||
|
||||
```
|
||||
$ maxadmin
|
||||
@ -82,36 +118,38 @@ It is possible to use the maxadmin command to obtain statistics about the servic
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
Network listeners count as a user of the service, therefore there will always be one user per network port in which the service listens. More details can be obtained by using the "show service" command.
|
||||
Network listeners count as a user of the service, therefore there will always be
|
||||
one user per network port in which the service listens. More details can be
|
||||
obtained by using the "show service" command.
|
||||
|
||||
<a name="persistent"></a>
|
||||
### Persistent Connections
|
||||
## Persistent Connections
|
||||
|
||||
When clients who are accessing a database system through MariaDB MaxScale make frequent
|
||||
short connections, there may be a benefit in using persistent connections. This feature
|
||||
is controlled by two configuration values that are specified per server in the relevant
|
||||
server section of the configuration file. The configuration options are `persistpoolmax`
|
||||
and `persistmaxtime`.
|
||||
When clients who are accessing a database system through MariaDB MaxScale make
|
||||
frequent short connections, there may be a benefit in using persistent
|
||||
connections. This feature is controlled by two configuration values that are
|
||||
specified per server in the relevant server section of the configuration file.
|
||||
The configuration options are `persistpoolmax` and `persistmaxtime`.
|
||||
|
||||
Normally, when a client connection is terminated, all the related back end database
|
||||
connections are also terminated. If the `persistpoolmax` options is set to a non-zero
|
||||
integer, then up to that number of connections will be kept in a pool for that
|
||||
server. When a new connection is requested by the system to handle a client session,
|
||||
then a connection from the pool will be used if possible.
|
||||
Normally, when a client connection is terminated, all the related back end
|
||||
database connections are also terminated. If the `persistpoolmax` options is set
|
||||
to a non-zero integer, then up to that number of connections will be kept in a
|
||||
pool for that server. When a new connection is requested by the system to handle
|
||||
a client session, then a connection from the pool will be used if possible.
|
||||
|
||||
The connection will only be taken from the pool if it has been there for no more
|
||||
than `persistmaxtime` seconds. The connection will also be discarded if it has been
|
||||
disconnectedby the back end server. Connections will be selected so that they match
|
||||
the user name and protocol for the new request.
|
||||
than `persistmaxtime` seconds. The connection will also be discarded if it has
|
||||
been disconnectedby the back end server. Connections will be selected so that
|
||||
they match the user name and protocol for the new request.
|
||||
|
||||
Starting with MaxScale 2.1, when a MySQL protocol connection is
|
||||
taken from the pool, the backend protocol module resets the session state. This
|
||||
allows persistent connections to be used with no functional limitations.
|
||||
Starting with MaxScale 2.1, when a MySQL protocol connection is taken from the
|
||||
pool, the backend protocol module resets the session state. This allows
|
||||
persistent connections to be used with no functional limitations.
|
||||
|
||||
The session state is reset when the first outgoing network transmission is
|
||||
done. This _lazy initialization_ of the persistent connections allows
|
||||
MaxScale to take multiple new connections into use but only initialize the
|
||||
ones that it actually needs.
|
||||
The session state is reset when the first outgoing network transmission is done.
|
||||
This _lazy initialization_ of the persistent connections allows MaxScale to take
|
||||
multiple new connections into use but only initialize the ones that it actually
|
||||
needs.
|
||||
|
||||
**Please note** that in versions before 2.1 the persistent connections may give
|
||||
a different environment when compared to a fresh connection. For example, if the
|
||||
@ -125,9 +163,13 @@ It is possible to have pools for as many servers as you wish, with configuration
|
||||
values in each server section.
|
||||
|
||||
<a name="clients"></a>
|
||||
### What Clients Are Connected To MariaDB MaxScale
|
||||
## What Clients Are Connected To MariaDB MaxScale
|
||||
|
||||
To determine what client are currently connected to MariaDB MaxScale, you can use the "list clients" command within maxadmin. This will give you IP address and the ID’s of the DCB and session for that connection. As with any maxadmin command this can be passed on the command line or typed interactively in maxadmin.
|
||||
To determine what client are currently connected to MariaDB MaxScale, you can
|
||||
use the "list clients" command within maxadmin. This will give you IP address
|
||||
and the ID’s of the DCB and session for that connection. As with any maxadmin
|
||||
command this can be passed on the command line or typed interactively in
|
||||
maxadmin.
|
||||
|
||||
```
|
||||
$ maxadmin list clients
|
||||
@ -148,19 +190,27 @@ To determine what client are currently connected to MariaDB MaxScale, you can us
|
||||
```
|
||||
|
||||
<a name="rotating"></a>
|
||||
### Rotating the Log File
|
||||
## Rotating the Log File
|
||||
|
||||
MariaDB MaxScale logs messages of different priority into a single log file. With the exception if error messages that are always logged, whether messages of a particular priority should be logged or not can be enabled via the maxadmin interface or in the configuration file. By default, MaxScale keeps on writing to the same log file. To prevent the file from growing indefinitely, the administrator must take action.
|
||||
MariaDB MaxScale logs messages of different priority into a single log file.
|
||||
With the exception if error messages that are always logged, whether messages of
|
||||
a particular priority should be logged or not can be enabled via the maxadmin
|
||||
interface or in the configuration file. By default, MaxScale keeps on writing to
|
||||
the same log file. To prevent the file from growing indefinitely, the
|
||||
administrator must take action.
|
||||
|
||||
The name of the log file is maxscale.log. When the log is rotated, MaxScale closes the current log file and opens a new one using the same name.
|
||||
The name of the log file is maxscale.log. When the log is rotated, MaxScale
|
||||
closes the current log file and opens a new one using the same name.
|
||||
|
||||
Log file rotation is achieved by use of the "flush log" or “flush logs” command in maxadmin.
|
||||
Log file rotation is achieved by use of the "flush log" or “flush logs” command
|
||||
in maxadmin.
|
||||
|
||||
```
|
||||
$ maxadmin flush logs
|
||||
```
|
||||
|
||||
As there currently is only the maxscale log, that is the only one that will be rotated.
|
||||
As there currently is only the maxscale log, that is the only one that will be
|
||||
rotated.
|
||||
|
||||
The maxscale log can also be flushed explicitly.
|
||||
|
||||
@ -170,8 +220,11 @@ The maxscale log can also be flushed explicitly.
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
This may be integrated into the Linux _logrotate_ mechanism by adding a configuration file to the /etc/logrotate.d directory. If we assume we want to rotate the log files once per month and wish to keep 5 log files worth of history, the configuration file would look as follows.
|
||||
|
||||
This may be integrated into the Linux _logrotate_ mechanism by adding a
|
||||
configuration file to the /etc/logrotate.d directory. If we assume we want to
|
||||
rotate the log files once per month and wish to keep 5 log files worth of
|
||||
history, the configuration file would look as follows.
|
||||
|
||||
```
|
||||
/var/log/maxscale/maxscale.log {
|
||||
monthly
|
||||
@ -190,15 +243,15 @@ endscript
|
||||
|
||||
**Note**:
|
||||
|
||||
If 'root' user is no longer available for maxadmin connection and for example 'user1' is one of the allowed users, the maxadmin command should be run as:
|
||||
If 'root' user is no longer available for maxadmin connection and for example
|
||||
'user1' is one of the allowed users, the maxadmin command should be run as:
|
||||
|
||||
`
|
||||
su - user1 -c '/usr/bin/maxadmin flush logs'
|
||||
`
|
||||
`su - user1 -c '/usr/bin/maxadmin flush logs'`
|
||||
|
||||
If listening socket is not the default one, /tmp/maxadmin.sock, use -S option.
|
||||
|
||||
MariaDB MaxScale will also rotate all of its log files if it receives the USR1 signal. Using this the logrotate configuration script can be rewritten as
|
||||
MariaDB MaxScale will also rotate all of its log files if it receives the USR1
|
||||
signal. Using this the logrotate configuration script can be rewritten as
|
||||
|
||||
```
|
||||
/var/log/maxscale/maxscale.log {
|
||||
@ -213,28 +266,46 @@ endscript
|
||||
}
|
||||
```
|
||||
|
||||
*NOTE* Since MaxScale currently renames the log file, the behaviour is not fully compliant with the assumptions of logrotate and may lead to issues, depending on the used logrotate configuration file. From version 2.1 onwards, MaxScale will not itself rename the log file, but when the log is rotated, MaxScale will simply close and reopen (and truncate) the same log file. That will make the behaviour fully compliant with logrotate.
|
||||
Since MaxScale currently renames the log file, the behaviour is not fully
|
||||
compliant with the assumptions of logrotate and may lead to issues, depending on
|
||||
the used logrotate configuration file. From version 2.1 onwards, MaxScale will
|
||||
not itself rename the log file, but when the log is rotated, MaxScale will
|
||||
simply close and reopen (and truncate) the same log file. That will make the
|
||||
behaviour fully compliant with logrotate.
|
||||
|
||||
<a name="outofuse"></a>
|
||||
### Taking A Database Server Out Of Use
|
||||
## Taking A Database Server Out Of Use
|
||||
|
||||
MariaDB MaxScale supports the concept of maintenance mode for servers within a cluster, this allows for planned, temporary removal of a database from the cluster within the need to change the MariaDB MaxScale configuration.
|
||||
MariaDB MaxScale supports the concept of maintenance mode for servers within a
|
||||
cluster, this allows for planned, temporary removal of a database from the
|
||||
cluster within the need to change the MariaDB MaxScale configuration.
|
||||
|
||||
To achieve the removal of a database server you can use the set server command in the maxadmin utility to set the maintenance mode flag for the server. This may be done interactively within maxadmin or by passing the command on the command line.
|
||||
To achieve the removal of a database server you can use the set server command
|
||||
in the maxadmin utility to set the maintenance mode flag for the server. This
|
||||
may be done interactively within maxadmin or by passing the command on the
|
||||
command line.
|
||||
|
||||
```
|
||||
MaxScale> set server dbserver3 maintenance
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
This will cause MariaDB MaxScale to stop routing any new requests to the server, however if there are currently requests executing on the server these will not be interrupted.
|
||||
This will cause MariaDB MaxScale to stop routing any new requests to the server,
|
||||
however if there are currently requests executing on the server these will not
|
||||
be interrupted.
|
||||
|
||||
To bring the server back into service use the "clear server" command to clear the maintenance mode bit for that server.
|
||||
To bring the server back into service use the "clear server" command to clear
|
||||
the maintenance mode bit for that server.
|
||||
|
||||
```
|
||||
MaxScale> clear server dbserver3 maintenance
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
Note that maintenance mode is not persistent, if MariaDB MaxScale restarts when a node is in maintenance mode a new instance of MariaDB MaxScale will not honor this mode. If multiple MariaDB MaxScale instances are configured to use the node them maintenance mode must be set within each MariaDB MaxScale instance. However if multiple services within one MariaDB MaxScale instance are using the server then you only need set the maintenance mode once on the server for all services to take note of the mode change.
|
||||
|
||||
Note that maintenance mode is not persistent, if MariaDB MaxScale restarts when
|
||||
a node is in maintenance mode a new instance of MariaDB MaxScale will not honor
|
||||
this mode. If multiple MariaDB MaxScale instances are configured to use the node
|
||||
them maintenance mode must be set within each MariaDB MaxScale instance. However
|
||||
if multiple services within one MariaDB MaxScale instance are using the server
|
||||
then you only need set the maintenance mode once on the server for all services
|
||||
to take note of the mode change.
|
||||
|
||||
@ -2,11 +2,13 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The document covers the MySQL Cluster 7.2.17 setup and MariaDB MaxScale configuration for load balancing the SQL nodes access.
|
||||
The document covers the MySQL Cluster 7.2.17 setup and MariaDB MaxScale
|
||||
configuration for load balancing the SQL nodes access.
|
||||
|
||||
## MySQL Cluster setup
|
||||
|
||||
The MySQL Cluster 7.2.17 setup is based on two virtual servers with Linux Centos 6.5
|
||||
The MySQL Cluster 7.2.17 setup is based on two virtual servers with Linux Centos
|
||||
6.5
|
||||
|
||||
- server1:
|
||||
|
||||
@ -19,7 +21,8 @@ The MySQL Cluster 7.2.17 setup is based on two virtual servers with Linux Centos
|
||||
* SQL data node2
|
||||
* MySQL 5.5.38 as SQL node2
|
||||
|
||||
Cluster configuration file is `/var/lib/mysql-cluster/config.ini`, copied on all servers.
|
||||
Cluster configuration file is `/var/lib/mysql-cluster/config.ini`, copied on all
|
||||
servers.
|
||||
|
||||
```
|
||||
[ndbd default]
|
||||
@ -45,7 +48,8 @@ hostname=178.62.38.199
|
||||
hostname=162.243.90.81
|
||||
```
|
||||
|
||||
Note that it’s possible to specify all node id:s and `datadir` as well for each cluster component.
|
||||
Note that it’s possible to specify all node id:s and `datadir` as well for each
|
||||
cluster component.
|
||||
|
||||
Example:
|
||||
|
||||
@ -70,9 +74,12 @@ ndb-connectstring=178.62.38.199
|
||||
|
||||
## Startup of MySQL Cluster
|
||||
|
||||
Each cluster node process must be started separately, and on the host where it resides. The management node should be started first, then the data nodes, and finally any SQL nodes:
|
||||
Each cluster node process must be started separately, and on the host where it
|
||||
resides. The management node should be started first, then the data nodes, and
|
||||
finally any SQL nodes:
|
||||
|
||||
- On the management host, server1, issue the following command from the system shell to start the management node process:
|
||||
- On the management host, server1, issue the following command from the system
|
||||
shell to start the management node process:
|
||||
|
||||
```
|
||||
[root@server1 ~]# ndb_mgmd -f /var/lib/mysql-cluster/config.ini
|
||||
@ -96,14 +103,16 @@ Each cluster node process must be started separately, and on the host where it r
|
||||
|
||||
## Check the cluster status
|
||||
|
||||
If all has gone well and the cluster has been set up correctly, the cluster should now be operational.
|
||||
If all has gone well and the cluster has been set up correctly, the cluster
|
||||
should now be operational.
|
||||
|
||||
It’s possible to test this by invoking the `ndb_mgm` management node client.
|
||||
|
||||
The output should look as shown here, although you might see some slight differences in the output depending upon the exact version of MySQL in use:
|
||||
The output should look as shown here, although you might see some slight
|
||||
differences in the output depending upon the exact version of MySQL in use:
|
||||
|
||||
```
|
||||
[root@server1 ~]# ndb_mgm
|
||||
[root@server1 ~]# ndb_mgm
|
||||
|
||||
-- NDB Cluster -- Management Client --
|
||||
|
||||
@ -131,10 +140,11 @@ id=22 @178.62.38.199 (mysql-5.5.38 ndb-7.2.17)
|
||||
|
||||
id=23 @162.243.90.81 (mysql-5.5.38 ndb-7.2.17)
|
||||
|
||||
ndb_mgm>
|
||||
ndb_mgm>
|
||||
```
|
||||
|
||||
The SQL node is referenced here as [mysqld(API)], which reflects the fact that the mysqld process is acting as a MySQL Cluster API node.
|
||||
The SQL node is referenced here as [mysqld(API)], which reflects the fact that
|
||||
the mysqld process is acting as a MySQL Cluster API node.
|
||||
|
||||
## Working with NDBCLUSTER engine in MySQL
|
||||
|
||||
@ -254,7 +264,8 @@ Assuming MariaDB MaxScale is installed in server1, start it.
|
||||
[root@server1 bin]# ./maxscale -c ../
|
||||
```
|
||||
|
||||
Using the debug interface it’s possible to check the status of monitored servers.
|
||||
Using the debug interface it’s possible to check the status of monitored
|
||||
servers.
|
||||
|
||||
```
|
||||
MaxScale> show monitors
|
||||
@ -297,7 +308,8 @@ Current no. of conns: 0
|
||||
Current no. of operations: 0
|
||||
```
|
||||
|
||||
It’s now possible to run basic tests with the read connection load balancing for the two configured SQL nodes.
|
||||
It’s now possible to run basic tests with the read connection load balancing
|
||||
for the two configured SQL nodes.
|
||||
|
||||
(1) test MaxScale load balancing requesting the Ndb_cluster_node_id variable:
|
||||
|
||||
@ -321,7 +333,8 @@ It’s now possible to run basic tests with the read connection load balancing
|
||||
|
||||
The MariaDB MaxScale connection load balancing is working.
|
||||
|
||||
(2) test a select statement on an NBDBCLUSTER table, database test and table t1 created before:
|
||||
(2) test a select statement on an NBDBCLUSTER table, database test and table t1
|
||||
created before:
|
||||
|
||||
```
|
||||
[root@server1 ~] mysql -h 127.0.0.1 -P 4906 -utest -ptest -e "SELECT COUNT(1) FROM test.t1"
|
||||
|
||||
@ -2,19 +2,34 @@
|
||||
|
||||
## Environment & Solution Space
|
||||
|
||||
The object of this tutorial is to have a system that appears to the clients of MariaDB MaxScale as if there was a single database behind MariaDB MaxScale. MariaDB MaxScale will split the statements such that write statements will be sent to the current master server in the replication cluster and read statements will be balanced across the rest of the slave servers.
|
||||
The object of this tutorial is to have a system that appears to the clients of
|
||||
MariaDB MaxScale as if there was a single database behind MariaDB MaxScale.
|
||||
MariaDB MaxScale will split the statements such that write statements will be
|
||||
sent to the current master server in the replication cluster and read statements
|
||||
will be balanced across the rest of the slave servers.
|
||||
|
||||
## Setting up MariaDB MaxScale
|
||||
|
||||
The first part of this tutorial is covered in [MariaDB MaxScale Tutorial](MaxScale-Tutorial.md). Please read it and follow the instructions for setting up MariaDB MaxScale with the type of cluster you want to use.
|
||||
The first part of this tutorial is covered in
|
||||
[MariaDB MaxScale Tutorial](MaxScale-Tutorial.md). Please read it and follow the
|
||||
instructions for setting up MariaDB MaxScale with the type of cluster you want
|
||||
to use.
|
||||
|
||||
Once you have MariaDB MaxScale installed and the database users created, the configuration file for MariaDB MaxScale can be written.
|
||||
Once you have MariaDB MaxScale installed and the database users created, the
|
||||
configuration file for MariaDB MaxScale can be written.
|
||||
|
||||
## Creating Your MariaDB MaxScale Configuration
|
||||
|
||||
MariaDB MaxScale configuration is defined in the file `maxscale.cnf` located in the directory `/etc`. If you have installed MaxScale in the default location the file path should be `/etc/maxscale.cnf`. This file is not created as part of the installation process and must be manually created. A template file, which may be used as a basis for your configuration, exists within the `/usr/share/maxscale` directory.
|
||||
MariaDB MaxScale configuration is defined in the file `maxscale.cnf` located in
|
||||
the directory `/etc`. If you have installed MaxScale in the default location the
|
||||
file path should be `/etc/maxscale.cnf`. This file is not created as part of the
|
||||
installation process and must be manually created. A template file, which may be
|
||||
used as a basis for your configuration, exists within the `/usr/share/maxscale`
|
||||
directory.
|
||||
|
||||
A global section, marked `maxscale`, is included within every MariaDB MaxScale configuration file. The section is used to set the values of various process-wide parameters, for example the number of worker threads.
|
||||
A global section, marked `maxscale`, is included within every MariaDB MaxScale
|
||||
configuration file. The section is used to set the values of various
|
||||
process-wide parameters, for example the number of worker threads.
|
||||
|
||||
```
|
||||
[maxscale]
|
||||
@ -22,14 +37,20 @@ threads=4
|
||||
|
||||
```
|
||||
|
||||
The first step is to create a Read/Write Splitter service. Create a section in your configuration file and set the type to service. The section header is the name of the service and should be meaningful to the administrator. Names may contain whitespace.
|
||||
The first step is to create a Read/Write Splitter service. Create a section in
|
||||
your configuration file and set the type to service. The section header is the
|
||||
name of the service and should be meaningful to the administrator. Names may
|
||||
contain whitespace.
|
||||
|
||||
```
|
||||
[Splitter Service]
|
||||
type=service
|
||||
```
|
||||
|
||||
The router module needed for this service is named `readwritesplit`. The service must contain a list of backend server names. The server names are the headers of server sections in the configuration file and not the physical hostnames or addresses of the servers.
|
||||
The router module needed for this service is named `readwritesplit`. The service
|
||||
must contain a list of backend server names. The server names are the headers of
|
||||
server sections in the configuration file and not the physical hostnames or
|
||||
addresses of the servers.
|
||||
|
||||
```
|
||||
[Splitter Service]
|
||||
@ -38,14 +59,20 @@ router=readwritesplit
|
||||
servers=dbserv1, dbserv2, dbserv3
|
||||
```
|
||||
|
||||
The final step in the service section is to add the username and password that will be used to populate the user data from the database cluster. There are two options for representing the password: either plain text or encrypted passwords. To use encrypted passwords, a set of keys for encryption/decryption must be generated. To generate the keys use the `maxkeys` command and pass the name of the secrets file containing the keys.
|
||||
The final step in the service section is to add the username and password that
|
||||
will be used to populate the user data from the database cluster. There are two
|
||||
options for representing the password: either plain text or encrypted passwords.
|
||||
To use encrypted passwords, a set of keys for encryption/decryption must be
|
||||
generated. To generate the keys use the `maxkeys` command and pass the name of
|
||||
the secrets file containing the keys.
|
||||
|
||||
```
|
||||
maxkeys /var/lib/maxscale/.secrets
|
||||
|
||||
```
|
||||
|
||||
Once the keys have been created, use the `maxpasswd` command to generate the encrypted password.
|
||||
Once the keys have been created, use the `maxpasswd` command to generate the
|
||||
encrypted password.
|
||||
|
||||
```
|
||||
maxpasswd plainpassword
|
||||
@ -54,7 +81,8 @@ maxpasswd plainpassword
|
||||
|
||||
```
|
||||
|
||||
The username and password, either encrypted or in plain text, are stored in the service section.
|
||||
The username and password, either encrypted or in plain text, are stored in the
|
||||
service section.
|
||||
|
||||
```
|
||||
[Splitter Service]
|
||||
@ -65,7 +93,11 @@ user=maxscale
|
||||
passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
```
|
||||
|
||||
This completes the service definition. To have the service accept network connections, a listener must be associated with it. The listener is defined in its own section. The type should be `listener` with an entry `service` defining the name of the service the listener is listening for. A service may have multiple listeners.
|
||||
This completes the service definition. To have the service accept network
|
||||
connections, a listener must be associated with it. The listener is defined in
|
||||
its own section. The type should be `listener` with an entry `service` defining
|
||||
the name of the service the listener is listening for. A service may have
|
||||
multiple listeners.
|
||||
|
||||
```
|
||||
[Splitter Listener]
|
||||
@ -73,7 +105,10 @@ type=listener
|
||||
service=Splitter Service
|
||||
```
|
||||
|
||||
A listener must also define the protocol module it will use for the incoming network protocol, currently this should be the `MySQLClient` protocol for all database listeners. The listener may then supply a network port to listen on and/or a socket within the file system.
|
||||
A listener must also define the protocol module it will use for the incoming
|
||||
network protocol, currently this should be the `MySQLClient` protocol for all
|
||||
database listeners. The listener may then supply a network port to listen on
|
||||
and/or a socket within the file system.
|
||||
|
||||
```
|
||||
[Splitter Listener]
|
||||
@ -84,9 +119,16 @@ port=3306
|
||||
socket=/tmp/ClusterMaster
|
||||
```
|
||||
|
||||
An address parameter may be given if the listener is required to bind to a particular network address when using hosts with multiple network addresses. The default behavior is to listen on all network interfaces.
|
||||
An address parameter may be given if the listener is required to bind to a
|
||||
particular network address when using hosts with multiple network addresses. The
|
||||
default behavior is to listen on all network interfaces.
|
||||
|
||||
The next stage in the configuration is to define the backend servers. The
|
||||
definitions include how to connect to the servers. A section is created for each
|
||||
server and it contains: `type` set to `server`, the network address and port,
|
||||
and the protocol to use. Currently, the protocol module for all database
|
||||
connections is `MySQLBackend`.
|
||||
|
||||
The next stage in the configuration is to define the backend servers. The definitions include how to connect to the servers. A section is created for each server and it contains: `type` set to `server`, the network address and port, and the protocol to use. Currently, the protocol module for all database connections is `MySQLBackend`.
|
||||
```
|
||||
[dbserv1]
|
||||
type=server
|
||||
@ -107,7 +149,11 @@ port=3306
|
||||
protocol=MySQLBackend
|
||||
```
|
||||
|
||||
For MariaDB MaxScale to monitor the servers using the correct monitoring mechanisms a monitor section should be written. This section defines the monitor module to use and the monitored servers. The section `type` should be set to `monitor`. Parameters added include: the list of servers to monitor and the username and password the monitor module should use when connecting.
|
||||
For MariaDB MaxScale to monitor the servers using the correct monitoring
|
||||
mechanisms a monitor section should be written. This section defines the monitor
|
||||
module to use and the monitored servers. The section `type` should be set to
|
||||
`monitor`. Parameters added include: the list of servers to monitor and the
|
||||
username and password the monitor module should use when connecting.
|
||||
|
||||
```
|
||||
[Replication Monitor]
|
||||
@ -118,9 +164,13 @@ user=maxscale
|
||||
passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
```
|
||||
|
||||
Similarly to the password definition in the server either a plain text or an encrypted password may be used.
|
||||
Similarly to the password definition in the server either a plain text or an
|
||||
encrypted password may be used.
|
||||
|
||||
The final stage in the configuration is to add the service which used by the `maxadmin` command to connect to MariaDB MaxScale for monitoring and administration purposes. The example below shows a service section and a listener section.
|
||||
The final stage in the configuration is to add the service which used by the
|
||||
`maxadmin` command to connect to MariaDB MaxScale for monitoring and
|
||||
administration purposes. The example below shows a service section and a
|
||||
listener section.
|
||||
|
||||
```
|
||||
[CLI]
|
||||
@ -136,16 +186,25 @@ socket=default
|
||||
|
||||
# Starting MariaDB MaxScale
|
||||
|
||||
Upon completion of the configuration MariaDB MaxScale is ready to be started. This may either be done manually by running the `maxscale` command or via the service interface.
|
||||
Upon completion of the configuration MariaDB MaxScale is ready to be started.
|
||||
This may either be done manually by running the `maxscale` command or via the
|
||||
service interface.
|
||||
|
||||
```
|
||||
% maxscale
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
% service maxscale start
|
||||
```
|
||||
Check the error log in /var/log/maxscale to see if any errors are detected in the configuration file and to confirm MariaDB MaxScale has been started. Also the maxadmin command may be used to confirm that MariaDB MaxScale is running and the services, listeners etc have been correctly configured.
|
||||
|
||||
Check the error log in /var/log/maxscale to see if any errors are detected in
|
||||
the configuration file and to confirm MariaDB MaxScale has been started. Also
|
||||
the maxadmin command may be used to confirm that MariaDB MaxScale is running and
|
||||
the services, listeners etc have been correctly configured.
|
||||
|
||||
```
|
||||
% maxadmin list services
|
||||
|
||||
@ -199,5 +258,12 @@ CLI | maxscaled | localhost | 6603 | Running
|
||||
```
|
||||
|
||||
|
||||
MariaDB MaxScale is now ready to start accepting client connections and routing them to the master or slaves within your cluster. Other configuration options, that can alter the criteria used for routing, are available. These include monitoring the replication lag within the cluster and routing only to slaves that are within a predetermined delay from the current master or using weights to obtain unequal balancing operations. These options may be found in the MariaDB MaxScale Configuration Guide. More details on the use of maxadmin can be found in the document [MaxAdmin - The MariaDB MaxScale Administration & Monitoring Client Application](Administration-Tutorial.md).
|
||||
|
||||
MariaDB MaxScale is now ready to start accepting client connections and routing
|
||||
them to the master or slaves within your cluster. Other configuration options,
|
||||
that can alter the criteria used for routing, are available. These include
|
||||
monitoring the replication lag within the cluster and routing only to slaves
|
||||
that are within a predetermined delay from the current master or using weights
|
||||
to obtain unequal balancing operations. These options may be found in the
|
||||
MariaDB MaxScale Configuration Guide. More details on the use of maxadmin can be
|
||||
found in the document
|
||||
[MaxAdmin - The MariaDB MaxScale Administration & Monitoring Client Application](Administration-Tutorial.md).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user