Skalierbarkeit mit MariaDB und MaxScale - MariaDB Roadshow Summer 2014 Hamburg Berlin Frankfurt

Skalierbarkeit mit MariaDB und MaxScale

MariaDB Roadshow 2014 Hamburg -‐ Berlin -‐ Frankfurt

Ralf Gebhardt, Sales Engineer [email protected]

© SkySQL – The MariaDB Company

MaxScale ObjecRves

•  Highly scalable •  Transparent to the applicaRon •  Highly available •  Extendible •  Flexible • Modules specify what MaxScale is : router / firewall / data extract tool /…

•  Open source, GPL2 soZware since 8th of Jan. 2014


How? In a nut shell

Core of MaxScale is mulR-‐threaded, event-‐driven network IO processor

10/06/2014

Client authenRcates once -‐ with MaxScale

Alter, block or log client requests and results

Content-‐aware or unaware routers

ConfiguraRon and state aware monitors

Allows mulRple protocols for clients and servers


MaxScale 0.7

●  Galera support ○  Read/Write Split router for Galera Cluster

●  Multiple slaves support

○  Read/Write Split router allows multiple slave connections and balancing load between them

●  Debug Interface enhancements ○  Support for wide variety of MaxScale objects which can be referenced by their names instead of memory

addresses ○  User mode to prevent access by using memory addresses

●  Maintenance mode for servers ●  Configurable monitoring interval ●  Replication Lag Heartbeat Monitor ●  Filters API ●  MariaDB 10 Replication support in MySQL monitor

Release notes: https://github.com/skysql/MaxScale/blob/release-0.7/Documentation/Debug%20And%20Diagnostic%20Support.pdf


MaxScale 1.0 beta

●  Announced 7th of July ●  First Beta Release

●  ConnecRon RouRng ●  Master, Slave, Synced

●  Read/Write Spliber ●  Statement based rouRng ●  Balance Load on Slaves

●  Monitor for ReplicaRon and Galera

●  Filter ●  Query Logging ●  RegEx Match/Replace ●  Tee – Second Service ●  Top – Per ConnecRon Long

Query logging ●  Protocols

●  MySQL Client, MySQL Backend ●  Telnet ●  HTTPD


Basic Setup

●  Clients access MaxScale ●  MaxScale in the app server,

UNIX sockets ●  Database servers accessed

via TCP

●  Clients ●  ApplicaRon Server

Database Cluster


Typical Scenarios

●  MySQL ReplicaRon with ●  Read connecRon load

balancing ●  Read/Write statement

spligng ●  Galera Cluster

●  ConnecRon load balancing ●  Read/Write statement

spligng ●  Write conflict avoidance

(planned)


Inside MaxScale MySQL Local AuthenRcaRon

Backends Clients

ok

“read user, host” connect/auth

Users are loaded at start


Inside MaxScale Read/write spligng

“call my_proc(1)”

Master

Slave

Query Classifier


Inside MaxScale RouRng


Read ConnecRon RouRng -‐ ReplicaRon

●  For applica*ons that are “Replica*on aware”, i.e. they can use 2 connec*ons, one for the master and one for the slave servers

●  Each applicaRon server uses 2 or more connecRons: 1 R/W, 1+ R/O

●  ConnecRon load balancing is fast, lightweight and it provides high availability

●  MaxScale connects the R/W client connecRon to the master and it load balances the R/O client connecRon to one of the slaves

●  MHA may provide the automaRc failover in case of fault of the master


Read Scalability with MySQL ReplicaRon Using MaxScale’s ConnecRon Load Balancing

Client Client Client For applications that need read scalability and load balancing and can use separate connections for reads and writes.

Each client establishes one connection for writes and one for reads

Master Slave Slave

[write service] type=service router=readconnroute router_options=master servers=s1,s2,s3,..,sn

[read service] type=service router=readconnroute router_options=slave servers=s1,s2,s3,..,sn

Slave Slave ...


ConnecRon RouRng -‐ Galera

●  For applica*ons that can use the“all-‐master” capabili*es of Galera

●  Each applicaRon server uses only 1 connecRon

●  MaxScale monitors the state of each Galera Cluster and it applies load balancing only on synced nodes

●  MaxScale load balances the client connecRons to the Galera nodes


Read/Write Spligng -‐ ReplicaRon

●  For applica*ons that have been designed to work with a single server and require read scalability

●  Each applicaRon server uses only 1 connecRon

●  MaxScale monitors the state of each node and it applies load balancing only on the available slaves

●  MaxScale creates 2 or more connecRons, one for R/W on the master node and one R/O load balanced on the slave nodes

●  Slave automaRc failover, server weighRng, replicaRon consistency can be applied


Read/Write Spligng -‐ Galera

●  For applica*ons designed to work with a single database server, they now require high availability and read scalability without applica*on changes

●  Read/Write requests are sent to a designated master in order to maintain full compaRbility also at locking level

●  Read/Only requests are sent to other masters, when no locking is needed (depending on the isolaRon level)

●  MaxScale monitors the availability of the Galera nodes

●  No need to set ReplicaRon consistency checks on MaxScale


Query Monitor

●  For developers and devops who need to monitor/troubleshoot their applica*ons and the traffic between the applica*on server and the database

●  Incoming queries and outcoming results are tracked by MaxScale and info are stored in log files or they are sent to external data handlers

●  Developers can have a precise logging of their queries or they can analyse the top queries that are sent to the database

●  The query monitor uses filters to operate. It can coexist with other services


Query TransformaRon

●  For applica*ons that cannot be modified, but queries must be evaluated and in some cases transformed, for example to apply different reads or writes

●  Incoming queries are evaluated by filters using regular expressions

●  The queries can be passed as is, they can be transformed or even split/trasnformed in mulRple queries

●  Developers can apply modificaRons to legacy applicaRons without changes to the code


Query Rewrite and Filtering Using MaxScale’s Filters

Client Client Client For applications with multiple different backend databases. For database firewalling, etc.

CREATE TABLE SUPPLIER(ID INTEGER, NAME VARCHAR) TYPE=INNODB

[regex] type=filter module=regexfilter match=TYPE replace=ENGINE

CREATE TABLE SUPPLIER(ID INTEGER, NAME VARCHAR) ENGINE=INNODB


Query rewrite and filtering (cont.) Using MaxScale’s Filters

Client Client Client For sloppy administrators :-)

Select count(*) f0rm mysql.user

[regex] type=filter module=regexfilter match=[Ff][Oo0][Rr][Mm] replace=FROM

Select count(*) FROM mysql.user


What’s coming

●  Filters ●  RouRng hints ●  MulRple Slave Support ●  Weight based rouRng ●  Backend failure tolerance ●  Enforce Node ReplicaRon consistency for MariaDB 10 & MySQL 5.6


Extending with filters

●  May be connected to form arbitrary chains ●  Allows inspecRon, modificaRon and rejecRon of requests and results

●  blacklist ●  data mining / log


Get involved

●  Check on GitHub ●  hbps://github.com/skysql/MaxScale

●  MariaDB Source ●  hbps://downloads.mariadb.org/

●  Bugs report ●  hbp://bugs.skysql.com/buglist.cgi?product=Maxscale

●  Google groups ●  hbps://groups.google.com/forum/#!forum/maxscale

●  Binary Tarball ●  hbp://downloads.skysql.com/files/SkySQL/MaxScale

●  SkySQL website ●  hbp://www.skysql.com

Fragen? www.mariadb.com

www.facebook.com/mariadb.dbms www.twiber.com/mariadb

Vielen Dank!

Skalierbarkeit mit MariaDB und MaxScale

© Copyright 2014 SkySQL Corporation Ab. SkySQL and MariaDB are trademarks or registered trademarks of SkySQL Corporation Ab in the European Union and United States of America and/or other

countries. MySQL is a trademark of Oracle Corporation Inc. Other names may be trademarks of their respective owners.

Skalierbarkeit mit MariaDB und MaxScale - MariaDB Roadshow Summer 2014 Hamburg Berlin Frankfurt

Software

Transcript of Skalierbarkeit mit MariaDB und MaxScale - MariaDB Roadshow Summer 2014 Hamburg Berlin Frankfurt