Partitioning and Sharding

Database clustering is done for various reasons. Clusters can improve availability,
fault tolerance, and increase performance by applying a divide and conquer approach
as work is distributed over many machines. Clustering is sometimes combined with
partitioning and sharding to further break up a large complex task into
smaller, more manageable units.

The mysqlnd_ms plugin aims to support a wide variety of MySQL database clusters. Some flavors of
MySQL database clusters have built-in methods for partitioning and sharding,
which could be transparent to use. The plugin supports the two most
common approaches: MySQL Replication table filtering, and Sharding
(application based partitioning).

MySQL Replication supports partitioning as filters that allow you to
create slaves that replicate all or specific databases of the master, or tables.
It is then in the responsibility of the application
to choose a slave according to the filter rules. You can either use the
mysqlnd_ms node_groups
filter to manually support this, or use the experimental table filter.

Manual partitioning or sharding is supported through the
node grouping filter, and SQL hints as of 1.5.0. The node_groups filter
lets you assign a symbolic name to a group of master and slave servers.
In the example, the master master_0 and slave_0
form a group with the name Partition_A. It is entirely
up to you to decide what makes up a group. For example, you may use node
groups for sharding, and use the group names to address shards
like Shard_A_Range_0_100.

By default, the plugin will use all configured master and slave servers for
query execution. But if a query begins with a SQL hint like
/*node_group*/, the plugin will only consider the servers
listed in the node_group for query execution. Thus,
SELECT queries prefixed with /*Partition_A*/
will only be executed on slave_0.