| Bug #95151 | unsuccessful auto-rejoin sometimes is unable to set super_read_only | ||
|---|---|---|---|
| Submitted: | 26 Apr 2019 10:06 | Modified: | 30 Apr 2019 12:54 |
| Reporter: | Nuno Carvalho | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Group Replication | Severity: | S3 (Non-critical) |
| Version: | OS: | Any | |
| Assigned to: | CPU Architecture: | Any | |
[30 Apr 2019 12:54]
Margaret Fisher
Posted by developer: Changelog entry added for MySQL 8.0.17: A replication group member that was unable to contact a majority of the group before the group_replication_unreachable_majority_timeout setting was reached, and then exhausted the number of auto-rejoin attempts specified by the group_replication_autorejoin_tries system variable without successfully rejoining, was sometimes unable to carry out the action specified by the group_replication_exit_state_action system variable. The member tries to carry out the action using the current session, which sometimes failed. The member now ensures that the session is initialized before using it to connect to the server to carry out the exit state action.
Description: When auto-rejoin is unable to succeed after a expel caused by a majority loss, its thread may not be able to follow the action set by group_replication_exit_state_action. To set that action, it connects to the server though the SQL API, using its own thread with the current session (PSESSION_USE_THREAD), though after a majority loss that may not be enough, what will make the SQL connection to fail. How to repeat: Remove the log suppression: call mtr.add_suppression("Unable to read the server value for the super_read_only variable"); from tests: gr_autorejoin_majority_loss_rejoin_failed_abort.test gr_autorejoin_majority_loss_rejoin_failed_readonly.test gr_autorejoin_monitoring_test.test Suggested fix: Ensure that the thread session is always initialized.