Oracle 5.0 Reference Manual page 2609

Please note, since version 1.5.0 automatic failover is disabled for the duration of a transaction if
transaction stickiness is enabled and transaction boundaries have been detected. The plugin will
not switch connections for the duration of a transaction. It will also not perform automatic and silent
failover. Instead an error will be thrown. It is then left to the user to handle the failure of the transaction.
Please check, the
A basic manual failover example is provided within the
Standby servers
Using weighted load
servers that are sparsely used during normal operations. A standby server that is primarily used as
a worst-case standby failover target can be assigned a very low weight/priority in relation to all other
servers. As long as all servers are up and running the majority of the workload is assigned to the
servers which have hight weight values. Few requests will be directed to the standby system which has
a very low weight value.
Upon failure of the servers with a high priority, you can still failover to the standby, which has been
given a low load balancing priority by assigning a low weight to it. Failover can be some manually or
automatically. If done automatically, you may want to combine it with the
At this point, it is not possible to instruct the load balancer to direct no requests at all to a standby.
This may not be much of a limitation given that the highest weight you can assign to a server is 65535.
Given two slaves, of which one shall act as a standby and has been assigned a weight of 1, the
standby will have to handle far less than one percent of the overall workload.
Failover and primary copy
Please note, if using a primary copy cluster, such as MySQL Replication, it is difficult to do connection
failover in case of a master failure. At any time there is only one master in the cluster for a given
dataset. The master is a single point of failure. If the master fails, clients have no target to fail over write
requests. In case of a master outage the database administrator must take care of the situation and
update the client configurations, if need be.
20.7.6.5.6. Load balancing
Copyright 1997-2012 the PHP Documentation Group. [2230]
Four load balancing strategies are supported to distribute statements over the configured MySQL slave
servers:
random
random once (default)
round robin
user-defined via callback
The load balancing policy is configured in the plugins configuration file using the random, roundrobin,
and user filters.
Servers can be prioritized assigning a weight. A server that has been given a weight of two will get
twice as many requests as a server that has been given the default weight of one. Prioritization can
be handy in heterogenous environments. For example, you may want to assign more requests to a
powerful machine than to a less powerful. Or, you may have configured servers that are close or far
from the client, thus expose different latencies.
Mysqlnd replication and load balancing plugin (mysqlnd_ms)
trx_stickiness
balancing, introduced in PECL/mysqlnd 1.4.0, it is possible to configure standby
Chooses a random server whenever a statement is executed.
Chooses a random server after the first statement is executed, and
uses the decision for the rest of the PHP request.
It is the default, and the lowest impact on the connection state.
Iterates over the list of configured servers.
Is used to implement any other strategy.
documentation how to do this.
error handling
2589
section.
remember_failed
option.