[MDEV-35969] reset service manager status

[eworm-de]

• The Jira issue number for this PR is: MDEV-35969

Description

I am running a Galera cluster with MariaDB 11.4.4. When ever a server does a WSREP state transfer it results in the service manager reporting that WSREP state transfer, visible in status:

root@mariadb01 ~ # systemctl --lines=0 --no-pager status mariadb.service
● mariadb.service - MariaDB 11.4.4 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
             └─LimitNOFILE.conf, Shutdown.conf
     Active: active (running) since Tue 2025-01-28 12:12:19 CET; 23h ago
 Invocation: e079a859e5f24b2f8a9e48013e7d61cb
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 984 (mariadbd)
     Status: "WSREP state transfer ongoing..."
      Tasks: 491 (limit: 1020061)
     Memory: 116.9G (peak: 123G)
        CPU: 11h 46min 3.224s
     CGroup: /system.slice/mariadb.service
             └─984 /usr/bin/mariadbd --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1

However that status is not updated after the state transfer. Instead it should change back to the default status "Taking your SQL requests now...".

Release Notes

• Update status in service manager after state transfer

How can this PR be tested?

After a state transfer the status should switch back. No idea if this can be tested in current test suite.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[janlindstrom]

Looks good.

[grooverdan]

Happy with most of this. Good idea.

Completely optionally, did you want to go further and for the donor list the joiner node and for the joiner, list the donor?

Though the READY=1 is probably harmless, it doesn't appear to be relevant at this point in the server execution. Was there are reason to to include it?

ref: https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html#READY=1

[eworm-de]

Completely optionally, did you want to go further and for the donor list the joiner node and for the joiner, list the donor?

Sounds reasonable, I will have a look. This should be straight forward for the joins. Can a donor have more than one joiner at a time?

Though the READY=1 is probably harmless, it doesn't appear to be relevant at this point in the server execution. Was there are reason to to include it?

That's true, should not be required here. Just push a new commit with that dropped.

But thinking about this... In case of the joiner role, does the code go through handle_connections_sockets() after state transfer is complete, making the extra call to sd_notify() useless (or even wrong, as it happens too early)?

[eworm-de]

Hmm, is there an easy way to get the remote joiner or donor name? Or is it available within the Galera plugin only?

[eworm-de]

Alternatively... How about setting new state:

"WSREP state transfer (role) finished."

This would not set the initial state ("Taking..."), but would be fine fore me as long as it does not read "... ongoing...".

[grooverdan]

But thinking about this... In case of the joiner role, does the code go through handle_connections_sockets() after state transfer is complete, making the extra call to sd_notify() useless (or even wrong, as it happens too early)?

Might depend on if its a mysqldump sst or another one. Needs a deeper look.

Can a donor have more than one joiner at a time?

Fairly sure it cannot be.

Hmm, is there an easy way to get the remote joiner or donor name? Or is it available within the Galera plugin only?

I haven't looked to closely where it would be. Guess I was hoping it was close.

Alternatively... How about setting new state:

"WSREP state transfer (role) finished."

This would not set the initial state ("Taking..."), but would be fine fore me as long as it does not read "... ongoing...".

I'm pretty open to anything factually correct.

[eworm-de]

Just updated again... I think it's better to go with this wording.

No idea where to get the remote node's name... Give me a hint if you know. 😉

[grooverdan]

Just updated again... I think it's better to go with this wording.

No idea where to get the remote node's name... Give me a hint if you know. 😉

I got as far as grooverdan@91594dd

Both are joiner addresses, and if the joiner is aware who the donor its much higher than where the monitor threads are created and hence not really suitable for a restructure. Sorry I suggested it 😼 .