Mysql User Camp : 20-June-14 : Mysql Fabric

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.1
MySQL Fabric

Copyright © 2014, Oracle and/or its affiliates. All rights reserved.| Percona Live | April 3, 2014 |2
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.
Safe Harbor Statement

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.3
Program Agenda
 Handling Scaling
 What is sharding?
 Managing a Sharded Database
 Working with a Sharded Database

What is
this
shardin
g?
What are
the
benefits
of
sharding
?
How do I
shard my
database
?

It's all about scaling...
●
Start with a single server
The Growing Enterprise

●
●
More and more page requests
●
...more and more reads
●
What to do?
●
Scale out!

●
●
●
●
What to do?
●
Scale out!
●
Replicate to read servers

●
●
●
●
What to do?
●
Scale out!
●
Replicate to read servers
●
Perform a read-write split
●
Writes go to master
●
Reads go to read servers

●
More and more updates
●
Write load increases
●
What now?

●
●
●
What now?
●
Add another master?

●
●
●
What now?
●
Add another master?
●
Doesn't work...
●
Write load is replicated

●
●
●
What now?
●
Add another master?
●
Doesn't work...
●
Write load is replicated
●
Partition database
●
Distribute writes
●
Called sharding
UID 10000-20000 UID 20001-40000

Benefits of Sharding
●
Write scalability
●
Can handle more writes
●
Large data set
●
Database too large
●
Does not fit on single server
●
Improved performance
●
Smaller index size
●
Smaller working set
●
Improve performance
UID 10000-20000 UID 20001-40000

High-level Architecture
●
What components do we need?
●
How are they deployed?

Components for a Sharding Solution
Shard
#2
Shard
#1
Shard
#3
Switch
State
Store Executor
QUERY
KEY
KEY
QUERY
Contain decision logic
for distributing queries
Contain information
about location of shards
SHARD#

Transaction and Shard Key Handling
●
How are the transactions handled?
●
How do get the shard key for a transaction?
●
How to compute shard from key?

BEGIN
SELECT salary INTO @s FROM salaries WHERE emp_no = 20101;
SET @s = 1.1 * @s;
INSERT INTO salaries VALUES (20101, @s);
COMMIT
BEGIN
INSERT INTO ...
COMMIT
Sharding key? Ah, there it is!
Session state?
Hmm... looks like
a read transaction
Oops.. it was a
write transaction!
Transaction done!
Clear session state?
New transaction! Different shard?
What about the session state?
Transaction Handling

Transaction Handling
●
Detecting transaction boundaries
●
Managing session state
●
Move session state between servers
– Easy to use
– Expensive and error prone
●
Reset state after each transaction
– Transactions start with default session state
What about
crashes?
Where do I store
the session state?

Mapping the Sharding Key
●
What is a sharding key?
●
Single column
●
Multi column
– Same table?
– Different tables?
●
How is the key
transformed?
●
Hash
●
Range
●
User-defined
Compute
Shard#
KeyShard#
(X)
(X,Y,...)
RANGE
HASH
Something else

Granularity of Sharding
●
Can multiple tables be sharded with the same key?
●
Can we shard different tables different ways?
●
Do we allow global tables?
●
Do we allow cross-database queries?

Sharded Tables
Table Rows
salaries 284 404 700
titles 44 330 800
employees 30 002 400
dept_emp 33 160 300
dept_manager 2 400
departments 900
In desperate need
of sharding!
Foreign keys

Multi-table Query with Sharded Tables
SELECT first_name, last_name, salary
FROM salaries JOIN employees USING (emp_no)
WHERE emp_no = 21012
AND CURRENT_DATE BETWEEN from_date AND to_date;
● Referential Integrity Constraint
● Example query joining salaries and employees
● Same key, same shard: co-locate rows for same user
● JOIN normally based on equality
● Using non-equality defeats purpose of foreign key

Global Tables
Table Rows
salaries 284 404 700
titles 44 330 800
employees 30 002 400
dept_emp 33 160 300
dept_manager 2 400
departments 900
Do not really need
to be sharded

Multi-table Query with Global Tables
SELECT first_name, last_name, GROUP_CONCAT(dept_name)
FROM employees JOIN dept_emp USING (emp_no)
JOIN departments USING (dept_no)
WHERE emp_no = 21012 GROUP BY emp_no;
● JOIN with departments table
● Has no employee number, hence no sharding key
● Table need to be present on all shards
● How do we update global tables?

25
Insert Picture Here
Copyright © 2014, Oracle and/or its affiliates. All rights reserved.| Percona Live | April 3, 2014 |
An extensible and easy-to-use
framework for managing a farm of
MySQL servers supporting high-
availability and sharding
MySQL Fabric

MySQL Fabric Architecture
High Availability Groups
Application
XML-RPC
SQL
SQL
Connector
Connector
Connector
Operator
MySQL
Fabric
Node
Application
Servers

High-Level Components
●
Fabric-aware Connectors
●
Python, PHP, and Java
●
Enhanced Connector API
●
MySQL Fabric Node
●
Manage information about farm
●
Provide status information
●
Execute procedures
●
MySQL Servers
●
Organized in High-Availability
Groups
●
Handling application data
High Availability
Group
Application
Connector
Connector
Connector
MySQL
Fabric
Node

MySQL Fabric Node Architecture
MySQL
MySQL Fabric
Framework
Executor
State Store
(Persister)
Sh
HA
MySQLAMQP XML-RPC
??
Connector
Connector
Connector
Protocols
Extensions
Backing
Store

MySQL Fabric: Prerequisites
●
MySQL Servers (version 5.6.10 or later)
●
Backing store database server
●
Application datatabase servers
●
Python 2.6 or 2.7
●
No support for 3.x yet
●
MySQL Utilities 1.4
●
Available at
https://dev.mysql.com/downloads/tools/utilities
●
“Development release” tab

30
Insert Picture Here
Architecture for
High-Availability

High-Availability Group Concept
● Group of servers
● Hardware redundancy
● Data redundancy
● Generic Concept
● Implementation-independent
● Self-managed or externally
managed
● Different Types
● Primary-Backup (Master-Slave)
● Shared or Replicated Storage
● MySQL Cluster
Done!
Examples Only
Not Yet Implemented

High-Availability Group Concept
● Abstract Concept
● Set of servers
● Server attributes
● Connector Attributes
● Connection information
● Mode: read-only, read-
write, ...
● Weight: distribute load
● Management Attributes
● Status: state/role of the
server
Status: Primary
Mode: Read-Write
Host: server-1.example.com

33
Insert Picture Here
Architecture for
Sharding

Sharding Architecture
Shards
MySQL Fabric
Node
Application
Connector
Connector
Connector
Global
Group
Global Updates
Shard
Updates
Replication
Support global update
for off-line shards

MySQL Fabric: Sharding Goals & Features
●
Connector API
Extensions
●
Support Transactions
●
Support full SQL
●
Decision logic in
connector
●
Reducing network load
●
Shard Multiple Tables
●
Using same key
●
Global Updates
●
Global tables
●
Schema updates
●
Sharding Functions
●
Range
●
(Consistent) Hash
●
Shard Operations
●
Using built-in executor
●
Shard move
●
Shard split

Thank you!

Mysql User Camp : 20-June-14 : Mysql Fabric

More Related Content

What's hot

What's hot (20)

Similar to Mysql User Camp : 20-June-14 : Mysql Fabric

Similar to Mysql User Camp : 20-June-14 : Mysql Fabric (20)

More from Mysql User Camp

More from Mysql User Camp (10)

Recently uploaded

Recently uploaded (20)

Mysql User Camp : 20-June-14 : Mysql Fabric