Oracle 5.0 Reference Manual page 2617

• Loop over all slaves. For every slave wait for its reply. Do not start checking another slave
before the currently waited for slave has replied. Check for
and Slave_SQL_Running=Yes. If both conditions hold true, fetch the value of
Seconds_Behind_Master. In case of any errors or if conditions fail, set an error on the slave
connection. Skip any such slave connection for the rest of connection filtering.
• Search for the maximum value of
the previous conditions. Subtract the value from the maximum age provided by the user with
mysqlnd_ms_set_qos. Use the result as a TTL.
• The filtering may sort out all slaves. If so, the maximum age is used as TTL, because the maximum
lag found equals zero. It is perfectly valid to sort out all slaves. In the following it is up to subsequent
filter to decide what to do. The built-in load balancing filter will pick the master.
• Inject the appropriate SQL hints to enable caching by PECL/mysqlnd_qc.
• Proceed with the connection filtering, e.g. apply load balancing rules to pick a slave.
• PECL/mysqlnd_qc is loaded after PECL/mysqlnd_ms by PHP. Thus, it will see all query
modifications of PECL/mysqlnd_ms and cache the query if instructed to do so.
The algorithm may seem expensive.
number of requests and cache hits per second the cost of checking the slaves lag can easily outweight
the costs of the cache decision.
Suggestions on a better algorithm are always welcome.
20.7.6.5.12. Supported clusters
Copyright 1997-2012 the PHP Documentation Group. [2230]
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 (primary copy). When using classical,
asynchronous MySQL replication all of the above listed tasks need to be mastered at the client side.
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
(multi-master, update-all). If all nodes in the cluster are synchronous, they automatically provide the
highest possible quality of service which makes choosing a node easier. In this case, the plugin may
serve the application after some reconfiguration to disable certain features, such as built-in read-write
splitting.
Primary copy (MySQL Replication)
This is the primary use case of the plugin. Follow the hints given in the descriptions of each feature.
Mysqlnd replication and load balancing plugin (mysqlnd_ms)
Seconds_Behind_Master
SHOW SLAVE STATUS
Documentation focus
The documentation focusses describing the use of the plugin with classical
asynchronous MySQL replication clusters (primary copy). 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.
Slave_IO_Running=Yes
from all slaves that passed
is a very fast operation. Given a sufficient
2597