Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
Arrow up icon
GO TO TOP
MariaDB High Performance

You're reading from   MariaDB High Performance Familiarize yourself with the MariaDB system and build high-performance applications

Arrow left icon
Product type Paperback
Published in Sep 2014
Publisher
ISBN-13 9781783981601
Length 298 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Author (1):
Arrow left icon
Pierre Mavro Pierre Mavro
Author Profile Icon Pierre Mavro
Pierre Mavro
Arrow right icon
View More author details
Toc

Table of Contents (18) Chapters Close

MariaDB High Performance
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
1. Performance Introduction FREE CHAPTER 2. Performance Analysis 3. Performance Optimizations 4. MariaDB Replication 5. WAN Slave Architectures 6. Building a Dual Master Replication 7. MariaDB Multimaster Slaves 8. Galera Cluster – Multimaster Replication 9. Spider – Sharding Your Data 10. Monitoring 11. Backups Index

Chapter 9. Spider – Sharding Your Data

Spider is a specific engine made for MySQL/MariaDB. It has been integrated in MariaDB 10 which makes it one of the new and major features. It's a specific storage engine dedicated to shard data across several MariaDB servers.

It should act as a proxy to be able to work properly:

You can see in the preceding diagram that a client is talking directly to Spider to get access to its backend table content.

However, the goal of Spider is to shard your data across multiple backend servers, as illustrated in the following diagram:

Sharding will split your data on several servers to speed up read and write queries. However, in this case, we need to replicate our shards to avoid data loss, as shown in the following diagram:

Spider monitors itself to produce SQL errors when one of the backend tables is not available. As you can see, there are three Spider servers here to avoid a split-brain (classical cluster-consensus).

Note

When Spider creates a table, the table links...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime
Visually different images