2.1 doc esak (#127)
* Update MySQL-Replication-Read-Write-Splitting-Tutorial.md * Update MySQL-Replication-Read-Write-Splitting-Tutorial.md * Update MySQL-Replication-Read-Write-Splitting-Tutorial.md * Update MySQL-Cluster-Setup.md * Update Administration-Tutorial.md * Update Administration-Tutorial.md * Update Galera-Cluster-Connection-Routing-Tutorial.md * Update CLI.md * Update ReadWriteSplit.md * Update Tee-Filter.md * Update CCRFilter.md * Update RabbitMQ-Filter.md * Update Debug-And-Diagnostic-Support.md * Update MaxBinlogCheck.md * Update Configuration-Guide.md * Update Module-Commands.md
This commit is contained in:
Esa Korhonen
GitHub
parent
73c38230fe
commit
e8dfccb4c8
@ -10,7 +10,7 @@ done through MaxScale while still allowing scaleout of non-critical reads.
|
||||
When the filter detects a statement that would modify the database, it attaches a
|
||||
routing hint to all following statements. This routing hint guides the routing
|
||||
module to route the statement to the master server where data is guaranteed to be
|
||||
in a up-to-date state.
|
||||
in an up-to-date state.
|
||||
|
||||
## Filter Options
|
||||
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
#RabbitMQ Filter
|
||||
# RabbitMQ Filter
|
||||
|
||||
## 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 canonicalized queries and their replies in to a RabbitMQ broker where they can later be retrieved. The retrieval can be done with your own 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
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Overview
|
||||
|
||||
The tee filter is a filter module for MariaDB MaxScale is a "plumbing" fitting in the MariaDB MaxScale filter toolkit. It can be used in a filter pipeline of a service to make a copy of requests from the client and dispatch a copy of the request 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
|
||||
|
||||
@ -45,7 +45,7 @@ The tee filter requires a mandatory parameter to define the service to replicate
|
||||
|
||||
### Match
|
||||
|
||||
An optional parameter that can be 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*
|
||||
@ -55,7 +55,7 @@ All regular expressions are evaluated with the option to ignore the case of the
|
||||
|
||||
### Exclude
|
||||
|
||||
An optional parameter that can be 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
|
||||
@ -83,9 +83,9 @@ 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 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,11 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
The purpose of this document is to describe how to configure MariaDB MaxScale
|
||||
and to discuss some possible usage scenarios for MariaDB MaxScale. MariaDB
|
||||
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 MariaDB MaxScale itself.
|
||||
the behavior of the program.
|
||||
|
||||
# Table of Contents
|
||||
|
||||
@ -25,23 +25,22 @@ the behavior of the MariaDB MaxScale itself.
|
||||
* [Authentication](#authentication)
|
||||
* [Error Reporting](#error-reporting)
|
||||
|
||||
### Terms
|
||||
## Glossary
|
||||
|
||||
|
||||
| Term | Description
|
||||
------------------- | ------------------
|
||||
service | A service represents a set of databases with a specific access mechanism that is offered to clients of MariaDB MaxScale. The access mechanism defines the algorithm that MariaDB MaxScale will use to direct particular requests to the individual databases.
|
||||
server | A server represents an individual database server to which a client can be connected via MariaDB MaxScale.
|
||||
router | A router is a module within MariaDB MaxScale that will route client requests to the various database servers which MariaDB MaxScale provides a service interface to.
|
||||
connection routing | Connection routing is a method of handling requests in which MariaDB MaxScale will accept connections from a client and route data on that connection to a single database using a single connection. Connection based routing will not examine individual requests on a connection and it will not move that connection once it is established.
|
||||
statement routing | Statement routing is a method of handling requests in which each request within a connection will be handled individually. Requests may be sent to one or more servers and connections may be dynamically added or removed from the session.
|
||||
protocol | A protocol is a module of software that is used to communicate with another software entity within the system. MariaDB MaxScale supports the dynamic loading of protocol modules to allow for increased flexibility.
|
||||
module | A module is a separate code entity that may be loaded dynamically into MariaDB MaxScale to increase the available functionality. Modules are implemented as run-time loadable shared objects.
|
||||
monitor | A monitor is a module that can be executed within MariaDB MaxScale to monitor the state of a set of database. The use of an internal monitor is optional, monitoring may be performed externally to MariaDB MaxScale.
|
||||
listener | A listener is the network endpoint that is used to listen for connections to MariaDB MaxScale from the client applications. A listener is associated to a single service, however, a service may have many listeners.
|
||||
connection failover| When a connection currently being used between MariaDB MaxScale and the database server fails a replacement will be automatically created to another server by MariaDB MaxScale without client intervention
|
||||
backend database | A term used to refer to a database that sits behind MariaDB MaxScale and is accessed by applications via MariaDB MaxScale.
|
||||
filter | A module that can be placed between the client and the MariaDB MaxScale router module. All client data passes through the filter module and may be examined or modified by the filter modules. Filters may be chained together to form processing pipelines.
|
||||
Word | Description
|
||||
--------------------|----------------------------------------------------
|
||||
service | A service represents a set of databases with a specific access mechanism that is offered to clients of MariaDB MaxScale. The access mechanism defines the algorithm that MariaDB MaxScale will use to direct particular requests to the individual databases.
|
||||
server | A server represents an individual database server to which a client can be connected via MariaDB MaxScale.
|
||||
router | A router is a module within MariaDB MaxScale that will route client requests to the various database servers which MariaDB MaxScale provides a service interface to.
|
||||
connection routing | Connection routing is a method of handling requests in which MariaDB MaxScale will accept connections from a client and route data on that connection to a single database using a single connection. Connection based routing will not examine individual requests on a connection and it will not move that connection once it is established.
|
||||
statement routing | Statement routing is a method of handling requests in which each request within a connection will be handled individually. Requests may be sent to one or more servers and connections may be dynamically added or removed from the session.
|
||||
protocol | A protocol is a module of software that is used to communicate with another software entity within the system. MariaDB MaxScale supports the dynamic loading of protocol modules to allow for increased flexibility.
|
||||
module | A module is a separate code entity that may be loaded dynamically into MariaDB MaxScale to increase the available functionality. Modules are implemented as run-time loadable shared objects.
|
||||
monitor | A monitor is a module that can be executed within MariaDB MaxScale to monitor the state of a set of database. The use of an internal monitor is optional, monitoring may be performed externally to MariaDB MaxScale.
|
||||
listener | A listener is the network endpoint that is used to listen for connections to MariaDB MaxScale from the client applications. A listener is associated to a single service, however, a service may have many listeners.
|
||||
connection failover | When a connection currently being used between MariaDB MaxScale and the database server fails a replacement will be automatically created to another server by MariaDB MaxScale without client intervention
|
||||
backend database | A term used to refer to a database that sits behind MariaDB MaxScale and is accessed by applications via MariaDB MaxScale.
|
||||
filter | A module that can be placed between the client and the MariaDB MaxScale router module. All client data passes through the filter module and may be examined or modified by the filter modules. Filters may be chained together to form processing pipelines.
|
||||
|
||||
## Configuration
|
||||
|
||||
@ -134,7 +133,7 @@ used for systems dedicated for running MariaDB MaxScale.
|
||||
threads=1
|
||||
```
|
||||
|
||||
It should be noted that additional threads will be created to execute other
|
||||
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.
|
||||
|
||||
@ -346,7 +345,7 @@ To disable the augmentation use the value 0 and to enable it use the value 1.
|
||||
|
||||
#### `log_throttling`
|
||||
|
||||
In some circumstances it is possible that a particular error (or warning) is
|
||||
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
|
||||
|
||||
@ -1,10 +1,4 @@
|
||||
MariaDB MaxScale
|
||||
|
||||
Debug & Diagnostic Support
|
||||
|
||||
Mark Riddoch
|
||||
|
||||
Last Updated: 24th November 2014
|
||||
# MariaDB MaxScale Debug & Diagnostic Support
|
||||
|
||||
[[TOC]]
|
||||
|
||||
|
||||
@ -1,24 +1,16 @@
|
||||
# Maxbinlogcheck
|
||||
|
||||
# The MySQL/MariaDB binlog check utility
|
||||
|
||||
Massimiliano Pinto
|
||||
|
||||
Last Updated: 07th December 2016
|
||||
# Maxbinlogcheck, the MySQL/MariaDB binlog check utility
|
||||
|
||||
# Overview
|
||||
|
||||
Maxbinlogcheck is a command line utility for checking binlogfiles downloaded by MariaDB MaxScale binlog router or the MySQL/MariaDB binlog files stored in a database server acting as a master in a replication environment.
|
||||
It checks the binlog file against any corruption and incomplete transaction stored and reports a transaction summary after reading all the events.
|
||||
It may optionally truncate 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
|
||||
Maxbinlogcheck supports:
|
||||
|
||||
* MariaDB 5.5 and MySQL 5.6
|
||||
|
||||
* MariaDB 10.0 and 10.1 with a command line option
|
||||
|
||||
# Running maxbinlogcheck
|
||||
|
||||
```
|
||||
# /usr/local/bin/maxbinlogcheck /path_to_file/bin.000002
|
||||
```
|
||||
@ -36,27 +28,27 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<tr>
|
||||
<td>-f</td>
|
||||
<td>--fix</td>
|
||||
<td>If the option is set the binlog file will be truncated at last safe transaction pos in case of any error</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>
|
||||
<td>--mariadb10</td>
|
||||
<td>Check the current binlog against MariaDB 10.0.x events</td>
|
||||
<td>Checks the current binlog against MariaDB 10.0.x events</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-d</td>
|
||||
<td>--debug</td>
|
||||
<td>Set 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>
|
||||
<td>--help</td>
|
||||
<td>Print usage information regarding maxbinlogcheck</td>
|
||||
<td>Prints usage information regarding maxbinlogcheck</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-V</td>
|
||||
<td>--version</td>
|
||||
<td>Print the maxbinlogcheck version information</td>
|
||||
<td>Prints the maxbinlogcheck version information</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>-K</td>
|
||||
@ -71,7 +63,7 @@ The maxbinlogcheck command accepts a number of switches
|
||||
<tr>
|
||||
<td>-H</td>
|
||||
<td>--header</td>
|
||||
<td>Print the binlog event header</td>
|
||||
<td>Prints the binlog event header</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
@ -183,7 +175,7 @@ This file is corrupted, as reported by the utility:
|
||||
2015-09-08 10:03:16 Check retcode: 1, Binlog Pos = 245
|
||||
```
|
||||
|
||||
The suggested safe pos is 245
|
||||
The suggested safe pos is 245.
|
||||
|
||||
Use -f option for fix with debug:
|
||||
|
||||
@ -281,8 +273,9 @@ And finally big transaction is now done.
|
||||
2015-09-08 10:17:16 Check retcode: 0, Binlog Pos = 590760698
|
||||
```
|
||||
|
||||
**Note**
|
||||
with current maxbinlogcheck it's not possible to fix a binlog with incomplete transaction and no other errors
|
||||
**Note**
|
||||
|
||||
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:
|
||||
|
||||
|
||||
@ -53,9 +53,8 @@ int main(int argc, char **argv)
|
||||
}
|
||||
```
|
||||
|
||||
The array of _modulecmd_arg_type_t_ type is used to tell what kinds of arguments
|
||||
the command expects. The first argument is a SERVER which will be replaced with a
|
||||
pointer to a server. The second argument is an optional string argument.
|
||||
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.
|
||||
|
||||
@ -5,7 +5,7 @@ of the `maxscaled` protocol.
|
||||
|
||||
## Configuration
|
||||
|
||||
Two components are required in order to run the command line interface for use with
|
||||
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.
|
||||
|
||||
@ -31,6 +31,7 @@ protocol=maxscaled
|
||||
address=localhost
|
||||
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
|
||||
@ -38,9 +39,9 @@ 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.
|
||||
`-P` options, respectively.
|
||||
|
||||
Note that if Unix domain sockets are used, the connection is secure, but _maxadmin_
|
||||
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.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# 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 examples of the router's use 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
|
||||
|
||||
@ -10,7 +10,7 @@ The router is designed to be used with a traditional Master-Slave replication cl
|
||||
|
||||
## 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 from 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).
|
||||
|
||||
@ -23,18 +23,16 @@ For more details about the standard service parameters, refer to the [Configurat
|
||||
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 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.
|
||||
Please note max_slave_replication_lag must be greater than 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 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.
|
||||
|
||||
### `use_sql_variables_in`
|
||||
|
||||
@ -44,11 +42,11 @@ concept of slave lag even if the application of write sets might have lag.
|
||||
|
||||
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). Note, that 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 query would be routed due to `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
|
||||
@ -74,7 +72,9 @@ Multiple options can be defined as a comma-separated list of parameter-value pai
|
||||
```
|
||||
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
|
||||
```
|
||||
@ -241,8 +241,8 @@ The following operations are routed to master:
|
||||
|
||||
* write statements,
|
||||
* all statements within an open transaction,
|
||||
* stored procedure calls, and
|
||||
* user-defined function calls.
|
||||
* stored procedure calls
|
||||
* user-defined function calls
|
||||
* DDL statements (`DROP`|`CREATE`|`ALTER TABLE` … etc.)
|
||||
* `EXECUTE` (prepared) statements
|
||||
* all statements using temporary tables
|
||||
|
||||
@ -1,10 +1,8 @@
|
||||
# MariaDB MaxScale Administration Tutorial
|
||||
|
||||
Last updated 24th June 2015
|
||||
|
||||
## Common Administration Tasks
|
||||
|
||||
The purpose of this tutorial is to introduce the MariaDB MaxScale Administrator to a few of the common administration tasks that need to be performed with MariaDB MaxScale. It is not intended as a reference to all the tasks that may be performed, more this is aimed as an introduction for administrators who are new to MariaDB MaxScale.
|
||||
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)
|
||||
@ -17,7 +15,7 @@ The purpose of this tutorial is to introduce the MariaDB MaxScale Administrator
|
||||
<a name="starting"></a>
|
||||
### 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 installed 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
|
||||
```
|
||||
@ -38,7 +36,7 @@ MAXSCALE_OPTIONS="--logdir=/home/maxscale/logs --piddir=/tmp --syslog=no"
|
||||
<a name="stopping"></a>
|
||||
### Stopping MariaDB MaxScale
|
||||
|
||||
There are numerous ways in which MariaDB MaxScale can be stopped; using the service interface, killing the process or by use of 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.
|
||||
```
|
||||
@ -59,7 +57,7 @@ In order to shutdown MariaDB MaxScale using the maxadmin command you may either
|
||||
<a name="checking"></a>
|
||||
### Checking The Status Of The MariaDB MaxScale Services
|
||||
|
||||
It is possible to use the maxadmin command to obtain statistics regarding the services that are configured within your MariaDB MaxScale configuration file. The maxadmin command "list services" will give very basic information regarding the services that are define. This command may be either run in interactive mode or passed on the maxadmin command line.
|
||||
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
|
||||
@ -84,30 +82,30 @@ It is possible to use the maxadmin command to obtain statistics regarding the se
|
||||
MaxScale>
|
||||
```
|
||||
|
||||
It should be noted that 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 detail can be obtained by use of the "show service" command which is passed a service name.
|
||||
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
|
||||
|
||||
Where the clients who are accessing a database system through MariaDB MaxScale make frequent
|
||||
short connections, there may be a benefit from invoking the MariaDB MaxScale Persistent
|
||||
Connection feature. This 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
|
||||
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 meet a new client request,
|
||||
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. It was also be discarded if it has been disconnected
|
||||
by the back end server. Connections will be selected that 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 the 2.1 version of MaxScale, when a MySQL protocol connection is
|
||||
taken from the pool the backend protocol module resets the session state. This
|
||||
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
|
||||
@ -129,7 +127,7 @@ values in each server section.
|
||||
<a name="clients"></a>
|
||||
### 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,29 +146,34 @@ To determine what client are currently connected to MariaDB MaxScale you can use
|
||||
|
||||
$
|
||||
```
|
||||
|
||||
<a name="rotating"></a>
|
||||
### 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, so 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.
|
||||
|
||||
When MaxScale is started for the first time, the name of the log file is maxscale1.log. When the log is rotated, MaxScale closes the current log file and opens a new one where the sequence number is increased by one. That is, the first time the log is rotated, the name will be maxscale2.log.
|
||||
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.
|
||||
|
||||
```
|
||||
$ maxadmin flush logs
|
||||
```
|
||||
Flushes all logs. However, 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.
|
||||
|
||||
```
|
||||
$ maxadmin
|
||||
MaxScale> flush log maxscale
|
||||
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 like the following.
|
||||
|
||||
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/*.log {
|
||||
/var/log/maxscale/maxscale.log {
|
||||
monthly
|
||||
rotate 5
|
||||
missingok
|
||||
@ -186,16 +189,19 @@ endscript
|
||||
```
|
||||
|
||||
**Note**:
|
||||
If 'root' user is no longer available for maxadmin connection and say 'user1' is one of the allowed users, the maxadmin command should be run this way:
|
||||
|
||||
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'
|
||||
`
|
||||
|
||||
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
|
||||
|
||||
```
|
||||
/var/log/maxscale/*.log {
|
||||
/var/log/maxscale/maxscale.log {
|
||||
monthly
|
||||
rotate 5
|
||||
missingok
|
||||
@ -215,16 +221,20 @@ endscript
|
||||
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.
|
||||
|
||||
```
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -1,30 +1,8 @@
|
||||
# MySQL Cluster setup and MariaDB MaxScale configuration
|
||||
|
||||
Massimiliano Pinto
|
||||
|
||||
Last Updated: 1st August 2014
|
||||
|
||||
## Contents
|
||||
|
||||
## Document History
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>Date</td>
|
||||
<td>Change</td>
|
||||
<td>Who</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>31st July 2014</td>
|
||||
<td>Initial version</td>
|
||||
<td>Massimiliano Pinto</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
The document covers the MySQL Cluster 7.2.17 setup and MariaDB MaxScale configuration in order to 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
|
||||
|
||||
@ -32,19 +10,16 @@ The MySQL Cluster 7.2.17 setup is based on two virtual servers with Linux Centos
|
||||
|
||||
- server1:
|
||||
|
||||
NDB Manager process
|
||||
* NDB Manager process
|
||||
* SQL data node1
|
||||
* MySQL 5.5.38 as SQL node1
|
||||
|
||||
SQL data node1
|
||||
- server2:
|
||||
|
||||
MySQL 5.5.38 as SQL node1
|
||||
* SQL data node2
|
||||
* MySQL 5.5.38 as SQL node2
|
||||
|
||||
- server2:
|
||||
|
||||
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]
|
||||
@ -70,7 +45,7 @@ hostname=178.62.38.199
|
||||
hostname=162.243.90.81
|
||||
```
|
||||
|
||||
Note, it’s possible to specify all node ids 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:
|
||||
|
||||
@ -81,7 +56,7 @@ id=43
|
||||
datadir=/usr/local/mysql/data
|
||||
```
|
||||
|
||||
and /etc/my.cnf, copied as well in all servers
|
||||
Also, `/etc/my.cnf`, copied as well in all servers.
|
||||
|
||||
```
|
||||
[mysqld]
|
||||
@ -95,31 +70,38 @@ 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, followed by the data nodes, and then finally by 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:
|
||||
|
||||
```
|
||||
[root@server1 ~]# ndb_mgmd -f /var/lib/mysql-cluster/config.ini
|
||||
```
|
||||
|
||||
- On each of the data node hosts, run this command to start the ndbd process:
|
||||
|
||||
```
|
||||
[root@server1 ~]# ndbd —-initial -—initial-start
|
||||
|
||||
[root@server2 ~]# ndbd —-initial -—initial-start
|
||||
```
|
||||
|
||||
- On each SQL node start the MySQL server process:
|
||||
|
||||
```
|
||||
[root@server1 ~]# /etc/init.d/mysql start
|
||||
|
||||
[root@server2 ~]# /etc/init.d/mysql start
|
||||
```
|
||||
|
||||
## 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.
|
||||
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 like that shown here, although you might see some slight differences in the output depending upon the exact version of MySQL that you are using:
|
||||
```
|
||||
[root@server1 ~]# ndb_mgm
|
||||
|
||||
@ -151,11 +133,13 @@ id=23 @162.243.90.81 (mysql-5.5.38 ndb-7.2.17)
|
||||
|
||||
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.
|
||||
|
||||
## Working with NDBCLUSTER engine in MySQL
|
||||
|
||||
- First create a table with NDBCLUSTER engine:
|
||||
|
||||
```
|
||||
[root@server1 ~]# mysql
|
||||
|
||||
@ -179,13 +163,17 @@ mysql> show create table t1;
|
||||
|
||||
1 row in set (0.01 sec)
|
||||
```
|
||||
- Just add a row in the table:
|
||||
|
||||
- Add a row in the table:
|
||||
|
||||
```
|
||||
mysql> insert into test.t1 values(11);
|
||||
|
||||
Query OK, 1 row affected (0.15 sec)
|
||||
```
|
||||
|
||||
- Select the current number of rows:
|
||||
|
||||
```
|
||||
mysql> select count(1) from t1;
|
||||
|
||||
@ -197,7 +185,9 @@ mysql> select count(1) from t1;
|
||||
|
||||
1 row in set (0.07 sec)
|
||||
```
|
||||
- The same from the MySQL client pointing to SQL node on server2
|
||||
|
||||
- The same from the MySQL client pointing to SQL node on server2:
|
||||
|
||||
```
|
||||
[root@server2 ~]# mysql
|
||||
|
||||
@ -211,9 +201,11 @@ mysql> select count(1) from test.t1;
|
||||
|
||||
1 row in set (0.08 sec)
|
||||
```
|
||||
|
||||
## Configuring MariaDB MaxScale for connection load balancing of SQL nodes
|
||||
|
||||
Add these sections in maxscale.cnf config file:
|
||||
Add these sections into the maxscale.cnf config file:
|
||||
|
||||
```
|
||||
[Cluster Service]
|
||||
type=service
|
||||
@ -253,13 +245,17 @@ address=162.243.90.81
|
||||
port=3306
|
||||
protocol=MySQLBackend
|
||||
```
|
||||
Assuming MariaDB MaxScale is installed in server1, start it
|
||||
|
||||
Assuming MariaDB MaxScale is installed in server1, start it.
|
||||
|
||||
```
|
||||
[root@server1 ~]# cd /usr/bin
|
||||
|
||||
[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
|
||||
|
||||
@ -300,9 +296,11 @@ Number of connections: 0
|
||||
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:
|
||||
|
||||
```
|
||||
[root@server1 ~]# mysql -h 127.0.0.1 -P 4906 -u test -ptest -e "SHOW STATUS LIKE 'Ndb_cluster_node_id'"
|
||||
|
||||
@ -320,9 +318,11 @@ It’s now possible to run basic tests with the read connection load balancing
|
||||
| Ndb_cluster_node_id | 22 |
|
||||
+---------------------+-------+
|
||||
```
|
||||
|
||||
The MariaDB MaxScale connection load balancing is working.
|
||||
|
||||
(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"
|
||||
|
||||
@ -332,10 +332,13 @@ The MariaDB MaxScale connection load balancing is working.
|
||||
| 1 |
|
||||
+----------+
|
||||
```
|
||||
|
||||
(3) test an insert statement
|
||||
|
||||
```
|
||||
mysql -h 127.0.0.1 -P 4906 -utest -ptest -e "INSERT INTO test.t1 VALUES (19)"
|
||||
```
|
||||
|
||||
(4) test again the select and check the number of rows
|
||||
|
||||
```
|
||||
|
||||
@ -2,19 +2,19 @@
|
||||
|
||||
## Environment & Solution Space
|
||||
|
||||
The object of this tutorial is to have a system that appears to the clients of MariaDB MaxScale as if there is 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.
|
||||
|
||||
Once you have MariaDB MaxScale installed and the database users created, we can create the configuration file for MariaDB MaxScale.
|
||||
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 held in an ini file that is located in the file maxscale.cnf in the directory /etc, if you have installed in the default location then this file is available in /etc/maxscale.cnf. This is not created as part of the installation process and must be manually created. A template file does exist within the /usr/share/maxscale directory that may be use as a basis for your 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.
|
||||
|
||||
A global, maxscale, section is included within every MariaDB MaxScale configuration file; this is used to set the values of various MariaDB MaxScale wide parameters, perhaps the most important of these is the number of threads that MariaDB MaxScale will use to execute the code that forwards requests and handles responses for clients.
|
||||
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 +22,14 @@ threads=4
|
||||
|
||||
```
|
||||
|
||||
The first step is to create a service for our Read/Write Splitter. Create a section in your MariaDB MaxScale configuration file and set the type to service, the section names are the names of the services themselves 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 for we need to use for this configuration is the readwritesplit module, also the services should be provided with the list of servers that will be part of the cluster. The server names given here are actually the names 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 +38,14 @@ router=readwritesplit
|
||||
servers=dbserv1, dbserv2, dbserv3
|
||||
```
|
||||
|
||||
The final step in the service sections 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 may be used. In order to use encrypted passwords a set of keys must be generated that will be used by the encryption and decryption process. To generate the keys use the maxkeys command and pass the name of the secrets file in which the keys are stored.
|
||||
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 the maxpasswd command can be used to generate the encrypted password.
|
||||
Once the keys have been created, use the `maxpasswd` command to generate the encrypted password.
|
||||
|
||||
```
|
||||
maxpasswd plainpassword
|
||||
@ -54,7 +54,7 @@ maxpasswd plainpassword
|
||||
|
||||
```
|
||||
|
||||
The username and password, either encrypted or plain text, are stored in the service section using the user and passwd parameters.
|
||||
The username and password, either encrypted or in plain text, are stored in the service section.
|
||||
|
||||
```
|
||||
[Splitter Service]
|
||||
@ -65,7 +65,7 @@ user=maxscale
|
||||
passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
```
|
||||
|
||||
This completes the definitions required by the service, however listening ports must be associated with the service in order to allow network connections. This is done by creating a series of listener sections. This section again is named for the convenience of the administrator and should be of type listener with an entry labeled service which contains the name of the service to associate the listener with. 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 +73,7 @@ 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]
|
||||
@ -86,7 +86,7 @@ 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.
|
||||
|
||||
The next stage is the configuration is to define the server information. This defines how to connect to each of the servers within the cluster, again a section is created for each server, with the type set to server, the network address and port to connect to and the protocol to use to connect to the server. Currently the protocol module for all database connections in 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 +107,7 @@ port=3306
|
||||
protocol=MySQLBackend
|
||||
```
|
||||
|
||||
In order for MariaDB MaxScale to monitor the servers using the correct monitoring mechanisms a section should be provided that defines the monitor to use and the servers to monitor. Once again a section is created with a symbolic name for the monitor, with the type set to monitor. Parameters are added for the module to use, the list of servers to monitor and the username and password to use when connecting to the the servers with the monitor.
|
||||
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 +118,9 @@ user=maxscale
|
||||
passwd=96F99AA1315BDC3604B006F427DD9484
|
||||
```
|
||||
|
||||
As with the password definition in the server either plain text or encrypted passwords 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 option service which is used by the maxadmin command to connect to MariaDB MaxScale for monitoring and administration purposes. This creates 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,7 +136,8 @@ socket=default
|
||||
|
||||
# Starting MariaDB MaxScale
|
||||
|
||||
Upon completion of the configuration process MariaDB MaxScale is ready to be started for the first time. 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
|
||||
```
|
||||
@ -198,5 +199,5 @@ 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 are available that can alter the criteria used for routing, 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 detail 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