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

Massimiliano pinto doc update 2.1 (#125)

Browse Source 
* Update Nagios-Plugins.md

* Update MM-Monitor.md

* Update Nagios-Plugins.md

* Update Nagios-Plugins.md

* Update Galera-Cluster-Connection-Routing-Tutorial.md

* Update Galera-Cluster-Connection-Routing-Tutorial.md

* Update RabbitMQ-Setup-And-MaxScale-Integration.md

* Update MaxScale-Tutorial.md

* Update Cache.md

* Update Transaction-Performance-Monitoring-Filter.md

* Update RabbitMQ-Consumer-Client.md

* Update Building-MaxScale-from-Source-Code.md

* Update MariaDB-MaxScale-Installation-Guide.md

* Update Install-MariaDB-MaxScale-Using-a-Tarball.md

* Update RabbitMQ-Setup-And-MaxScale-Integration.md

* Update RabbitMQ-Consumer-Client.md
This commit is contained in:
MassimilianoPinto
2017-04-20 13:36:13 +02:00
committed by GitHub
parent 33b809eec1
commit 695ba19965
11 changed files with 459 additions and 154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

116
Documentation/Tutorials/Galera-Cluster-Connection-Routing-Tutorial.md
View File

@ -2,33 +2,53 @@
# Environment & Solution Space
The object of this tutorial is to have a system that has two ports available, one for write connections to the database cluster and the other for read connections to the database.
The object of this tutorial is to have a system that has two ports available, one for
write connections to the database cluster and the other for read connections to the database.
## Setting up MariaDB MaxScale
The first part of this tutorial is covered in [MariaDB MaxScale Tutorial](MaxScale-Tutorial.md). Please read it and follow the instructions for setting up MariaDB MaxScale with the type of cluster you want to use.
The first part of this tutorial is covered in [MariaDB MaxScale Tutorial](MaxScale-Tutorial.md).
Please read it and follow the instructions for setting up MariaDB MaxScale with the
type of cluster you want to use.
Once you have MariaDB MaxScale installed and the database users created, we can create the configuration file for MariaDB MaxScale.
Once you have MariaDB MaxScale installed and the database users created, we can create
the configuration file for MariaDB MaxScale.
## 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 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.
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, 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.
```
[maxscale]
threads=4
```
Since we are using Galera Cluster and connection routing we want a single to which the client application can connect; MariaDB MaxScale will then route connections to this port onwards to the various nodes within the Galera Cluster. To achieve this within MariaDB MaxScale we need to define a service in the ini file. Create a section for each in your MariaDB MaxScale configuration file and set the type to service, the section name is the names of the service and should be meaningful to the administrator. Names may contain whitespace.
Since we are using Galera Cluster and connection routing we want a single to which
the client application can connect; MariaDB MaxScale will then route connections to
this port onwards to the various nodes within the Galera Cluster. To achieve this
within MariaDB MaxScale we need to define a service in the ini file. Create a section
for each in your MariaDB MaxScale configuration file and set the type to service,
the section name is the names of the service and should be meaningful to
the administrator. Names may contain whitespace.
```
[Galera Service]
type=service
```
The router for this section the readconnroute module, also the service 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 for this section the readconnroute module, also the service 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.
```
[Galera Service]
@ -37,7 +57,12 @@ router=readconnroute
servers=dbserv1, dbserv2, dbserv3
```
In order to instruct the router to which servers it should route we must add router options to the service. The router options are compared to the status that the monitor collects from the servers and used to restrict the eligible set of servers to which that service may route. In our case we use the option that restricts us to servers that are fully functional members of the Galera cluster which are able to support SQL operations on the cluster. To achieve this we use the router option synced.
In order to instruct the router to which servers it should route we must add router
options to the service. The router options are compared to the status that the monitor
collects from the servers and used to restrict the eligible set of servers to which that
service may route. In our case we use the option that restricts us to servers that are
fully functional members of the Galera cluster which are able to support SQL operations
on the cluster. To achieve this we use the router option synced.
```
[Galera Service]
@ -47,14 +72,20 @@ router_options=synced
servers=dbserv1, dbserv2, dbserv3
```
The final step in the service section is to add the username and password that will be used to populate the user data from the database cluster. There are two options for representing the password, either plain text or encrypted passwords 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 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.
```
% 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 the maxpasswd command can be used to generate
the encrypted password.
```
% maxpasswd plainpassword
@ -62,7 +93,8 @@ Once the keys have been created the maxpasswd command can be used to generate th
%
```
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 plain text, are stored in the service
section using the user and passwd parameters.
```
[Galera Service]
@ -74,7 +106,12 @@ user=maxscale
passwd=96F99AA1315BDC3604B006F427DD9484
```
This completes the definitions required by the service, however listening ports must be associated with a service in order to allow network connections. This is done by creating a series of listener sections. These sections again are 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. Each service may have multiple listeners.
This completes the definitions required by the service, however listening ports must
be associated with a service in order to allow network connections. This is done by
creating a series of listener sections. These sections again are 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.
Each service may have multiple listeners.
```
[Galera Listener]
@ -82,7 +119,10 @@ type=listener
service=Galera 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.
```
[Galera Listener]
@ -93,9 +133,15 @@ port=4306
socket=/tmp/DB.Cluster
```
An address parameter may be given if the listener is required to bind to a particular network address when using hosts with multiple network addresses. The default behavior is to listen on all network interfaces.
An address parameter may be given if the listener is required to bind to a particular
network address when using hosts with multiple network addresses.
The default behavior is to listen on all network interfaces.
The next stage 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 for all database connections in MySQLBackend.
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 for
all database connections in MySQLBackend.
```
[dbserv1]
@ -117,7 +163,12 @@ 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.
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 servers with the monitor.
```
[Galera Monitor]
@ -128,9 +179,12 @@ user=maxscale
passwd=96F99AA1315BDC3604B006F427DD9484
```
As with the password definition in the server either plain text or encrypted passwords may be used.
As with the password definition in the server either plain text or encrypted
passwords 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 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.
```
[CLI]
@ -145,7 +199,9 @@ 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 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.
```
% maxscale
@ -157,7 +213,10 @@ or
% service maxscale start
```
Check the error log in /var/log/maxscale to see if any errors are detected in the configuration file and to confirm MariaDB MaxScale has been started. Also the maxadmin command may be used to confirm that MariaDB MaxScale is running and the services, listeners etc have been correctly configured.
Check the error log in /var/log/maxscale to see if any errors are detected in
the configuration file and to confirm MariaDB MaxScale has been started.
Also the maxadmin command may be used to confirm that MariaDB MaxScale is running
and the services, listeners etc have been correctly configured.
```
% maxadmin list services
@ -180,9 +239,14 @@ dbserv3 | 192.168.2.3 | 3306 | 0 | Running, Synced, Sl
-------------------+-----------------+-------+-------------+--------------------
```
A Galera Cluster is a multi-master clustering technology, however the monitor is able to impose false notions of master and slave roles within a Galera Cluster in order to facilitate the use of Galera as if it were a standard MySQL Replication setup. This is merely an internal MariaDB MaxScale convenience and has no impact on the behavior of the cluster.
A Galera Cluster is a multi-master clustering technology, however the monitor is able
to impose false notions of master and slave roles within a Galera Cluster in order to
facilitate the use of Galera as if it were a standard MySQL Replication setup.
This is merely an internal MariaDB MaxScale convenience and has no impact on the behavior of the cluster.
You can control which Galera node is the master server by using the _priority_ mechanism of the Galera Monitor module. For more details, read the [Galera Monitor](../Monitors/Galera-Monitor.md) documentation.
You can control which Galera node is the master server by using the _priority_
mechanism of the Galera Monitor module. For more details,
read the [Galera Monitor](../Monitors/Galera-Monitor.md) documentation.
```
% maxadmin list listeners
@ -197,4 +261,10 @@ 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, such as 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"](../Reference/MaxAdmin.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 are
available that can alter the criteria used for routing, such as 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"](../Reference/MaxAdmin.md).

81
Documentation/Tutorials/MaxScale-Tutorial.md
View File

@ -1,10 +1,21 @@
# Setting up MariaDB MaxScale
This document is designed as a quick introduction to setting up MariaDB MaxScale in an environment in which you have either a MySQL Master-Slave replication cluster with one master and multiple slave servers or a multi-node Galera cluster. The process of setting and configuring MariaDB MaxScale will be covered within this document.
This document is designed as a quick introduction to setting up MariaDB MaxScale
in an environment in which you have either a MySQL Master-Slave replication cluster
with one master and multiple slave servers or a multi-node Galera cluster.
The process of setting and configuring MariaDB MaxScale will be covered within this document.
The installation and configuration of the MySQL Replication or the Galera cluster will not be covered nor will any discussion of installation management tools to handle automated or semi-automated failover of the replication cluster. The [Setting Up Replication](https://mariadb.com/kb/en/mariadb/setting-up-replication/) article on the MariaDB knowledgebase can help you get started with replication clusters and the [Getting Started With Mariadb Galera Cluster](https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/) article will help you set up a Galera cluster.
The installation and configuration of the MySQL Replication or the Galera cluster
will not be covered nor will any discussion of installation management tools
to handle automated or semi-automated failover of the replication cluster.
The [Setting Up Replication](https://mariadb.com/kb/en/mariadb/setting-up-replication/)
article on the MariaDB knowledgebase can help you get started with replication clusters
and the [Getting Started With Mariadb Galera Cluster](https://mariadb.com/kb/en/mariadb/getting-started-with-mariadb-galera-cluster/) article will help you set up a Galera cluster.
This tutorial will assume the user is running from one of the binary distributions available and has installed this in the default location. Building from source code in GitHub is covered in the [Building from Source](../Getting-Started/Building-MaxScale-from-Source-Code.md) document.
This tutorial will assume the user is running from one of the binary distributions
available and has installed this in the default location.
Building from source code in GitHub is covered in the
[Building from Source](../Getting-Started/Building-MaxScale-from-Source-Code.md) document.
## Process
@ -18,19 +29,33 @@ The steps involved in setting up MariaDB MaxScale are:
## Installation
The precise installation process will vary from one distribution to another details of what to do with the RPM and DEB packages can be found on the download site when you select the distribution you are downloading from. The process involves setting up your package manager to include the MariaDB repositories and then running the package manager for your distribution (usually yum or apt-get).
The precise installation process will vary from one distribution to another
details of what to do with the RPM and DEB packages can be found on the download
site when you select the distribution you are downloading from.
The process involves setting up your package manager to include the MariaDB repositories
and then running the package manager for your distribution (usually yum or apt-get).
Upon successful completion of the installation command you will have MariaDB MaxScale installed and ready to be run but without a configuration. You must create a configuration file before you first run MariaDB MaxScale which is covered in a later section.
Upon successful completion of the installation command you will have MariaDB MaxScale
installed and ready to be run but without a configuration.
You must create a configuration file before you first run MariaDB MaxScale
which is covered in a later section.
## Creating Database Users
MariaDB MaxScale needs to connect to the backend databases and run queries for two reasons; one to determine the current state of the database and the other to retrieve the user information for the database cluster. The first pair of credentials will be used by the monitor modules and the second is used by MariaDB MaxScale itself. This may be done either using two separate usernames or with a single user.
MariaDB MaxScale needs to connect to the backend databases and run queries for
two reasons; one to determine the current state of the database and the other to
retrieve the user information for the database cluster. The first pair of
credentials will be used by the monitor modules and the second is used by
MariaDB MaxScale itself. This may be done either using two separate usernames
or with a single user.
The first user required must be able to select data from the table mysql.user, to create this user follow the steps below.
The first user required must be able to select data from the table mysql.user,
to create this user follow the steps below.
1. Connect to the current master server in your replication tree as the root user
2. Create the user, substituting the username, password and host on which maxscale runs within your environment
2. Create the user, substituting the username, password and host on which maxscale
runs within your environment
```
MariaDB [(none)]> create user '*username*'@'*maxscalehost*' identified by '*password*';
@ -42,7 +67,9 @@ MariaDB [(none)]> grant SELECT on mysql.user to '*username*'@'*maxscalehost*';
**Query OK, 0 rows affected (0.03 sec)**
```
Additionally, `SELECT` privileges on the `mysql.db` and `mysql.tables_priv` tables and `SHOW DATABASES` privileges are required in order to load databases name and grants suitable for database name authorization.
Additionally, `SELECT` privileges on the `mysql.db` and `mysql.tables_priv` tables
and `SHOW DATABASES` privileges are required in order to load databases name
and grants suitable for database name authorization.
```
MariaDB [(none)]> GRANT SELECT ON mysql.db TO 'username'@'maxscalehost';
@ -56,7 +83,11 @@ MariaDB [(none)]> GRANT SHOW DATABASES ON *.* TO 'username'@'maxscalehost';
**Query OK, 0 rows affected (0.00 sec)**
```
The second user is used to monitored the state of the cluster. This user, which may be the same username as the first, requires permissions to access the various sources of monitoring data. In order to monitor a replication cluster this user must be granted the role REPLICATION CLIENT. This is only required by the MySQL monitor and Multi-Master monitor modules.
The second user is used to monitored the state of the cluster. This user, which may be
the same username as the first, requires permissions to access the various sources
of monitoring data. In order to monitor a replication cluster this user must be granted
the role REPLICATION CLIENT. This is only required by the MySQL monitor
and Multi-Master monitor modules.
```
MariaDB [(none)]> grant REPLICATION CLIENT on *.* to '*username*'@'*maxscalehost*';
@ -64,17 +95,32 @@ MariaDB [(none)]> grant REPLICATION CLIENT on *.* to '*username*'@'*maxscalehost
**Query OK, 0 rows affected (0.00 sec)**
```
If you wish to use two different usernames for the two different roles of monitoring and collecting user information then create a different username using the first two steps from above.
If you wish to use two different usernames for the two different roles of monitoring
and collecting user information then create a different username using the first
two steps from above.
## Creating additional grants for users
Because MariaDB MaxScale sits between the clients and the backend databases, the backend databases will see all clients as if they were connecting from MariaDB MaxScale's address. This usually requires users to create additional grants for MariaDB MaxScale's hostname. The best way to describe this process is with an example.
Because MariaDB MaxScale sits between the clients and the backend databases,
the backend databases will see all clients as if they were connecting from
MariaDB MaxScale's address.
This usually requires users to create additional grants for MariaDB MaxScale's hostname.
The best way to describe this process is with an example.
User `'jdoe'@'192.168.0.200` has the following grant on the cluster: `GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'192.168.0.200'`. When the user connects directly to the server it will see it as `'jdoe'@'192.168.0.200` connecting to the server and it will match the grant for `'jdoe'@'192.168.0.200`.
User `'jdoe'@'192.168.0.200` has the following grant on the cluster:
`GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'192.168.0.200'`.
When the user connects directly to the server it will see it as
`'jdoe'@'192.168.0.200` connecting to the server and it will match
the grant for `'jdoe'@'192.168.0.200`.
If MariaDB MaxScale is at the address `192.168.0.101` and the user `jdoe` connects to this MariaDB MaxScale, the backend server will see the connection as `'jdoe'@'192.168.0.101'`. Since the backend server has no grants for `'jdoe'@'192.168.0.101'`, the connection from MariaDB MaxScale to the server will be refused.
If MariaDB MaxScale is at the address `192.168.0.101` and the user `jdoe`
connects to this MariaDB MaxScale, the backend server will see the connection as
`'jdoe'@'192.168.0.101'`. Since the backend server has no grants for
`'jdoe'@'192.168.0.101'`, the connection from MariaDB MaxScale to the server
will be refused.
We can fix this by either creating a matching grant for user `jdoe` from the MariaDB MaxScale address or by using a wildcard to cover both addresses.
We can fix this by either creating a matching grant for user `jdoe` from
the MariaDB MaxScale address or by using a wildcard to cover both addresses.
The quickest way to do this is by doing a SHOW GRANTS query:
```
@ -95,7 +141,10 @@ MariaDB [(none)]> GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'192.168
Query OK, 0 rows affected (0.00 sec)
```
The other option is to use a wildcard grant like `GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'%'`. This is more convenient but also less secure than having specific grants for both the client's address and MariaDB MaxScale's address.
The other option is to use a wildcard grant like
`GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'jdoe'@'%'`.
This is more convenient but also less secure than having specific grants
for both the client's address and MariaDB MaxScale's address.
## Creating the configuration file

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

@ -1,49 +1,40 @@
# MariaDB MaxScale Nagios plugins, for Nagios 3.5.1
Massimiliano Pinto
Last Updated: 12th March 2015
## Document History
<table>
<tr>
<td>Date</td>
<td>Change</td>
<td>Who</td>
</tr>
<tr>
<td>10th March 2015</td>
<td>Initial version</td>
<td>Massimiliano Pinto</td>
</tr>
<tr>
<td>20th May 2016</td>
<td>MaxAdmin uses UNIX socket only</td>
<td>Massimiliano Pinto</td>
</tr>
</table>
# Introduction
Nagios® Core™ is an Open Source system and network monitoring application. It watches hosts and services that you specify, alerting you when things go bad and when they get better.
Nagios plugins are compiled executables or scripts (Perl scripts, shell scripts, etc.) that can be run from a command line to check the status or a host or service. Nagios uses the results from plugins to determine the current status of hosts and services on your network.
Nagios core executes a plugin whenever there is a need to check the status of a service or host.
Nagios® Core™ is an Open Source system and network monitoring application.
It watches hosts and services that you specify, alerting you when things go bad
and when they get better.
Nagios plugins are compiled executables or scripts (Perl scripts, shell scripts, etc.)
that can be run from a command line to check the status or a host or service.
Nagios uses the results from plugins to determine the current status of hosts and
services on your network.
Nagios core executes a plugin whenever there is a need to check the status
of a service or host.
While MariaDB MaxScale resources and status can be monitored via CLI using maxadmin commands, Nagios Plugin provides an automated way for system administration and database administrators to monitor MariaDB MaxScale. The diagram below provides view of how Nagios and MariaDB MaxScale interact.
While MariaDB MaxScale resources and status can be monitored via CLI using
maxadmin commands, Nagios Plugin provides an automated way for system administration
and database administrators to monitor MariaDB MaxScale.
The diagram below provides view of how Nagios and MariaDB MaxScale interact.
![Nagios and MariaDB MaxScale interaction](images/HowMaxScaleWorksWithNagios.png)
There are three Nagios plugin scripts that MariaDB MaxScale provides.
1. check_maxscale_threads.pl: This command provides you the status of current running threads and events in the queue on MariaDB MaxScale Server. The Performance data associated with this command current and historic wait time for threads and events
1. check_maxscale_threads.pl: This command provides you the status of current running
threads and events in the queue on MariaDB MaxScale Server.
The Performance data associated with this command current and historic wait time for threads and events
2. check_maxscale_resources.pl: This command provides you status of various resources on MariaDB MaxScale server. The Performance data associated provides details on respective resources.
2. check_maxscale_resources.pl: This command provides you status of various resources
on MariaDB MaxScale server. The Performance data associated provides
details on respective resources.
Current resources are: modules, services, listeners, servers, sessions, filters.
3. check_maxscale_monitor.pl: This command provides you status of the configured monitor modules on MariaDB MaxScale server.
3. check_maxscale_monitor.pl: This command provides you status of the configured
monitor modules on MariaDB MaxScale server.
In order to use these scripts on your Nagios Server, you need to copy them from the MariaDB MaxScale binary package or download them from source tree on GitHub.
In order to use these scripts on your Nagios Server, you need to copy them
from the MariaDB MaxScale binary package or download them from source tree on GitHub.
# MariaDB MaxScale Nagios Plugin Requirements
@ -65,10 +56,13 @@ socket=default
## Prepare Nagios configuration files.
Assuming Nagios installed on a separated server and the plugins are in /usr/lib64/nagios/plugins and configuration files are in /etc/nagios:
Assuming Nagios installed on a separated server and the plugins are
in /usr/lib64/nagios/plugins and configuration files are in /etc/nagios:
* Copy MariaDB MaxScale plugin scripts (./nagios/plugins/check_maxscale_*.pl) to /usr/lib64/nagios/plugins on Nagios Server
* Copy New commands and server1 definition (./nagios/plugins/maxscale_commands.cfg, server1.cfg) to /etc/nagios/objects/ on Nagios Server
* Copy MariaDB MaxScale plugin scripts (./nagios/plugins/check_maxscale_*.pl)
to /usr/lib64/nagios/plugins on Nagios Server
* 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 commands.cfg)
@ -87,14 +81,18 @@ cfg_file=/etc/nagios/objects/server1.cfg
- The default maxadmin executable path is /usr/bin/maxadmin can be changed by -m option
- default maxadmin socket (/tmp/maxadmin.sock) can be changed with -S option
- maxadmin executable is no longer required to be copied in Nagios server.
- the UNIX user in ssh connection should be also admin user for MariaDB MaxScale admin. First time access or no configured users means the "root" user is the only one that can access MariaDB MaxScale admin interface via UNIX socket.
- the UNIX user in ssh connection should be also admin user for MariaDB MaxScale admin.
First time access or no configured users means the "root" user is the only one that can access
MariaDB MaxScale admin interface via UNIX socket.
Test maxadmin with proper user in maxscale server and later via SSH.
Those checks are strongly recommended before using Nagios scripts.
For additional information about Maxadmin and MariaDB MaxScale administrative interface please refer to [MaxAdmin Utility](../Reference/MaxAdmin.md)
For additional information about Maxadmin and MariaDB MaxScale administrative interface
please refer to [MaxAdmin Utility](../Reference/MaxAdmin.md)
This example shows configuration that needs to be done on Nagios server in order to communicate to MariaDB MaxScale server that is running on host server1.
This example shows configuration that needs to be done on Nagios server in order to
communicate to MariaDB MaxScale server that is running on host server1.
In this example we are using the check_maxscale_resource as the check command
```
@ -109,7 +107,8 @@ In this example we are using the check_maxscale_resource as the check command
```
### Check new running monitors
* Restart Nagios and check new monitors are running in HTTP Interface "Current Status -> Services" on Nagios Server
* Restart Nagios and check new monitors are running in HTTP Interface
"Current Status -> Services" on Nagios Server
* Look for any errors in /var/log/nagios/nagios.log or nagios.debug on Nagios Server
# Nagios Plugin command line usage
@ -127,7 +126,8 @@ In this example we are using the check_maxscale_resource as the check command
-u <user> = username to connect to maxscale host via SSH (same user is used for maxadmin authentication)
-i <identity> = identity file to use for <user> at <host>
-m <maxadmin> = /path/to/maxadmin
-S <socket> = UNIX socket path between maxadmin and maxscale (default is /tmp/maxadmin.sock)
-S <socket> = UNIX socket path between maxadmin and maxscale (default
is /tmp/maxadmin.sock)
(2) ./check_maxscale_resources.pl -h
@ -166,7 +166,10 @@ Example for 'services'
```
#./check_maxscale_resources.pl -r resources
OK: 7 services found | services1=RW_Router;readwritesplit;1;1 services2=RW_Split;readwritesplit;1;1 services3=Test Service;readconnroute;1;1 services4=Master Service;readconnroute;2;2 services5=Debug Service;debugcli;1;1 services6=CLI;cli;2;145 services7=MaxInfo;maxinfo;2;2
OK: 7 services found | services1=RW_Router;readwritesplit;1;1 services2=RW_Split;
readwritesplit;1;1 services3=Test Service;readconnroute;1;1 services4=Master Service;
readconnroute;2;2 services5=Debug Service;debugcli;1;1 services6=CLI;cli;2;145
services7=MaxInfo;maxinfo;2;2
```
Returns OK and the number of services

54
Documentation/Tutorials/RabbitMQ-Setup-And-MaxScale-Integration.md
View File

@ -1,34 +1,42 @@
# Rabbit MQ setup and MariaDB MaxScale Integration
## Introduction
A step by step guide helps installing a RabbitMQ server and testing it before MariaDB MaxScale integration.
A step by step guide helps installing a RabbitMQ server and testing it before
MariaDB MaxScale integration.
New plugin filter and a message consumer application need to be compiled and linked with an external C library, RabbitMQ-c, that provides AMQP protocol integration.
New plugin filter and a message consumer application need to be compiled and
linked with an external C library, RabbitMQ-c, that provides AMQP protocol integration.
Custom configuration, with TCP/IP and Queue parameters, is also detailed here.
The software install setup provides RPM and DEB packaging and traditional compilation steps.
## Step 1 - Get the RabbitMQ binaries
On Centos 6.5 using fedora / RHEL rpm get the rpm from [http://www.rabbitmq.com/](http://www.rabbitmq.com/ "RabbitMQ")
On Centos 6.5 using fedora / RHEL rpm get the rpm from
[http://www.rabbitmq.com/](http://www.rabbitmq.com/ "RabbitMQ")
rabbitmq-server-3.3.4-1.noarch.rpm
Please note, before installing RabbitMQ, you must install Erlang.
Example:
```
yum install erlang
Package erlang-R14B-04.3.el6.x86_64 already installed and latest version
```
## Step 2 - Install and Start the Server
Install the packages using your distribution's package manager and start the server:
```
yum install rabbitmq-server-3.3.4-1.noarch.rpm
systemctl start rabbitmq-server.service
To configure your RabbitMQ server, please refer to the RabbitMQ website: [http://www.rabbitmq.com/](http://www.rabbitmq.com/ RabbitMQ website).
```
To configure your RabbitMQ server, please refer to the RabbitMQ website:
[http://www.rabbitmq.com/](http://www.rabbitmq.com/ RabbitMQ website).
rabbitmqctl is a command line tool for managing a RabbitMQ broker. It performs all actions by connecting to one of the broker's nodes.
rabbitmqctl is a command line tool for managing a RabbitMQ broker.
It performs all actions by connecting to one of the broker's nodes.
```
rabbitmqctl list_queues
@ -87,12 +95,14 @@ make
make install
```
Please note, this will install the packages to /usr. If you do not wish to install them to this location, provide a different value for the CMAKE_INSTALL_PREFIX variable.
Please note, this will install the packages to /usr. If you do not wish to install
them to this location, provide a different value for the CMAKE_INSTALL_PREFIX variable.
### Setup using the EPEL repository
Check how to configure your distribution for the EPEL repository: [https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL EPEL)
Check how to configure your distribution for the EPEL repository:
[https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL EPEL)
Configure your repositories and install the software:
@ -114,7 +124,9 @@ yum install rabbitmq-server
### Basic tests with library
The required library librabbitmq-c is now installed and we continue with basic operations with amqp_* tools, located in the examples/ folder of the build directory, testing client server interaction.
The required library librabbitmq-c is now installed and we continue with basic
operations with amqp_* tools, located in the examples/ folder of the build directory,
testing client server interaction.
Please note, those example applications may not be included in the RPM library packages.
@ -185,7 +197,8 @@ port=5672
logging_trigger=all
```
Logging triggers define whether to log all or a subset of the incoming queries using these options:
Logging triggers define whether to log all or a subset of the incoming queries
using these options:
```
# log only some elements or all
@ -230,9 +243,13 @@ anything targeting my1 table is logged
SELECT NOW(), SELECT MD5(“xyz)” are not logged
```
Please note that if we want to log only the user ‘maxtest’ accessing the schema ‘test’ with target ‘my1’ the option logging_strict must be set to TRUE and if we want to include those selects without schema name the option logging_log_all must be set to TRUE.
Please note that if we want to log only the user ‘maxtest’ accessing the
schema ‘test’ with target ‘my1’ the option logging_strict must be set
to TRUE and if we want to include those selects without schema name the
option logging_log_all must be set to TRUE.
The mqfilter logs into the MariaDB MaxScale TRACE log information about the matched logging triggers and the message delivering:
The mqfilter logs into the MariaDB MaxScale TRACE log information about
the matched logging triggers and the message delivering:
```
2014 09/03 06:22:04 Trigger is TRG_SOURCE: user: testuser = testuser
@ -288,7 +305,9 @@ and finally we can launch it:
# ./consumer
```
If the consumer.cnf file is not in the same directory as the binary file is, you can provide the location of the folder that it is in by passing it the -c flag followed by the path:
If the consumer.cnf file is not in the same directory as the binary file is,
you can provide the location of the folder that it is in by passing
it the -c flag followed by the path:
```
# ./consumer -c path/to/file
@ -298,7 +317,8 @@ and start MariaDB MaxScale as well
## Step 5 - Test the filter and check collected data
Assuming that MariaDB MaxScale and the message consumer are successfully running let’s connect to the service with an active mqfilter:
Assuming that MariaDB MaxScale and the message consumer are successfully
running let’s connect to the service with an active mqfilter:
```
[root@maxscale-02 MaxScale]# mysql -h 127.0.0.1 -P 4506 -uxxx -pyyy
@ -347,8 +367,10 @@ MariaDB [mqpairs]> select * from pairs;
7 rows in set (0.01 sec)
```
The filter send queries to the RabbitMQ server in the canonical format, i.e select RAND(?), RAND(?).
The queries Message Queue Consumer application gets from the server are stored with a counter that quickly shows how many times that normalized query was received:
The filter send queries to the RabbitMQ server in the canonical format,
i.e select RAND(?), RAND(?).
The queries Message Queue Consumer application gets from the server
are stored with a counter that quickly shows how many times that normalized query was received:
```
| 01050106010701080109010a010b010c10d | select RAND(?), RAND(?) | Columns: 2 | 2014-09-02 11:24:37 | 2014-09-02 11:29:15 | 3 |