Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NY Meetup: Scaling MariaDB with Maxscale

456 views

Published on

MySQL MeetUp NY, 2017

Published in: Technology
  • Be the first to comment

  • Be the first to like this

NY Meetup: Scaling MariaDB with Maxscale

  1. 1. Scaling Out MariaDB Server w/ MaxScale By Wagner Bianchi Principal RDBA wagner.bianchi@mariadb.com
  2. 2. M|17 The Conrad Hotel, NYC April 11 - 12, 2017 m17.mariadb.com Promo code: BIGAPPLE
  3. 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. 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
  5. 5. Scalability and, what are we talking about? 5
  6. 6. Scaling-Out MariaDB Server 6
  7. 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. 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. 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. 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. 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
  12. 12. MariaDB Server, Replication::ReadWriteSplit [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 protocol=MySQLBackend persistpoolmax=100 persistmaxtime=3600 [myrocksdb02] type=server address=192.168.50.12 port=3306 protocol=MySQLBackend persistpoolmax=100 persistmaxtime=3600 12
  13. 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. 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. 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. 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
  17. 17. MariaDB Server, Replication::ConnectionRoute Router • 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 protocol=MySQLClient port=33066 socket=/tmp/myrocksdb_readconnroute.sock [Read Listener] type=listener service=Read Service protocol=MySQLClient port=33077 [myrocksdb01] type=server address=192.168.50.11 port=3306 protocol=MySQLBackend [myrocksdb02] type=server address=192.168.50.12 port=3306 protocol=MySQLBackend serv_weight=3 [myrocksdb03] type=server address=192.168.50.13 port=3306 protocol=MySQLBackend serv_weight=2 17
  18. 18. MariaDB Server, Replication::SchemaRouter Module 18
  19. 19. Scaling-Out MariaDB Cluster 19
  20. 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. 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
  22. 22. Scaling-Out MariaDB Cluster • Listing servers: • Listing Monitors MaxScale> list servers Servers. -------------------+-----------------+-------+-------------+-------------------------- Server | Address | Port | Connections | Status -------------------+-----------------+-------+-------------+-------------------------- wbwsrep01 | 192.168.50.11 | 3306 | 0 | Master, Synced, Running wbwsrep02 | 192.168.50.12 | 3306 | 0 | Slave, Synced, Running wbwsrep03 | 192.168.50.13 | 3306 | 0 | Slave, Synced, Running -------------------+-----------------+-------+-------------+-------------------------- MaxScale> list monitors ---------------------+--------------------- Monitor | Status ---------------------+--------------------- Galera Monitor | Running ---------------------+--------------------- 22
  23. 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
  24. 24. Scaling-Out MariaDB Cluster • When using priorities to elect current master: [root@maxscale ~]# maxadmin -e "list servers" Servers. -------------------+-----------------+-------+-------------+-------------------- Server | Address | Port | Connections | Status -------------------+-----------------+-------+-------------+-------------------- wbwsrep01 | 192.168.50.11 | 3306 | 654 | Master, Synced, Running wbwsrep02 | 192.168.50.12 | 3306 | 76 | Slave, Synced, Running wbwsrep03 | 192.168.50.13 | 3306 | 89 | Slave, Synced, Running -------------------+-----------------+-------+-------------+-------------------- [root@maxscale ~]# vim /etc/maxscale.cnf # edited priorities [root@maxscale ~]# systemctl restart maxscale [root@maxscale ~]# maxadmin -e "list servers" Servers. -------------------+-----------------+-------+-------------+-------------------- Server | Address | Port | Connections | Status -------------------+-----------------+-------+-------------+-------------------- wbwsrep01 | 192.168.50.11 | 3306 | 78 | Slave, Synced, Running wbwsrep02 | 192.168.50.12 | 3306 | 3 | Slave, Synced, Running wbwsrep03 | 192.168.50.13 | 3306 | 12 | Master, Synced, Running -------------------+-----------------+-------+-------------+-------------------- 24
  25. 25. Scaling-Out MariaDB Cluster • 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 protocol=MySQLBackend priority=3 [wbwsrep02] type=server address=192.168.50.12 port=3306 protocol=MySQLBackend priority=2 [wbwsrep03] type=server address=192.168.50.13 port=3306 protocol=MySQLBackend priority=1 25
  26. 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. 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. 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. 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
  30. 30. New MaxScale 2.1 30
  31. 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. 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. 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. 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. 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
  36. 36. Thank you Wagner Bianchi Principal RDBA wagner.bianchi@mariadb.com

×