Maxscale - Revision history

Dominik.epple: /* Installation */

2017-10-18T12:16:49Z

Installation

← Older revision		Revision as of 12:16, 18 October 2017
Line 14:		Line 14:
	== Installation ==		== Installation ==

	~~apt-get install curl~~		Follow instructions on https://mariadb.com/kb/en/mariadb-enterprise/maxscale-21-installation-guide/ to install the software on your system.
	~~curl -sS~~ https://~~downloads.~~mariadb.com/~~MariaDB~~/~~mariadb_repo_setup > setup.sh~~
	~~# be paranoid and review the script before executing... it should only modify~~
	~~# apt repos and call apt~~-~~get update~~
	~~bash setup.sh~~
	~~# so now~~ install the ~~thing~~
	~~apt-get install maxscale~~

	== Configuration ==		== Configuration ==

Dominik.epple at 14:15, 22 September 2017

2017-09-22T14:15:48Z

← Older revision		Revision as of 14:15, 22 September 2017
Line 3:		Line 3:
	== Introduction ==		== Introduction ==

	Since long HAproxy is the standard loadbalancing solution for people who want a simple userspace daemon for MySQL loadbalancing. However with the availability of Maxscale ~~there is~~ a tool which has been specifically designed to loadbalance for MySQL instances (Galera clusters and/or Master-Slave systems) and offers some attractive features. Performance-wise we have not finished out testing, but first experiments indicate that we do not observe performance regressions from HAproxy to Maxscale.		Since long HAproxy is the standard [[OXLoadBalancingClustering_Database#Loadbalancer_options\|loadbalancing solution]] for people who want a simple userspace daemon for MySQL loadbalancing. However with the availability of [https://mariadb.com/kb/en/mariadb-enterprise/maxscale/ Maxscale] we have a tool which has been specifically designed to loadbalance for MySQL instances (Galera clusters and/or Master-Slave systems) and offers some attractive features. Performance-wise we have not finished out testing, but first experiments indicate that we do not observe performance regressions from HAproxy to Maxscale.

	Maxscale comes with built-in MySQL server node status monitoring, thus no external health check service is required, which simplifies the setup ~~sigificantly~~.		Maxscale comes with built-in MySQL server node status monitoring, thus no external health check service is required, which simplifies the setup significantly.

	Links:		Links:
Line 40:		Line 40:
	The <code>Read Service</code> and <code>Write Service</code> are different by their <code>router_options</code> -- effectively we define that for the <code>Read Service</code> all nodes which are <code>synced</code> are available, while for the for the <code>Write Service</code> only the node considered by Maxscale to be the master is being used.		The <code>Read Service</code> and <code>Write Service</code> are different by their <code>router_options</code> -- effectively we define that for the <code>Read Service</code> all nodes which are <code>synced</code> are available, while for the for the <code>Write Service</code> only the node considered by Maxscale to be the master is being used.

	The behavior which node is considered master can be changed by some configuration variables, most notably <code>root_node_as_master</code> which defines that onle the ''root node'', i.e. the node with <code>wsrep_local_index=0</code> will be used as master node. This setting makes sense multiple distributed Maxscale instances are to be used, since it avoids the otherwise potential danger that different nodes pick different masters. However if you use only one (active) Maxscale instance per target cluster at a time (maybe with some active-passive HA setup), it might be beneficial to not use <code>root_node_as_master</code>, but rather <code>disable_master_failback</code> to reduce the number of master switches / failovers.		The behavior which node is considered master can be changed by some configuration variables, most notably <code>root_node_as_master</code> which defines that onle the ''root node'', i.e. the node with <code>wsrep_local_index=0</code> will be used as master node. This setting makes sense if multiple distributed Maxscale instances are to be used, since it avoids the otherwise potential danger that different nodes pick different masters. However if you use only one (active) Maxscale instance per target cluster at a time (maybe with some active-passive HA setup), it might be beneficial to not use <code>root_node_as_master</code>, but rather <code>disable_master_failback</code> to reduce the number of master switches / failovers.

	<pre>[maxscale]		<pre>[maxscale]
Line 140:		Line 140:
	socket=default		socket=default
	</pre>		</pre>

			== Operations ==

			Maxscale offers a command line tool <code>maxadmin</code> offering an impressive set of features for operations.

			* https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-21-mariadb-maxscale-administration-tutorial/
			* https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-21-maxadmin-admin-interface/

Dominik.epple: Created page with "= MariaDB Maxscale = == Introduction == Since long HAproxy is the standard loadbalancing solution for people who want a simple userspace daemon for MySQL loadbalancing. Howe..."

2017-09-22T14:05:15Z

Created page with "= MariaDB Maxscale = == Introduction == Since long HAproxy is the standard loadbalancing solution for people who want a simple userspace daemon for MySQL loadbalancing. Howe..."

New page

= MariaDB Maxscale =

== Introduction ==

Since long HAproxy is the standard loadbalancing solution for people who want a simple userspace daemon for MySQL loadbalancing. However with the availability of Maxscale there is a tool which has been specifically designed to loadbalance for MySQL instances (Galera clusters and/or Master-Slave systems) and offers some attractive features. Performance-wise we have not finished out testing, but first experiments indicate that we do not observe performance regressions from HAproxy to Maxscale.

Maxscale comes with built-in MySQL server node status monitoring, thus no external health check service is required, which simplifies the setup sigificantly.

Links:

* MaxScale documentation on GitHub: https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Documentation-Contents.md
* Complete list of configuration options: https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Getting-Started/Configuration-Guide.md

== Installation ==

apt-get install curl
curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup > setup.sh
# be paranoid and review the script before executing... it should only modify
# apt repos and call apt-get update
bash setup.sh
# so now install the thing
apt-get install maxscale

== Configuration ==

Maxscale requires a user for monitoring et al.

CREATE USER 'maxscale'@'loadbalancer.fqdn' IDENTIFIED BY 'sitpavOfEyt5';
GRANT SELECT on mysql.user TO 'maxscale'@'loadbalancer.fqdn';
GRANT SELECT ON mysql.db TO 'maxscale'@'loadbalancer.fqdn';
GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'loadbalancer.fqdn';
GRANT SHOW DATABASES ON *.* TO 'maxscale'@'loadbalancer.fqdn';
GRANT REPLICATION CLIENT on *.* TO 'maxscale'@'loadbalancer.fqdn';
FLUSH PRIVILEGES;

The config file we use is given below. Since OX App Suite has its own built-in read/write separation, we don't need Maxscale's ''Read-Write Split'' feature; rather, we configure a Read Service with round-robin semantics, and a Write Service with a persistent active-passive behavior.

Do not confuse the wording <code>Replication Monitor</code> below with OX's builtin ''Replication Monitor'' (which we disable for fully synchronous Galera). It is just an identifier for the definition of Maxscale's built-in health check which is in this case checking Galera nodes (<code>module=galeramon</code>).

The <code>Read Service</code> and <code>Write Service</code> are different by their <code>router_options</code> -- effectively we define that for the <code>Read Service</code> all nodes which are <code>synced</code> are available, while for the for the <code>Write Service</code> only the node considered by Maxscale to be the master is being used.

The behavior which node is considered master can be changed by some configuration variables, most notably <code>root_node_as_master</code> which defines that onle the ''root node'', i.e. the node with <code>wsrep_local_index=0</code> will be used as master node. This setting makes sense multiple distributed Maxscale instances are to be used, since it avoids the otherwise potential danger that different nodes pick different masters. However if you use only one (active) Maxscale instance per target cluster at a time (maybe with some active-passive HA setup), it might be beneficial to not use <code>root_node_as_master</code>, but rather <code>disable_master_failback</code> to reduce the number of master switches / failovers.

<pre>[maxscale]
threads=4

# Server definitions
#
# Set the address of the server to the network
# address of a MySQL server.
#

[db1]
type=server
address=db1.fqdn
port=3306
protocol=MySQLBackend

[db2]
type=server
address=db2.fqdn
port=3306
protocol=MySQLBackend

[db3]
type=server
address=db3.fqdn
port=3306
protocol=MySQLBackend

# Monitor for the servers
#
# This will keep MaxScale aware of the state of the servers.
# MySQL Monitor documentation:
# https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Monitors/MySQL-Monitor.md

[Replication Monitor]
type=monitor
module=galeramon
servers=db1, db2, db3
user=maxscale
passwd=sitpavOfEyt5
monitor_interval=10000

# Service definitions
#
# Service Definition for a read-only service and
# a read/write splitting service.
#

# ReadConnRoute documentation:
# https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Routers/ReadConnRoute.md

[Read Service]
type=service
router=readconnroute
servers=db1, db2, db3
user=maxscale
passwd=sitpavOfEyt5
router_options=synced

[Write Service]
type=service
router=readconnroute
servers=db1, db2, db3
user=maxscale
passwd=sitpavOfEyt5
router_options=master

# This service enables the use of the MaxAdmin interface
# MaxScale administration guide:
# https://github.com/mariadb-corporation/MaxScale/blob/2.1/Documentation/Reference/MaxAdmin.md

[MaxAdmin Service]
type=service
router=cli

# Listener definitions for the services
#
# These listeners represent the ports the
# services will listen on.
#

[Read Listener]
type=listener
service=Read Service
protocol=MySQLClient
port=4306

[Write Listener]
type=listener
service=Write Service
protocol=MySQLClient
port=4307

[MaxAdmin Listener]
type=listener
service=MaxAdmin Service
protocol=maxscaled
socket=default
</pre>