Triangle MySQL User Group MySQL Fabric Presentation Feb 12th, 2015

MySQL Fabric
MySQL Fabric provides a simple way to manage a
collection of MySQL Servers and ensure that
transactions and queries are routed to the correct server
Dave Stokes @Stoker David.Stokes@oracle.com
Slides available at Slideshare.net/davestokes

2
Safe Harbor Agreement
The following is intended to outline our general product direction. It is intended
for information purposes only, and may not be incorporated into any contract. It
is not a commitment to deliver any material, code, or functionality, and should
not be relied upon in making purchasing decision. The development, release,
and timing of any features or functionality described for Oracle’s products
remains at the sole discretion of Oracle.

3
Or in other words ...
● Take what I
saw with a
grain of salt
(or more)

4
MySQL Fabric
● MySQL Fabric is an extensible framework for managing farms of MySQL
Servers. Two primary features have been implemented - High Availability
(HA) and scaling out using data sharding. These features can be used in
isolation or in combination. MySQL Fabric also provides server provisioning
using cloud frameworks such as OpenStack.
● Both features are implemented in two layers:
– The mysqlfabric process which processes any management requests.
When using the HA feature, this process can also be made responsible
for monitoring the master server and initiating failover to promote a slave
to be the new master should it fail.
– MySQL Fabric-aware connectors store a cache of the routing
information that it has fetched from MySQL Fabric and then uses that
information to send transactions or queries to the correct MySQL Server

5
What Does Fabric Look Like?
MySQL Fabric provides high availability and database sharding for MySQL Servers

6
High Availability
● HA Groups are formed from pools of two or more MySQL Servers; at any point in
time, one of those servers is the Primary (MySQL Replication master) and the
others are Secondaries (MySQL Replication slaves). The role of a HA Group is
to ensure that access to the data held within that group is always available.
● While MySQL Replication allows the data to be made safe by duplicating it, for a
HA solution two extra components are needed and MySQL Fabric provides
these:
– Failure detection and promotion - MySQL Fabric
monitors the Primary within the HA group and
should that server fail then it selects one of the
Secondaries and promotes it to be the Primary
– Routing of database requests - The routing of writes
to the Primary and load balancing reads across the
slaves is transparent to the application, even when
the topology changes during failover

7
Sharding - Scaling out
● When nearing the capacity or write performance limit of a single
MySQL Server (or HA group), MySQL Fabric can be used to
scale-out the database servers by partitioning the data across
multiple MySQL Server "groups". Note that a group could
contain a single MySQL Server or it could be a HA group.
● The administrator defines how data should be sharded between
these servers; indicating which table columns should be used as
shard keys and whether HASH or RANGE mappings should be
used to map from those keys to the correct shard.
● If further shards are needed then MySQL Fabric can split
existing shards; it is also possible to relocate shards.

8
Cloud Framework Integration -
Server Provisioning
● Elastically scale-out and scale-in the farm of
managed MySQL Servers using Cloud
frameworks such as OpenStack. MySQL
Fabric transparently secures machines from
the Cloud before setting up MySQL and
replication and including the new servers.

9
MySQL Fabric-Aware
Connectors
● MySQL Fabric-Aware connectors are currently
available for Java, PHP and Python. These
connectors automatically fetch routing
information from MySQL Fabric and then cache
it in order to route queries and transactions
directly to the correct MySQL Server. The
application simply provides the sharding key -
with no knowledge of the topology of the server
farm or the state of any server.

10
Proxy-Free Operation
● As transactions and queries are routed
directly to the correct MySQL Server, there
is no need for a proxy function - saving
latency and complexity. In addition, there is
no need for agents to be run on any of the
target machines.

11
What MySQL Fabric Adds
in Terms of High Availability
● MySQL Fabric has the concept of a HA
group which is a pool of two or more MySQL
Servers; at any point in time, one of those
servers is the Primary (MySQL Replication
master) and the others are Secondaries
(MySQL Replication slaves). The role of a
HA group is to ensure that access to the data
held within that group is always available.

12
HA (2)
●
While MySQL Replication allows the data to be made safe by duplicating it, for a HA
solution two extra components are needed and MySQL Fabric provides these:
●
Failure detection and promotion - the MySQL Fabric process monitors the Primary
within the HA group and should that server fail then it selects one of the Secondaries
and promotes it to be the Primary (with all of the other slaves in the HA group then
receiving updates from the new master). Note that the connectors can inform MySQL
Fabric when they observe a problem with the Primary and the MySQL Fabric process
uses that information as part of its decision making process surrounding the state of
the servers in the farm.
●
Routing of database requests - When MySQL Fabric
promotes the new Primary, it updates the state store
and notifies the connectors so that they can refresh
their caches with the updated routing information. In
this way, the application does not need to be aware
that the topology has changed and that writes need
to be sent to a different destination.

13
Scaling Out - Sharding
● When nearing the capacity or write
performance limit of a single MySQL Server
(or HA group), MySQL Fabric can be used
to scale-out the database servers by
partitioning the data across multiple MySQL
Server "groups". Note that a group could
contain a single MySQL Server or it could
be a HA group.

14
Sharding(2)
●
The administrator defines how data should be partitioned/sharded between these servers; this is done by creating shard mappings. A shard mapping
applies to a set of tables and for each table the administrator specifies which column from those tables should be used as a shard key (the shard key will
subsequently be used by MySQL Fabric to calculate which shard a specific row from one of those tables should be part of). Because all of these tables
use the same shard key and mapping, the use of the same column value in those tables will result in those rows being in the same shard - allowing a
single transaction to access all of them. For example, if using the subscriber-id column from multiple tables then all of the data for a specific subscriber
will be in the same shard. The administrator then defines how that shard key should be used to calculate the shard number:
– HASH - A hash function is run on the shard key to generate the shard number. If values held in the column used as the sharding key don't tend to have too many repeated
values then this should result in an even partitioning of rows across the shards.
– RANGE - The administrator defines an explicit mapping between ranges of values for the sharding key and shards. This gives maximum control to the user of how data is
partitioned and which rows should be co-located.
● When the application needs to access the sharded database, it sets a property for the connection that specifies the sharding key - the Fabric-aware
connector will then apply the correct range or hash mapping and route the transaction to the correct shard.
●
If further shards/groups are needed then MySQL Fabric can split an existing shard into two and then update the state-store and the caches of routing data
held by the connectors. Similarly, a shard can be moved from one HA group to another.
●
Note that a single transaction or query can only access a single shard and so
it is important to select shard keys based on an understanding of the data and
the application's access patterns. It doesn't always make sense to shard all
tables as some may be relatively small and having their full contents available
in each group can be beneficial given the rule about no cross-shard queries.
These global tables are written to a 'global group' and any additions or changes
to data in those tables are automatically replicated to all of the other groups.
Schema changes are also made to the global group and replicated to all of the
others to ensure consistency.
● To get the best mapping, it may also be necessary to modify the schema if there
isn't already a 'natural choice' for the sharding keys.

15
Current Limitations
The initial version of MySQL Fabric is designed to be simple, robust and able to scale to
thousands of MySQL Servers. This approach means that this version has a number of limitations,
which are described here:
● Sharding is not completely transparent to the application. While the application need not be aware
of which server stores a set of rows and it doesn't need to be concerned when that data is moved,
it does need to provide the sharding key when accessing the database.
● Auto-increment columns cannot be used as a sharding key
● All transactions and queries need to be limited in scope to the rows held in a single shard, together
with the global (non-sharded) tables. For example, Joins involving multiple shards are not
supported
● Because the connectors perform the routing function, the extra latency involved in proxy-based
solutions is avoided but it does mean that Fabric-aware connectors are required - at the time of
writing these exist for PHP, Python and Java
●
The MySQL Fabric process itself is not fault-tolerant and must be restarted in the event of it failing.
Note that this does not represent a single-point-of-failure for the server farm (HA and/or sharding)
as the connectors are able to continue routing operations using their local caches while the
MySQL Fabric process is unavailable

16
Architected for Extensibility
MySQL Fabric has been architected for extensibility at a number
of levels. For example, in the first release the only
option for implementing HA
is based on MySQL
Replication but in future
releases we hope to add
further options (for example,
MySQL Cluster). We also
hope to see completely new
applications around the
managing of farms of MySQL
Servers - both from Oracle
and the wider MySQL community.

17
Slide to Check if Audience
is still awake!

18
Conclusion
MySQL Fabric is an extensible framework for managing farms of MySQL Servers
and enabling MySQL Connectors to get transactions and queries to the most
appropriate server while hiding the topology of the server farm from the
application.
● The intent is that developers can focus on high value activities such as adding
new features to their applications rather than spending time on the platform
plumbing - that can now be handled by MySQL Fabric.
● The first applications supported by MySQL Fabric are High Availability (built on
top of MySQL Replication) and sharding-based scale-out. Over time we hope to
add new options to these applications (for example, alternate HA technologies)
as well as completely new applications. We look forward to hearing what users
would like us to add as well as what they build for themselves.

19
More on Fabric
● MySQL Forums :: Fabric, Sharding, HA,
Utilities
● Blogs
– Search on Planet.MySQL.COM

20
Demo
✔ Install MySQL 5.6/5.7 on Fabric controller
✔ Install MySQL Utilities w/ Fabic on controller
✔ Install MySQL 5.6 on three Vagrant Virtualbox
images for data nodes
✔ Setup replication for data nodes
✔ GRANT REPLICATION SLAVE ON
*.* TO 'REPLICATION'@'%'
identified BY 'ItsSecret';

21
What we want it to look like!
Sometimes it helps
to have a mental
image to help reach
goal
Or to print out and
use as a dart board
when frustrated.

22
Data Nodes
[mysqld]
● binlog-format=ROW
● log-slave-updates=true
● gtid-mode=on
● enforce-gtid-consistency=true
● master-info-repository=TABLE
● relay-log-info-repository=TABLE
● sync-master-info=1
● report-host=x.x.x.x
● report-port=3306
● server-id=1
● log-bin=mysql1-bin.log
mysql> CHANGE MASTER TO
MASTER_HOST='10.10.13.10',
MASTER_USER='replication',
MASTER_PASSWORD='*****',
MASTER_AUTO_POSITION=1;
● Query OK, 0 rows affected, 2
warnings (0.01 sec)
● mysql> START SLAVE;
● Query OK, 0 rows affected (0.00
sec)

23
Setup
mysqlfabric manage setup
[INFO] 1423080461.323271 -
MainThread - Initializing persister: user
(Fabric), server (localhost:3306),
database (fabric).
Finishing initial setup
=======================
Password for admin user is not yet set.
Password for admin/xmlrpc:
Repeat Password:
Password set.
Password set.
No result returned
● mysqlfabric manager setup creates
the necessary tables in the Fabric
state store. These tables will be
used to store the topology
information. The admin user
created here can be used to create
other users that can connect to
fabric as can be seen below. And
this command needs to be run only
once.
● MySQL 5.7 – Default SQL MODE
of STRICT will cause this to fail; I
set SQL MODE to ANSI

24
Start
mysqlfabric manage start &
[1] 12690
dstokes@dstokes-E7240:~/vagrant$ [INFO] 1423080590.563764 - MainThread - Initializing persister: user (Fabric), server
(localhost:3306), database (fabric).
[INFO] 1423080590.571004 - MainThread - Loading Services.
[INFO] 1423080590.585766 - MainThread - MySQL-RPC protocol server started, listening on localhost:32275
[INFO] 1423080590.592161 - MainThread - Fabric node starting.
[INFO] 1423080590.596949 - MainThread - Starting Executor.
[INFO] 1423080590.597056 - MainThread - Setting 5 executor(s).
[INFO] 1423080590.597318 - Executor-0 - Started.
[INFO] 1423080590.599224 - MainThread - Executor started.
[INFO] 1423080590.607582 - MainThread - Starting failure detector.
[INFO] 1423080590.609208 - XML-RPC-Server - XML-RPC protocol server ('127.0.0.1', 32274) started.
[INFO] 1423080590.609764 - XML-RPC-Server - Setting 1 XML-RPC session(s
[INFO] 1423080590.610071 - XML-RPC-Session-0 - Started XML-RPC-Session.

25
Create group
mysqlfabric group create davesfarm
Password for admin:
Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1
uuid finished success result
------------------------------------ -------- ------- ------
cc54e1b2-4e54-4d02-99b4-3692d35fcce1 1 1 1
state success when description
----- ------- ------------- ------------------------------------------------------------------
3 2 1423080661.24 Triggered by .
4 2 1423080661.25 Executing action (_create_group).
5 2 1423080661.27 Executed action (_create_group).

26
Look at new farm
mysqlfabric group lookup_servers davesfarm
Password for admin:
Fabric UUID: 5ca1ab1e-a007-feed-f00d-
cab3fe13249e
Time-To-Live: 1
server_uuid address status mode weight
----------- ------- ------ ---- ------

27
Activate
mysqlfabric group activate davesfarm
Password for admin:
[INFO] 1423081400.519033 - Executor-0 - Monitoring group (davesfarm).
Time-To-Live: 1
------------------------------------ -------- ------- ------
5ac9a044-c650-428e-ba50-50a6718f2342 1 1 1
----- ------- ------------- ------------------------------------------------------------------
3 2 1423081400.49 Triggered by .
4 2 1423081400.5 Executing action (_activate_group).
5 2 1423081400.53 Executed action (_activate_group).

28
Look at group
mysqlfabric group lookup_groups
Password for admin:
Time-To-Live: 1
group_id description failure_detector master_uuid
--------- ----------- ---------------- -----------
davesfarm None 1 None

29
Create an admin to
populate the farm
mysqlfabric user add client --user=admin
Password for admin:
Add a new Fabric user
=====================
Username: client
Protocol (default xmlrpc):
Password:
Repeat Password:
Select role(s) for new user
ID Role Name Description and Permissions
-- ---------- ---------------------------
1 superadmin Role for Administrative users
+ Full access to all core Fabric functionality
2 useradmin Role for users dealing with user administration
+ User administration
+ Role administration
3 connector Role for MySQL Connectors
+ Access to dump commands
+ Reporting to Fabric
Enter comma separated list of role IDs or names: 1
Fabric user added.
No result returned

30
Add data nodes to farm
group add davesfarm 10.10.13.10
Password for admin:
Time-To-Live: 1
------------------------------------ -------- ------- ------
550b1ba6-082d-4fef-9808-8fdfd6397de9 1 1 1
----- ------- ------------- ------------------------------------------------------------------
3 2 1423083005.22 Triggered by .
4 2 1423083005.23 Executing action (_add_server).
5 2 1423083005.27 Executed action (_add_server).
Add in .20 and .30 as other two data nodes too!

31
Welcome to Farmville!
Password for admin:
Time-To-Live: 1
------------------------------------ ----------- --------- --------- ------
0977d639-abbb-11e4-a804-0800273b9c80 10.10.13.30 SECONDARY READ_ONLY
1.0
1f96a235-abb9-11e4-a7f8-0800273b9c80 10.10.13.10 SECONDARY READ_ONLY
1.0
304e20cd-abba-11e4-a7ff-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY
1.0

32
Create PRIMARY
mysqlfabric group promote davesfarm --slave_id=1f96a235-abb9-11e4-a7f8-0800273b9c80
Password for admin:
Time-To-Live: 1
------------------------------------ -------- ------- ------
af79f3e0-fda2-4531-8aab-c8a48ad036a6 1 1 1
----- ------- ------------- ------------------------------------------------------------------
3 2 1423084103.73 Triggered by .
4 2 1423084103.73 Executing action (_define_ha_operation).
5 2 1423084103.75 Executed action (_define_ha_operation).
3 2 1423084103.74 Triggered by .
4 2 1423084103.75 Executing action (_check_candidate_fail).
5 2 1423084103.77 Executed action (_check_candidate_fail).
3 2 1423084103.77 Triggered by .
4 2 1423084103.77 Executing action (_wait_slave_fail).
5 2 1423084103.81 Executed action (_wait_slave_fail).
3 2 1423084103.8 Triggered by .
4 2 1423084103.81 Executing action (_change_to_candidate).
5 2 1423084103.93 Executed action (_change_to_candidate).
I wish the server ID was
a little easier to
remember!!!

33
E-I-E-I-O!!!
Password for admin:
Time-To-Live: 1
------------------------------------ ----------- --------- ---------- ------
0977d639-abbb-11e4-a804-0800273b9c80 10.10.13.30 SECONDARY READ_ONLY 1.0
1f96a235-abb9-11e4-a7f8-0800273b9c80 10.10.13.10 PRIMARY READ_WRITE 1.0
304e20cd-abba-11e4-a7ff-0800273b9c80 10.10.13.20 SECONDARY READ_ONLY 1.0
Note modes!! Primary and
Secondary.

34
What if I want to stop?!?!?
shell> mysqlfabric manage stop

35
Real Live Data Being Sent!!
● This is where the demo comes to a grinding halt
– Was never able to get a client program to connect
(my fault)
– Was able to promote SECONDAY to PRIMARY
– Was not able to clear faulty node
– Documentation leaves much to be desired
– Could not get logging to work
– BIG applogies

36
What Next?
● Get notes to Developers
● Get client programs to work
● Shore up documentation
● Get this in Docker
Slideshare.net/davestokes
@stoker
OpensourceDBA.wordpress.com
David.Stokes@Oracle.com

Triangle MySQL User Group MySQL Fabric Presentation Feb 12th, 2015

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Triangle MySQL User Group MySQL Fabric Presentation Feb 12th, 2015 (20)

More from Dave Stokes (20)

Recently uploaded (20)

Triangle MySQL User Group MySQL Fabric Presentation Feb 12th, 2015