Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.4.13
-
None
-
None
-
None
Description
Even after service startup has completed, and the Status: info in systemctl status mariadb has reached Status: Taking your SQL requests now... it still can be changed by further calls to service_manager_extend_timeout().
E.g. in a Galera cluster, when a new node joins and needs to receive data via SST, both the joiners and the donors status info will change to Status: WSREP State transfer ongoing .... After SST has finished the joiner will continue to proceed with startup, and status will eventually become Status: Taking your SQL requests now....
So far there's not really a problem yet, but: while the joiners state continues to change towards "Taking requests now", the donors systemctl status will still continue to show Status: WSREP State transfer ongoing ... even after SST has completed and the joiner node has fully started up.
So over time in a Galera cluster all but the latest joiner that received a SST may show "State transfer ongoing" even though there's actually no ongoing SST at all.
Also at one point I had a node showing Status: To roll back: 1 transactions, 820613 rows for a long time after a transaction failure, far longer than the actuall rollback could have taken, this I was not able to reproduce yet though ...
So we should either make service_manager_extend_timeout() to just return without doing anything once the server is fully started up, or make sure that even after startup completed the status information is properly reset to "Taking queries" when the status actually changes.