Cleaned up documentation
Fixed spelling mistakes, cleaned up formatting and added missing links.
This commit is contained in:
parent
65b4fe0436
commit
36bf4ee0ce
@ -53,13 +53,24 @@ These tutorials are for specific use cases and module combinations.
|
||||
|
||||
## Routers
|
||||
|
||||
The routing module is the core of a MaxScale service. The router documentation
|
||||
contains all module specific configuration options and detailed explanations
|
||||
of their use.
|
||||
|
||||
- [Read Write Split](Routers/ReadWriteSplit.md)
|
||||
- [Read Connection Router](Routers/ReadConnRoute.md)
|
||||
- [Schemarouter](Routers/SchemaRouter.md)
|
||||
- [Binlogrouter](Routers/Binlogrouter.md)
|
||||
|
||||
There are also two diagnostic routing modules. The CLI is for MaxAdmin and
|
||||
the Debug CLI client for Telnet.
|
||||
|
||||
- [CLI](Routers/CLI.md)
|
||||
- [Debug CLI](Routers/Debug-CLI.md)
|
||||
|
||||
## Filters
|
||||
|
||||
Here are detailed documents about the filters MaxScale offers. They contain configuration guides and example use cases. Before reading these,you should have read the filter tutorial so that you know how they work and how to configure them.
|
||||
Here are detailed documents about the filters MaxScale offers. They contain configuration guides and example use cases. Before reading these, you should have read the filter tutorial so that you know how they work and how to configure them.
|
||||
|
||||
- [Query Log All](Filters/Query-Log-All-Filter.md)
|
||||
- [Regex Filter](Filters/Regex-Filter.md)
|
||||
|
@ -1,10 +1,10 @@
|
||||
Named Server Filter
|
||||
# Named Server Filter
|
||||
|
||||
# Overview
|
||||
## Overview
|
||||
|
||||
The **namedserverfilter** is a filter module for MaxScale which is able to route queries to servers based on regular expression matches.
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
The configuration block for the Named Server filter requires the minimal filter options in it’s section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
|
||||
|
||||
|
@ -107,3 +107,7 @@ filters=ProductsSelectLogger
|
||||
```
|
||||
|
||||
The result of then putting this filter into the service used by the application would be a log file of all select queries that mentioned the table but did not mention the PRODUCT_ID primary key in the predicates for the query.
|
||||
Executing `SELECT * FROM PRODUCTS` would log the following into `/var/logs/qla/SelectProducts`:
|
||||
```
|
||||
07:12:56.324 7/01/2016, SELECT * FROM PRODUCTS
|
||||
```
|
||||
|
@ -1,6 +1,6 @@
|
||||
Regex Filter
|
||||
# Regex Filter
|
||||
|
||||
# Overview
|
||||
## Overview
|
||||
|
||||
The regex filter is a filter module for MaxScale that is able to rewrite query content using regular expression matches and text substitution. It uses the PCRE2 syntax which differs from the POSIX regular expressions used in MaxScale versions prior to 1.3.0.
|
||||
|
||||
@ -8,7 +8,7 @@ For all details about the PCRE2 syntax, please read the [PCRE2 syntax documentat
|
||||
|
||||
Please note that the PCRE2 library uses a different syntax to refer to capture groups in the replacement string. The main difference is the usage of the dollar character instead of the backslash character for references e.g. `$1` instead of `\1`. For more details about the replacement string differences, please read the [Creating a new string with substitutions](http://www.pcre.org/current/doc/html/pcre2api.html#SEC34) chapter in the PCRE2 manual.
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
The configuration block for the Regex filter requires the minimal filter options in it’s section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
|
||||
|
||||
@ -80,7 +80,12 @@ log_file=/tmp/regexfilter.log
|
||||
|
||||
### `log_trace`
|
||||
|
||||
The optional log_trace parameter toggles the logging of non-matching and matching queries with their replacements into the trace log file. This is the preferred method of diagnosing the matching of queries since the trace log can be disabled mid-session if such a need rises.
|
||||
The optional log_trace parameter toggles the logging of non-matching and
|
||||
matching queries with their replacements into the log file on the *info* level.
|
||||
This is the preferred method of diagnosing the matching of queries since the
|
||||
log level can be changed at runtime. For more details about logging levels and
|
||||
session specific logging, please read the [Configuration Guide](../Getting-Started/Configuration-Guide.md#global-settings)
|
||||
and the [MaxAdmin](../Reference/MaxAdmin.md#change-maxscale-logging-options) documentation on changing the logging levels.
|
||||
|
||||
```
|
||||
log_trace=true
|
||||
|
@ -1,10 +1,10 @@
|
||||
TEE Filter
|
||||
# Tee Filter
|
||||
|
||||
# Overview
|
||||
## Overview
|
||||
|
||||
The tee filter is a filter module for MaxScale is a "plumbing" fitting in the 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 MaxScale.
|
||||
|
||||
# Configuration
|
||||
## 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.
|
||||
|
||||
|
@ -1,10 +1,10 @@
|
||||
Top Filter
|
||||
# Top Filter
|
||||
|
||||
# Overview
|
||||
## Overview
|
||||
|
||||
The top filter is a filter module for MaxScale that monitors every SQL statement that passes through the filter. It measures the duration of that statement, the time between the statement being sent and the first result being returned. The top N times are kept, along with the SQL text itself and a list sorted on the execution times of the query is written to a file upon closure of the client session.
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
The configuration block for the TOP filter requires the minimal filter options in it’s section within the maxscale.cnf file, stored in /etc/maxscale.cnf.
|
||||
|
||||
|
@ -31,7 +31,7 @@ implicit databases or use connections with different client settings, you
|
||||
should take great care when using persistent connections.
|
||||
|
||||
Additional information is available in the following document:
|
||||
* [Administration Tutorial](../Tutorials/Administration-Tutorial.md)
|
||||
* [Administration Tutorial](../Tutorials/Administration-Tutorial.md#persistent-connections)
|
||||
|
||||
### Binlog Server
|
||||
|
||||
@ -59,7 +59,8 @@ definition.
|
||||
|
||||
Additional information is available in the following documents:
|
||||
* [Binlogrouter Tutorial](../Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md)
|
||||
* [Upgrading binlogrouter to 1.3.0](../Upgrading/Upgrading-Binlogrouter-to-1.3.0.md)
|
||||
* [Upgrading Binlogrouter to 1.3](../Upgrading/Upgrading-BinlogRouter-To-Maxscale-1.3.md)
|
||||
* [Binlogrouter Documentation](../Routers/Binlogrouter.md)
|
||||
|
||||
### Logging Changes
|
||||
|
||||
|
@ -17,7 +17,7 @@ Binlogrouter is configured with a comma-separated list of key-value pairs. The f
|
||||
### `binlogdir`
|
||||
|
||||
This parameter allows the location that MaxScale uses to store binlog files to be set. If this parameter is not set to a directory name then MaxScale will store the binlog files in the directory /var/cache/maxscale/<Service Name>.
|
||||
In the binlog dir there is also the 'cache' directory that contains data retrieved from the master dureing registration phase and the master.ini file wich contains the configuration of current configured master.
|
||||
In the binlog dir there is also the 'cache' directory that contains data retrieved from the master during registration phase and the master.ini file which contains the configuration of current configured master.
|
||||
|
||||
### `uuid`
|
||||
|
||||
@ -87,7 +87,7 @@ The default value is off, set transaction_safety=on to enable the incomplete tra
|
||||
|
||||
### `send_slave_heartbeat`
|
||||
|
||||
This defines whether (on | off) MaxSclale sends to the slave the heartbeat packet when there are no real binlog events to send. The default value if 'off', no heartbeat event is sent to slave server. If value is 'on' the interval value (requested by the slave during registration) is reported in the diagnostic output and the packect is send after the time interval without any event to send.
|
||||
This defines whether (on | off) MaxScale sends to the slave the heartbeat packet when there are no real binlog events to send. The default value if 'off', no heartbeat event is sent to slave server. If value is 'on' the interval value (requested by the slave during registration) is reported in the diagnostic output and the packet is send after the time interval without any event to send.
|
||||
|
||||
A complete example of a service entry for a binlog router service would be as follows.
|
||||
```
|
||||
|
@ -32,14 +32,14 @@ in the Creating Database Users section of the [MaxScale Tutorial](MaxScale-Tutor
|
||||
|
||||
## Setting up RabbitMQ server
|
||||
|
||||
To set up the RabbitMQ server, follow the instructions for your OS onthe [RabbitMQ website](https://www.rabbitmq.com/download.html).
|
||||
To set up the RabbitMQ server, follow the instructions for your OS on the [RabbitMQ website](https://www.rabbitmq.com/download.html).
|
||||
Useful documentation about access rights can be found on the [Access Control](https://www.rabbitmq.com/access-control.html)
|
||||
page and for UNIX systems the [`rabbitmqctl` manpage](https://www.rabbitmq.com/man/rabbitmqctl.1.man.html)
|
||||
has all the needed commands to manage your installation of RabbitMQ.
|
||||
|
||||
For this tutorial, we will use a RabbitMQ server installed on a CentOS 7 from
|
||||
the RPM packages. Since CentOS 7 doesn't have the RabbitMQ server in the default
|
||||
repositores, we will need two extra repositories: The EPEL repository and the Erlang repository.
|
||||
repositories, we will need two extra repositories: The EPEL repository and the Erlang repository.
|
||||
|
||||
* [EPEL repositories](https://fedoraproject.org/wiki/EPEL)
|
||||
* [Erlang repositories](https://www.erlang-solutions.com/resources/download.html)
|
||||
@ -134,7 +134,7 @@ filters=MQ Filter
|
||||
The `filters` parameters for the services refer to the filters we will be creating next.
|
||||
The Production service will use the Tee filter to duplicate INSERT, UPDATE and DELETE
|
||||
statements to the Archive service. The statements passed to the Archive service will
|
||||
use the MQ Filter to send the canonic versions of the statements to the RabbitMQ broker.
|
||||
use the MQ Filter to send the canonical versions of the statements to the RabbitMQ broker.
|
||||
The Production service will use the `production-1` server and the Archive service will
|
||||
use the `archive-1` server. Both services user the `maxuser` user with the `maxpwd` password.
|
||||
|
||||
@ -158,7 +158,7 @@ The `port` parameter controls which port the listener will listen on and where t
|
||||
connections should be made. The `service` parameter tells which listener belongs to which
|
||||
service.
|
||||
|
||||
After the serivces and their listeners are configured we will configure the two filters we'll use. We
|
||||
After the services and their listeners are configured we will configure the two filters we'll use. We
|
||||
begin with the Tee filter.
|
||||
|
||||
```
|
||||
@ -337,7 +337,7 @@ Listing queues ...
|
||||
```
|
||||
|
||||
If we create a connection on the Production service on port 4000 and execute
|
||||
a set of data modifying statemets we should see an equal number of statements
|
||||
a set of data modifying statements we should see an equal number of statements
|
||||
being sent to the RabbitMQ server:
|
||||
|
||||
```
|
||||
|
@ -6,7 +6,7 @@ In a traditional MySQL replication setup a single master server is created and a
|
||||
Introducing a proxy layer between the master server and the slave servers can improve the situation, by reducing the load on the master to simply serving the proxy layer rather than all of the slaves. The slaves only need to be aware of the proxy layer and not of the real master server. Removing need for the slaves to have knowledge of the master, greatly simplifies the process of replacing a failed master within a replication environment.
|
||||
|
||||
## MariaDB/MySQL as a Binlog Server
|
||||
The most obvious solution to the requirement for a proxy layer within a replication environment is to use a MariaDB or MySQL database instance. The database server is designed to allow this, since a slave server is able to be configured such that it will produce binary logs for updates it has itself received via replication from the master server. This is done with the *log_slave_updates* configuration option of the server. In this case the server is known as an intermediate master, it is simultanously a slave to the real master and a master to the other slaves in the configuration.
|
||||
The most obvious solution to the requirement for a proxy layer within a replication environment is to use a MariaDB or MySQL database instance. The database server is designed to allow this, since a slave server is able to be configured such that it will produce binary logs for updates it has itself received via replication from the master server. This is done with the *log_slave_updates* configuration option of the server. In this case the server is known as an intermediate master, it is simultaneously a slave to the real master and a master to the other slaves in the configuration.
|
||||
|
||||
Using an intermediate master does not, however, solve all the problems and introduces some new ones, due to the way replication is implemented. A slave server reads the binary log data and creates a relay log from that binary log. This log provides a source of SQL statements, which are executed within the slave in order to make the same changes to the databases on the slaves as were made on the master. If the *log_slave_updates* option has been enabled, new binary log entries are created for the statements executed from the relay log.
|
||||
|
||||
@ -60,7 +60,7 @@ The final configuration requirement is the router specific options. The binlog r
|
||||
### binlogdir
|
||||
|
||||
This parameter allows the location that MaxScale uses to store binlog files to be set. If this parameter is not set to a directory name then MaxScale will store the binlog files in the directory */var/cache/maxscale/<Service Name>*.
|
||||
In the binlog dir there is also the 'cache' directory that contains data retrieved from the master during registration phase and the *master.ini* file wich contains the configuration of current configured master.
|
||||
In the binlog dir there is also the 'cache' directory that contains data retrieved from the master during registration phase and the *master.ini* file which contains the configuration of current configured master.
|
||||
|
||||
### uuid
|
||||
|
||||
@ -110,7 +110,7 @@ This defines the value of the heartbeat interval in seconds for the connection t
|
||||
|
||||
### send_slave_heartbeat
|
||||
|
||||
This defines whether (on | off) MaxScale sends to the slave the heartbeat packet when there are no real binlog events to send. The default value if 'off', no heartbeat event is sent to slave server. If value is 'on' the interval value (requested by the slave during registration) is reported in the diagnostic output and the packect is send after the time interval without any event to send.
|
||||
This defines whether (on | off) MaxScale sends to the slave the heartbeat packet when there are no real binlog events to send. The default value if 'off', no heartbeat event is sent to slave server. If value is 'on' the interval value (requested by the slave during registration) is reported in the diagnostic output and the packet is send after the time interval without any event to send.
|
||||
|
||||
### burstsize
|
||||
|
||||
@ -262,7 +262,7 @@ Enabling replication from a master server requires:
|
||||
|
||||
It's possible to specify the desired *MASTER_LOG_FILE* but position must be 4
|
||||
|
||||
The initfile option is nolonger available, filestem option also not available as the stem is automatically set by parsing *MASTER_LOG_FILE*.
|
||||
The initfile option is no longer available, filestem option also not available as the stem is automatically set by parsing *MASTER_LOG_FILE*.
|
||||
|
||||
### Stop/start the replication
|
||||
|
||||
@ -287,11 +287,11 @@ Next step is the master configuration
|
||||
|
||||
MariaDB> CHANGE MASTER TO ...
|
||||
|
||||
A succesful configuration change results in *master.ini* being updated.
|
||||
A successful configuration change results in *master.ini* being updated.
|
||||
|
||||
Any error is reported in the MySQL and in log files
|
||||
|
||||
The upported options are:
|
||||
The supported options are:
|
||||
|
||||
MASTER_HOST
|
||||
MASTER_PORT
|
||||
@ -311,7 +311,7 @@ Examples:
|
||||
MariaDB> CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000003',MASTER_LOG_POS=8888
|
||||
|
||||
This could be applied to current master_host/port or a new one.
|
||||
If there is a master server maintenance and a slave is beeing promoted as master it should be checked that binlog file and position are valid: in case of any error replication stops and errors are reported via *SHOW SLAVE STATUS* and in error logs.
|
||||
If there is a master server maintenance and a slave is being promoted as master it should be checked that binlog file and position are valid: in case of any error replication stops and errors are reported via *SHOW SLAVE STATUS* and in error logs.
|
||||
|
||||
2) Current binlog file is ‘mysql-bin.000099', position 1234
|
||||
|
||||
@ -319,7 +319,7 @@ If there is a master server maintenance and a slave is beeing promoted as master
|
||||
|
||||
This could be applied with current master_host/port or a new one
|
||||
If transaction safety option is on and the current binlog file contains an incomplete transaction it will be truncated to the position where transaction started.
|
||||
In such situation a proper message is reported in MySQL connection and with next START SLAVE binlog file truncation will occurr and MaxScale will request events from the master using the next binlog file at position 4.
|
||||
In such situation a proper message is reported in MySQL connection and with next START SLAVE binlog file truncation will occur and MaxScale will request events from the master using the next binlog file at position 4.
|
||||
|
||||
The above scenario might refer to a master crash/failure:
|
||||
the new server that has just been promoted as master doesn't have last transaction events but it should have the new binlog file (the next in sequence).
|
||||
@ -332,7 +332,7 @@ Check for any error in log files and with
|
||||
|
||||
MariaDB> SHOW SLAVE STATUS;
|
||||
|
||||
In some situations replication state could be *STOPPED* and proper messages are displyed in error logs and in *SHOW SLAVE STATUS*,
|
||||
In some situations replication state could be *STOPPED* and proper messages are displayed in error logs and in *SHOW SLAVE STATUS*,
|
||||
|
||||
In order to resolve any mistake done with *CHANGE MASTER TO MASTER_LOG_FILE / MASTER_LOG_POS*, another administrative command would be helpful.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user