3. Europe Roadshow
Locations in May & June
Berlin
May 18
Munich
May 11
Bonn
June 30
Amsterdam
May 23
Paris
June 30
Madrid
May 18
Milan
May 11
Details and registration:
http://go.mariadb.com/Europe-Roadshow-LP.html
More dates and locations will be announced soon!
4. Meetup’s Agenda
• With MariaDB Server:
• Replication::ReadWriteSplit;
• Replication::ConnectionRouting;
• Replication::SchemaRouter;
• With MariaDB Cluster:
• Configuring it as Master/Slave cluster
• New features MaxScale 2.1 (coming soon)
4
7. MariaDB Server, Replication::ReadWriteSplit
• The readwritesplit router is designed to increase the read-only processing capability of
a cluster while maintaining consistency;
• This is achieved by splitting the query load into read and write queries;
• Read queries, which do not modify data, are spread across multiple nodes while all write
queries will be sent to a single node;
• This router is designed to be used with a traditional Master-Slave replication cluster;
MaxScale> list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
myrocksdb01 | 192.168.50.11 | 3306 | 0 | Master, Running
myrocksdb02 | 192.168.50.12 | 3306 | 0 | Slave, Running
myrocksdb03 | 192.168.50.13 | 3306 | 0 | Slave, Running
-------------------+-----------------+-------+-------------+--------------------
7
8. MariaDB Server, Replication::ReadWriteSplit
• The following operations are routed to master:
• write statements;
• all statements within an open transaction;
• stored procedure calls, and user-defined function calls;
• DDL statements (DROP|CREATE|ALTER TABLE … etc.);
• EXECUTE (prepared) statements;
• all statements using temporary tables.
8
9. MariaDB Server, Replication::ReadWriteSplit
• Queries which can be routed to slaves must be auto committed and belong to one of the
following group:
• read-only database queries;
• read-only queries to system, or user-defined variables;
• SHOW statements, and system function calls.
• Slaves can be set as per max_slave_connections as it sets the maximum number of
slaves a router session uses at any moment - default is all including master;
• One can use router_options to remove current master to the current read pool;
9
10. MariaDB Server, Replication::ReadWriteSplit
• router_options
• it may include multiple readwritesplit-specific options;
• slave_selection_criteria, how requests will be sent to slaves;
• LEAST_GLOBAL_CONNECTIONS, the slave with least connections
from MariaDB MaxScale
• LEAST_ROUTER_CONNECTIONS, the slave with least connections
from this service
• LEAST_BEHIND_MASTER, the slave with smallest replication lag
• LEAST_CURRENT_OPERATIONS (default), the slave with least active
operations
10
11. MariaDB Server, Replication::ReadWriteSplit
• router_options
• master_accept_reads = [true|false]
• the is the option that can include or remove master from the reading pool;
• master_failure_mode
• fail_instantly, when the failure of the master server is detected, the connection
will be closed immediately.
• fail_on_write, the client connection is closed if a write query is received when
no master is available.
• error_on_write, If no master is available and a write query is received, an
error is returned stating that the connection is in read-only mode.
11
13. MariaDB Server, Replication::ConnectionRoute Router
• The readconnroute router provides simple and lightweight load balancing across a set
of servers;
• The router can also be configured to balance connections based on a weighting parameter
defined in the server's section;
• Differs from readwritesplit router as this router needs one port for reads and another
one for writes and router_options can be used as well;
• One can define a goos strategy here:
• point the master directly on the maxscale’s configuration file for writes;
• point the slaves for reads, in case a master crash, adjust configuration file and reload;
13
14. MariaDB Server, Replication::ConnectionRoute Router
• Let’s consider the following scenario:
MaxScale> list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
myrocksdb01 | 192.168.50.11 | 3306 | 0 | Master, Running
myrocksdb02 | 192.168.50.12 | 3306 | 0 | Slave, Running
myrocksdb03 | 192.168.50.13 | 3306 | 0 | Slave, Running
-------------------+-----------------+-------+-------------+--------------------
MaxScale> list services
Services.
--------------------------+----------------------+--------+---------------
Service Name | Router Module | #Users | Total Sessions
--------------------------+----------------------+--------+---------------
Write Service | readconnroute | 2 | 2
Read Service | readconnroute | 1 | 1
CLI | cli | 2 | 2
--------------------------+----------------------+--------+---------------
14
15. MariaDB Server, Replication::ConnectionRoute Router
• Let’s shutdown current master:
• We do the manual switch on the MariaDB server:
• reset slave all; on myrocksdb02;
• change master to master_host=‘myrocksdb02’; on myrocksdb03;
• On Maxscale, comment server myrocksdb01, remove it form the list of servers on [Replication
Monitor] and on Write Service, on the latter, put myrocksdb02;
• set server myrocksdb02 master
#: stop/crash current master
[root@box01 ~]# systemctl stop mariadb
#: maxscale logs
Server 192.168.50.11:3306 lost the master status.
Server changed state: myrocksdb01[192.168.50.11:3306]: master_down. [Master, Running] -> [Down]
15
16. MariaDB Server, Replication::ConnectionRoute Router
• After these…
#: new scenario
[root@maxscale maxscale_config]# maxadmin -e "list servers"
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
myrocksdb01 | 192.168.50.11 | 3306 | 0 | Down
myrocksdb02 | 192.168.50.12 | 3306 | 0 | Master, Running
myrocksdb03 | 192.168.50.13 | 3306 | 0 | Slave, Running
-------------------+-----------------+-------+-------------+--------------------
#: maxscale logs
Update server protocol for server 192.168.50.13 to protocol MySQLBackend.
Update server protocol for server 192.168.50.12 to protocol MySQLBackend.
Update router for service Read Service to readconnroute.
Update router for service Write Service to readconnroute.
Server changed state: myrocksdb02[192.168.50.12:3306]: new_slave. [Master, Slave, Running] ->
[Slave, Running]
16
20. Scaling-Out MariaDB Cluster
• MaxScale makes your life easier when working with MariaDB Cluster:
• Checks on severs roles;
• Setup monitors and trigger alerts from nodes status changes;
• Transparently configure good practices in read/write split;
• Elect new “master" node to receive write traffic;
• Add a server under maintenance and clear up its status;
• One can use Galera Monitor or the ReadWriteSplit Module for MariaDB Cluster:
• Galera Monitor: http://bit.ly/2nshrOk
• ReadWriteSplit: http://bit.ly/2oTPXxY
20
21. Scaling-Out MariaDB Cluster
• Galera Monitor:
• The Galera Monitor is a monitoring module for MaxScale that monitors a Galera
cluster;
• It detects whether nodes are a part of the cluster and if they are in sync with the rest of
the cluster;
• It can also assign master and slave roles inside MaxScale, allowing Galera clusters to be
used with modules designed for traditional master-slave clusters.
21
23. Scaling-Out MariaDB Cluster
• Galera Monitor (or galeramon)
• Avoid new master election by MaxScale when new server is added to the cluster with
Galera’s monitor parameter: disable_master_failback=true
• Use priority to give MaxScale and galeramon the ability to chose a new master in case
current master is down: use_priority=true
• If the SST method of your cluster is set to xtrabackup-v2 (wsrep_sst_method), this
following parameter is interesting to avoid white flag alerts, as this is keep node’s status
as Synced even being a Donor (DONOR/DESYNCED): available_when_donor=true
23
26. Scaling-Out MariaDB Cluster
• In case you need to execute a current master’s restart:
#: stop current master
[root@box03 ~]# systemctl stop mariadb
#: set current master in maintenance
MaxScale> list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
wbwsrep01 | 192.168.50.11 | 3306 | 72 | Slave, Synced, Running
wbwsrep02 | 192.168.50.12 | 3306 | 327 | Master, Synced, Running
wbwsrep03 | 192.168.50.13 | 3306 | 0 | Maintenance, Down
—————————+-----------------+-------+-------------+--------------------
#: new master elected (checking logs - /var/log/maxscale/maxscale1.log)
Server changed state: wbwsrep02[192.168.50.12:3306]: new_master. [Slave, Synced, Running] ->
[Master, Synced, Running]
Server changed state: wbwsrep03[192.168.50.13:3306]: master_down. [Master, Synced, Running] ->
[Down]
26
27. Scaling-Out MariaDB Cluster
• When former master comes back online:
#: when the former master comes back online, now as a slave due to monitor configs we applied
MaxScale> list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
wbwsrep01 | 192.168.50.11 | 3306 | 0 | Slave, Synced, Running
wbwsrep02 | 192.168.50.12 | 3306 | 0 | Master, Synced, Running
wbwsrep03 | 192.168.50.13 | 3306 | 0 | Maintenance, Down
-------------------+-----------------+-------+-------------+--------------------
MaxScale> clear server wbwsrep03 maintenance
MaxScale> list servers
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
wbwsrep01 | 192.168.50.11 | 3306 | 0 | Slave, Synced, Running
wbwsrep02 | 192.168.50.12 | 3306 | 0 | Master, Synced, Master Stickiness, Running
wbwsrep03 | 192.168.50.13 | 3306 | 0 | Slave, Synced, Running
-------------------+-----------------+-------+-------------+--------------------
27
28. Scaling-Out MariaDB Cluster
• Adding a new galera cluster's node:
• Provision a new node on cluster level and go for the proper settings;
• Raise the new node and make sure it’s part of the PRIMARY component;
• Make sure the new node is in Sync status:
• On MaxScale 2.0 config file:
• Make sure you add the new [servername] entry on servers definition;
• Make sure the Galera Service and the Galera Monitor lists the the servers name;
• Use maxadmin -e “reload configs"
#: tailing the log file after configurations and restart
Server changed state: wbwsrep01[192.168.50.11:3306]: new_slave. [Running] -> [Slave, Synced, Running]
Server changed state: wbwsrep02[192.168.50.12:3306]: new_slave. [Running] -> [Slave, Synced, Running]
Server changed state: wbwsrep03[192.168.50.13:3306]: new_master. [Running] -> [Master, Synced, Running]
Server changed state: wbwsrep04[192.168.50.14:3306]: new_slave. [Running] -> [Slave, Synced, Running]
28
29. Scaling-Out MariaDB Cluster
• The new scenario we have by now:
#: listing servers again, with the new added one
[root@maxscale ~]# maxadmin -e "list servers"
Servers.
-------------------+-----------------+-------+-------------+--------------------
Server | Address | Port | Connections | Status
-------------------+-----------------+-------+-------------+--------------------
wbwsrep01 | 192.168.50.11 | 3306 | 0 | Slave, Synced, Running
wbwsrep02 | 192.168.50.12 | 3306 | 0 | Slave, Synced, Running
wbwsrep03 | 192.168.50.13 | 3306 | 0 | Master, Synced, Running
wbwsrep04 | 192.168.50.14 | 3306 | 0 | Slave, Synced, Running
-------------------+-----------------+-------+-------------+--------------------
29
31. New MaxScale 2.1
• One of the big new features in 2.1 is the ability to add, remove and alter the server
definitions at runtime when one can starts MaxScale with a minimal configuration:
• After proper configurations to the Monitor, the listener for RWSplit can be created:
• Next step is to define the servers and link then to the monitor and service:
#: add a new monitor, stopped state after creation
maxadmin create monitor cluster-monitor mysqlmon
maxadmin alter monitor cluster-monitor user=maxuser password=maxpwd monitor_interval=1000
maxadmin restart monitor cluster-monitor
#: add the listener, no need of additional configs, started state
maxadmin create listener rwsplit-service rwsplit-listener 0.0.0.0 4006
#: add servers
maxadmin create server db-serv-west 172.0.10.2 3306
maxadmin create server db-serv-east 172.0.10.4 3306
#: link server, monitor and service
maxadmin add server db-serv-west cluster-monitor rwsplit-service
maxadmin add server db-serv-east cluster-monitor rwsplit-service
31
32. New MaxScale 2.1
• Cache
• The cache will now also be used and populated in a transaction that is not explicitly read
only, but only until the first statement that modifies the database is encountered:
• SELECT statements that refer to user or system variables are not cached;
• SELECT statements using functions whose result depend upon the current user or
context are not cached. Examples of such functions are USER(), RAND() or
CURRENT_TIME().
• Firewall Filter
• Prepared statements are now treated exactly like non-prepared statements.
• Statements can now be accepted/rejected based upon function usage.
32
33. New MaxScale 2.1
• ProxySQL performs slightly better then MaxScale 2.0 and MaxScale 2.1 performs better
than the both;
Source: https://mariadb.com/resources/blog/improving-performance-mariadb-maxscale 33
34. New MaxScale 2.1
• When connections grows largely, MaxScale 2.1 and ProxySQL are roughly on par;
Source: https://mariadb.com/resources/blog/improving-performance-mariadb-maxscale 34
35. New MaxScale 2.1
• The same here, MaxScale 2.1 and ProxySQL are roughly on par;
Source: https://mariadb.com/resources/blog/improving-performance-mariadb-maxscale 35