hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed spelling mistakes and cleaned up documentation

Browse Source 
Various documents had minor problems in them that needed cleaning up.
This commit is contained in:
Markus Makela 2015-12-02 11:05:25 +02:00
parent 5410f08578
commit 1b1958ca4f
5 changed files with 35 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
Documentation/Filters/RabbitMQ-Filter.md
View File

@ -1,7 +1,7 @@
#RabbitMQ Filter
## Overview
This filter is designed to extract queries and transform them into a canonical form e.g. `INSERT INTO dabata.table VALUES ("John Doe", "Downtown",100,50.0);` turns into `INSERT INTO dabata.table VALUES ("?", "?",?,?);`. The filter pushes these canonized 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 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.
## Configuration
@ -46,24 +46,22 @@ The RabbitMQ filter has parameters to control which queries are logged based on
Option | Description | Accepted Values | Default |
--------|-------------|-----------------|-------------
logging_trigger | Set the logging level | `all, source, schema, object` | `all` |
logging_strict | Sets whether to trigger when any of the parameters match or only if all parameters match | `true, false` | `false` |
logging_log_all | Log only SELECT, UPDATE, DELETE and INSERT or all possible queries | `true, false` | `true` |
logging_source_user | Comma-separated list of usernames to log | | |
logging_source_host | Comma-separated list of hostnames to log | | |
logging_schema | Comma-separated list of databases | | |
logging_object | Comma-separated list of database objects |
hostname | The server hostname where the messages are sent | | `localhost` |
port | Port to send the messages to | | `5672` |
username | Server login username | | `guest` |
password | Server login password | | `guest` |
vhost | The virtual host location on the server, where the messages are sent | | `/` |
exchange | The name of the exchange | | `default_exchange` |
exchange_type | The type of the exchange | `direct, fanout, topic, headers` | `direct` |
key | The routing key used when sending messages to the exchange | | `key` |
queue | The queue that will be bound to the used exchange | | |
ssl_CA_cert | Path to the CA certificate in PEM format | | |
ssl_client_cert | Path to the client cerificate in PEM format | | |
logging_trigger | Set the logging level | `all, source, schema, object` | `all` |
logging_strict | Sets whether to trigger when any of the parameters match or only if all parameters match | `true, false` | `false` |
logging_log_all | Log only SELECT, UPDATE, DELETE and INSERT or all possible queries | `true, false` | `true` |
logging_source_user | Comma-separated list of usernames to log | | |
logging_source_host | Comma-separated list of hostnames to log | | |
logging_schema | Comma-separated list of databases | | |
logging_object | Comma-separated list of database objects |
hostname | The server hostname where the messages are sent | | `localhost` |
port | Port to send the messages to | | `5672` |
username | Server login username | | `guest` |
password | Server login password | | `guest` |
vhost | The virtual host location on the server, where the messages are sent | | `/` |
exchange | The name of the exchange | | `default_exchange` |
exchange_type | The type of the exchange | `direct, fanout, topic, headers` | `direct` |
key | The routing key used when sending messages to the exchange | | `key` |
queue | The queue that will be bound to the used exchange | | |
ssl_CA_cert | Path to the CA certificate in PEM format | | |
ssl_client_cert | Path to the client certificate in PEM format | | |
ssl_client_key | Path to the client public key in PEM format | | |

2
Documentation/Release-Notes/MaxScale-1.0-Release-Notes.md
View File

@ -14,7 +14,7 @@ The MaxScale monitor module for Master/Slave replication is now able to correctl
### Support For Prepared Statements
Prepared statements are now correctly recognised by MaxScale, with the prepare stage being sent to all the eligible servers that could eventually run the statement. Statements are then execute on a single server.
Prepared statements are now correctly recognized by MaxScale, with the prepare stage being sent to all the eligible servers that could eventually run the statement. Statements are then execute on a single server.
### Slave Failure Resilience

4
Documentation/Release-Notes/MaxScale-1.2.0-Release-Notes.md
View File

@ -5,7 +5,7 @@
This document details the changes in version 1.2 since the release of the 1.1.1 GA Release of the MaxScale product.
###***PLEASE NOTICE: MaxScale installation directories have changed in this version***
The 1.2 version of MaxScale differs from previos versions in its installation layout. Please take great care when upgrading MaxScale from previous versions to version 1.2. An automatic upgrade will not work due to the severe changes in the installation layout.
The 1.2 version of MaxScale differs from previous versions in its installation layout. Please take great care when upgrading MaxScale from previous versions to version 1.2. An automatic upgrade will not work due to the severe changes in the installation layout.
## New Features
@ -31,7 +31,7 @@ MaxScale now supports SSL/TLS encrypted connections to MaxScale.
Now you can configure MaxScale monitor module to automatically launch a script when it detects change in the state of a backend server. The script can be any customer script defined by you to take diagnostic or reporting action. With this you can easily customize MaxScale's behavior.
### Lsyncd configuration guide
A new tutorial has beed added which helps you keep MaxScale's configuration files in sync across multiple hosts. This allows for easier HA setups with MaxScale and guarantees up-to-date configuration files on all nodes. The tutorial can be found [here](../Reference/MaxScale-HA-with-lsyncd.md).
A new tutorial has been added which helps you keep MaxScale's configuration files in sync across multiple hosts. This allows for easier HA setups with MaxScale and guarantees up-to-date configuration files on all nodes. The tutorial can be found [here](../Reference/MaxScale-HA-with-lsyncd.md).
## Bug fixes

2
Documentation/Tutorials/Nagios-Plugins.md
View File

@ -64,7 +64,7 @@ Assuming Nagios installed on a separated server and the plugins are in /usr/lib6
* Copy New commands and server1 definition (./nagios/plugins/maxscale_commands.cfg, server1.cfg) to /etc/nagios/objects/ on Nagios Server
* Edit /etc/nagios/nagios.cfg on Nagios Server
and add (just after localhost.cfg or commnads.cfg)
and add (just after localhost.cfg or commands.cfg)
```
cfg_file=/etc/nagios/objects/maxscale_commands.cfg

24
Documentation/Tutorials/Replication-Proxy-Binlog-Router-Tutorial.md
View File

@ -56,7 +56,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 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
@ -106,7 +106,7 @@ This defines the value of the heartbeat interval in seconds for the connection t
### 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.
### burstsize
@ -117,7 +117,7 @@ This parameter is used to define the maximum amount of data that will be sent to
This parameter is used to enable/disable incomplete transactions detection in binlog router.
When MaxScale starts an error message may appear if current binlog file is corrupted or an incomplete transaction is found.
During normal operations binlog events are not distributed to the slaves until a COMMIT is seen.
The default value is on, set transaction_safety=off to completly disable the incomplete transactions detection.
The default value is on, set transaction_safety=off to completely disable the incomplete transactions detection.
A complete example of a service entry for a binlog router service would be as follows.
```
@ -238,7 +238,7 @@ Binlog Router currently does not work for MySQL 5.5 due to missing @@global.binl
# Master server setup/change
In MaxScale ini file the server section for master is no longer required, same for servers=master_server in the service section. The mastet server setup is currently managed via CHANGE MASTER TO command issued in MySQL client connection to MaxScale or by providing a proper master.ini file in the binlogdir.
In MaxScale ini file the server section for master is no longer required, same for servers=master_server in the service section. The master server setup is currently managed via CHANGE MASTER TO command issued in MySQL client connection to MaxScale or by providing a proper master.ini file in the binlogdir.
If MaxScale starts without master.ini there is no replication configured to any master and slaves cannot register to the router: the binlog router could be later configured via CHANGE MASTER TO and the master.ini file will be written.
@ -257,7 +257,7 @@ CHANGE MASTER TO MASTER_HOST=‘$master_server’, MASTER_PORT=$master_port, MAS
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
@ -282,11 +282,11 @@ Next step is the master configuration
MariaDB> CHANGE MASTER TO ...
A succesfull 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
@ -306,7 +306,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
@ -314,12 +314,12 @@ 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).
Truncating the previous MaxScale binlog is safe as that incomplete transaction is lost.
It should be checked that current master or new one has the new bnlog file, in case of any error replication stops and errors are reported via SHOW SLAVE STATUS and in error logs.
It should be checked that current master or new one has the new binlog file, in case of any error replication stops and errors are reported via SHOW SLAVE STATUS and in error logs.
MariaDB> START SLAVE;
@ -327,13 +327,13 @@ 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.
MariaDB> RESET SLAVE;
This command removes master.ini file, blanks all master configuration in memory and sets binlog router in unconfigured state: a CHANHE MASTER TO command should be issued for the new configuration.
This command removes master.ini file, blanks all master configuration in memory and sets binlog router in unconfigured state: a CHANGE MASTER TO command should be issued for the new configuration.
Note: existing binlog files are not touched by this command.