| Bug #72606 | MYSQL FABRIC: FAILOVER SCENARIO FAILED FOR A GROUP | ||
|---|---|---|---|
| Submitted: | 10 May 2014 12:39 | Modified: | 13 Jan 2015 7:52 |
| Reporter: | Alfranio Junior | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Fabric | Severity: | S3 (Non-critical) |
| Version: | 1.4.0 | OS: | Any |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.012 sec. using MySQL 8.0.36-u2-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
© 2024, Oracle Corporation and/or its affiliates
Description: Fabric uses threads to process XML-RPC requests (Session Threads), update the state store (Executor Threads) and periodically check servers' availability (Failure Detector Threads). Each thread gets assigned its own database connection when it starts. If we configure too many executor threads and session threads, the maximum number of database connections might be reached and the failure detector will not be able to fetch information on servers and monitor them. So if there is a failure, servers will not be set to faulty and a new master will not be elected. How to repeat: 1. Set the max_connections so that: (#executor_threads + #session_threads >= #max_connections) 2. Create a group, add servers to it and promote a server to master. 3. Enable the built-in failure detector. 4. Kill the master. 5. Check that a new master is not elected. Suggested fix: Check whether (#executor_threads + #session_threads >= #max_connections) is true and raise an exception if this happens. This must be done when Fabric starts and when the built-in failure detector is enabled.