Supported clusters

Any application using any kind of MySQL cluster is faced with the same tasks:

• Identify nodes capable of executing a given statement with the required service level
• Load balance requests within the list of candidates
• Automatic fail over within candidates, if needed

The plugin is optimized for fulfilling these tasks in the context of a classical asynchronous MySQL replication cluster consisting of a single master and many slaves. When using classical, asynchronous MySQL replication all of the above listed tasks need to be mastered at the client level.

Other types of MySQL cluster may have lower requirements on the application side. For example, if all nodes in the cluster can answer read and write requests, no read-write splitting needs to be done. If all nodes in the cluster are synchronous, they automatically provide the higest possible quality of service which makes choosing a node easier. In those cases, the plugin may serve the application after some reconfiguration to disable certain features, such as built-in read-write splitting.

Замечание: Documentation focus

The documentation focusses describing the use of the plugin with classical asynchronous MySQL replication clusters. Support for this kind of cluster has been the original development goal. Use of other clusters is briefly described below. Please note, that this is still work in progress.

Using asynchronous clusters with single master

Primary use case of the plugin. Follow the hints given in the descriptions of each feature.

Замечание: Version requirement

The following cluster may require use of settings not available before mysqlnd_ms 1.2.0-alpha.

Using asynchronous clusters with multiple masters

This setup is currently unsupported.

The plugin has no built-in functionality to direct certain writes to certain masters. It is considered to add table filtering to future versions. Table filter would allow restricting both read and writes to certain slaves and masters based on the database/schema and table used by a statement.

A table filtering feature is prepared in the plugins source code. However, it is instable and must not be used. Bug reports on table filtering will be rejected.

Using synchronous clusters such as MySQL Cluster

MySQL Cluster is a synchronous cluster solution. All cluster nodes accept read and write requests. In the context of the plugin, all nodes shall be considered as masters.

Use the load balancing and fail over features only.

• Disable the plugins built-in read-write splitting.
• Configure masters only.
• Consider random once load balancing strategy, which is the plugins default. If random once is used, only masters are configured and no SQL hints are used to force using a certain node, no connection switches will happen for the duration of a web request. Thus, no special handling is required for transactions. The plugin will pick one master at the beginning of the PHP script and use it until the script terminates.
• Do not set the quality of service. All nodes have all the data. This automatically gives you the highest possible service quality (strong consistency).
• Do not enable client-side global transaction injection. It is neither required to help with server-side fail over nor to assist the quality of service filter choosing an appropiate node.

Disabling built-in read-write splitting.

• Set mysqlnd_ms.disable_rw_split=1
• Do not use SQL hints to enforce the use of slaves

Configure masters only.

• Set mysqlnd_ms.multi_master=1
• Do not configure any slaves
• Set failover=master in the plugins configuration file to avoid warnings about the empty slave list