| Bug #119197 | Switching primary Group Replication/InnoDB Cluster member restricted too much | ||
|---|---|---|---|
| Submitted: | 20 Oct 2025 15:21 | ||
| Reporter: | Przemyslaw Malkowski | Email Updates: | |
| Status: | Open | Impact on me: | |
| Category: | MySQL Server: Group Replication | Severity: | S3 (Non-critical) |
| Version: | 8.0.43 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | group_replication_set_as_primary, setPrimaryInstance | ||
[20 Jul 22:24]
Vinicius Malvestio Grippa
The issue is still reproducible on 8.0.46 and 8.4.10. Now, if we use the runningTransactionsTimeout, the switchover works. Another issue I see, which may be a feature request, is that even with log_error_verbosity=3, there is no indication in the logs that the timeout was reached. This means there is no difference between a regular switchover and one that reached the runningTransactionsTimeout. 2026-07-19T16:32:21.092128Z 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address 172.31.45.175:3306 was elected. The new primary will execute all previous group transactions before allowing writes. Enabling conflict detection until the new primary applies all relay logs.' 2026-07-19T16:32:21.093139Z 104 [System] [MY-011565] [Repl] Plugin group_replication reported: 'Setting super_read_only=ON.' 2026-07-19T16:32:21.095014Z 104 [System] [MY-011511] [Repl] Plugin group_replication reported: 'This server is working as secondary member with primary member address 172.31.45.175:3306.' 2026-07-19T16:32:21.095922Z 0 [System] [MY-013213] [Repl] Plugin group_replication reported: 'Configuration operation 'Primary election change' terminated. Primary server switched to: d54506d9-838d-11f1-b30a-0eb18e277031' So a possible solution is to add information to the logs when a timeout is reached.
Description: The function SELECT group_replication_set_as_primary() has to wait for any ongoing transactions to finish before proceeding. However, for some reason, this requirement is extended to read only transactions as well. Moreover, even a BEGIN command started and not followed by any read or write query, will block the primary switchover for as long as it's not committed or session terminated. This makes it the primary switchover potentially very disruptive. If the timeout parameter is specified, like via: Cluster().setPrimaryInstance("node2", { runningTransactionsTimeout: 50 }) All the new queries, both reads and writes will be rejected with: mysql> select 1 from test.sbtest1; ERROR 4094 (HY000): All queries have been blocked while function 'group_replication_set_as_primary()' is executing. Please refer timeout parameter of function 'group_replication_set_as_primary()'. If no timeout specified, switchover will be stuck as long as the culprit session exists. Now, it is very difficult to make any pre-checks, as the blocking "transactions" are not visible anywhere - a simple BEGIN command does not start anything that would be visible in SHOW ENGINE INNODB STATUS or select * from information_schema.INNODB_TRX results. Threfore, it is impossible to find out which session may be potentially blocking. How to repeat: Run a BEGIN command and keep the session open (on the current primary). Then try to promote a new primary node in a GR/InnoDB Cluster. This will result in function waiting for a long time: *************************** 9. row *************************** ID: 4121 USER: root HOST: 192.168.56.16:39300 DB: NULL COMMAND: Query TIME: 42 STATE: executing INFO: SELECT group_replication_set_as_primary('376b49ef-7edd-11f0-8eb3-525400256914') EXECUTION_ENGINE: PRIMARY Suggested fix: I don't see any good reason for blocking the primary switchover by read-only transactions, and even less so for a pre-transaction stage, where no table was even read. I think that only write transactions should be blocking the operation, and maybe locking reads (using FOR UPDATE) too, but nothing less than these. The idea is to remove/minimize all unncessary downtime during the primary switch.