NY Meetup: Scaling MariaDB with Maxscale

Scaling Out MariaDB
Server w/ MaxScale
By Wagner Bianchi
Principal RDBA
wagner.bianchi@mariadb.com

M|17
The Conrad Hotel, NYC
April 11 - 12, 2017
m17.mariadb.com
Promo code: BIGAPPLE

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!

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

Scalability and, what are we talking about?
5

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
-------------------+-----------------+-------+-------------+--------------------
7

• 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

• 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

• 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

• 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

[myrocksdb03]
type=server
address=192.168.50.13
port=3306
protocol=MySQLBackend
persistpoolmax=100
persistmaxtime=3600
[CLI]
type=service
router=cli
[CLI Listener]
type=listener
service=CLI
protocol=maxscaled
socket=default
[Splitter Service]
type=service
router=readwritesplit
servers=myrocksdb01,myrocksdb02,myrocksdb03
router_options=slave_selection_criteria=LEAST
_BEHIND_MASTER,master_accept_reads=FALSE,mast
er_failure_mode=erro
r_on_write
max_slave_connections=2
max_slave_replication_lag=30
user=maxuser
passwd=YqztlYG…
[Splitter Listener]
type=listener
service=Splitter Service
protocol=MySQLClient
port=3306
socket=/tmp/myrocksdb_cluster.sock
[Replication Monitor]
type=monitor
module=mysqlmon
servers=myrocksdb01,myrocksdb02,myroc
ksdb03
detect_replication_lag=1
detect_stale_master=1
user=maxuser
passwd=YqztlYG…
[myrocksdb01]
type=server
address=192.168.50.11
port=3306
persistpoolmax=100
persistmaxtime=3600
[myrocksdb02]
type=server
address=192.168.50.12
port=3306
persistpoolmax=100
persistmaxtime=3600
12

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

• Let’s consider the following scenario:
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
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

• 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

• After these…
#: new scenario
[root@maxscale maxscale_config]# maxadmin -e "list servers"
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
myrocksdb01 | 192.168.50.11 | 3306 | 0 | Down
-------------------+-----------------+-------+-------------+--------------------
#: 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

• Configuration for readconnroute load balancer
[Write Service]
type=service
router=readconnroute
router_options=master
servers=myrocksdb01
user=maxuser
password=123456
[Read Service]
type=service
router=readconnroute
router_options=slave
servers=myrocksdb02,myrocksdb03
weightby=serv_weight
user=maxuser
password=123456
[Write Listener]
type=listener
service=Write Service
port=33066
socket=/tmp/myrocksdb_readconnroute.sock
[Read Listener]
type=listener
service=Read Service
port=33077
[myrocksdb01]
type=server
address=192.168.50.11
port=3306
[myrocksdb02]
type=server
address=192.168.50.12
port=3306
serv_weight=3
[myrocksdb03]
type=server
address=192.168.50.13
port=3306
serv_weight=2 17

MariaDB Server, Replication::SchemaRouter Module
18

Scaling-Out MariaDB Cluster
19

• 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

• 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

• Listing servers:
• Listing Monitors
Servers.
-------------------+-----------------+-------+-------------+--------------------------
-------------------+-----------------+-------+-------------+--------------------------
wbwsrep01 | 192.168.50.11 | 3306 | 0 | Master, Synced, Running
wbwsrep02 | 192.168.50.12 | 3306 | 0 | Slave, Synced, Running
-------------------+-----------------+-------+-------------+--------------------------
MaxScale> list monitors
---------------------+---------------------
Monitor | Status
---------------------+---------------------
Galera Monitor | Running
---------------------+---------------------
22

• 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

• When using priorities to elect current master:
[root@maxscale ~]# maxadmin -e "list servers"
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
[root@maxscale ~]# vim /etc/maxscale.cnf # edited priorities
[root@maxscale ~]# systemctl restart maxscale
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
24

• When using priorities to elect current master:
#: monitor section
[Galera Monitor]
type=monitor
module=galeramon
servers=wbwsrep01,wbwsrep02,wbwsrep03
disable_master_failback=true
available_when_donor=true
use_priority=true
user=maxmon
passwd=123
#: servers section
[wbwsrep01]
type=server
address=192.168.50.11
port=3306
priority=3
[wbwsrep02]
type=server
address=192.168.50.12
port=3306
priority=2
[wbwsrep03]
type=server
address=192.168.50.13
port=3306
priority=1
25

• In case you need to execute a current master’s restart:
#: stop current master
[root@box03 ~]# systemctl stop mariadb
#: set current master in maintenance
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
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

• When former master comes back online:
#: when the former master comes back online, now as a slave due to monitor configs we applied
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
wbwsrep03 | 192.168.50.13 | 3306 | 0 | Maintenance, Down
-------------------+-----------------+-------+-------------+--------------------
MaxScale> clear server wbwsrep03 maintenance
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
wbwsrep02 | 192.168.50.12 | 3306 | 0 | Master, Synced, Master Stickiness, Running
-------------------+-----------------+-------+-------------+--------------------
27

• 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: wbwsrep03[192.168.50.13:3306]: new_master. [Running] -> [Master, Synced, Running]
28

• The new scenario we have by now:
#: listing servers again, with the new added one
Servers.
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
-------------------+-----------------+-------+-------------+--------------------
29

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

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

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

New MaxScale 2.1
• When connections grows largely, MaxScale 2.1 and ProxySQL are roughly on par;

New MaxScale 2.1
• The same here, MaxScale 2.1 and ProxySQL are roughly on par;

Thank you
Wagner Bianchi
Principal RDBA
wagner.bianchi@mariadb.com

NY Meetup: Scaling MariaDB with Maxscale

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à NY Meetup: Scaling MariaDB with Maxscale

Similaire à NY Meetup: Scaling MariaDB with Maxscale (20)

Plus de Wagner Bianchi

Plus de Wagner Bianchi (20)

Dernier

Dernier (20)

NY Meetup: Scaling MariaDB with Maxscale