The key features of PECL/mysqlnd_ms are as follows.
Transparent and therefore easy to use.
Supports all of the PHP MySQL extensions.
A consistent API.
Little to no application changes required, dependent on the required usage scenario.
Lazy connections: connections to master and slave servers are not opened before a SQL statement is executed.
Optional: automatic use of master after the first write in a web request, to lower the possible impact of replication lag.
Can be used with any MySQL clustering solution.
MySQL Replication: Read-write splitting is done by the plugin. Primary focus of the plugin.
MySQL Cluster: Read-write splitting can be disabled. Configuration of multiple masters possible
Third-party solutions: the plugin is optimized for MySQL Replication but can be used with any other kind of MySQL clustering solution.
Featured read-write split strategies
Automatic detection of SELECT.
Supports SQL hints to overrule automatism.
Can be disabled for, for example, when using synchronous clusters such as MySQL Cluster.
Featured load balancing strategies
Round Robin: choose a different slave in round-robin fashion for every slave request.
Random: choose a random slave for every slave request.
Random once (sticky): choose a random slave once to run all slave requests for the duration of a web request.
User-defined. The application can register callbacks with mysqlnd_ms.
PHP 5.4.0 or newer: transaction aware when using API calls only to control transactions.
Weighted load balancing: servers can be assigned different priorities, for example, to direct more requests to a powerful machine than to another less powerful machine. Or, to prefer nearby machines to reduce latency.
Global transaction ID
Client-side emulation. Makes manual master server failover and slave promotion easier with asynchronous clusters, such as MySQL Replication.
Support for built-in global transaction identifier feature of MySQL 5.6.5 or newer.
Supports using transaction ids to identify up-to-date asynchronous slaves for reading when session consistency is required.
Throttling: optionally, the plugin can wait for a slave to become "synchronous" before continuing.
Service and consistency levels
Applications can request eventual, session and strong consistency service levels for connections. Appropriate cluster nodes will be searched automatically.
Eventual consistent MySQL Replication slave accesses can be replaced with fast local cache accesses transparently to reduce server load.
Partitioning and sharding
Servers of a replication cluster can be organized into groups. SQL hints can be used to manually direct queries to a specific group. Grouping can be used to partition (shard) the data, or to cure the issue of hotspots with updates.
MySQL Replication filters are supported through the table filter.