I am trying XtraDB cluster on a 3 node setup with MySQL 8.0 and intended for WordPress CMS apps. I installed from the normal Percona getting started on Ubuntu using apt install method on Ubuntu 22.04 LTS. When I install the software and try to run systemctl start mysql@bootstrap.service (on the first node) or systemctl start mysql on the other nodes, the system service file times out after 2 minutes or hangs. In other terminal windows I check the DB process and logs and the DB and nodes run properly, as I can do normal operations like create users and query tables and such, but the systemd service file times out on the first node and hangs on the other nodes.
So it works, that is the systemctl exits normally after the start up, if I change the service file from type=notify to type=simple. (Yes, I did systemctl daemon-reload).
Is there some service script problem on Ubuntu 22.04 LTS? Is my service file hack safe to use in general, or are there other possible side effects for not using the type=notify setting?
Hey @bsabalaskey
Do you have any logs from the hang system?
What specific log(s) are you looking for? Just to reiterate, when I say hang, it is the systemctl service file that hangs at the end, but the mysql process runs and works normally, until on the 1st node the 2 minute timeout is hit, and then systemd kills the process. The other nodes just hangs indefinitely. The mysql logs show that mysql operates properly while it is running.
@bsabalaskey, systemctl status mysql should be helpful after you experience a failed start. Even journalctl -u mysql should have something.
The mysql process starts and runs fine. The systemd process => systemctl start mysql <= hangs and never exits. Repeat; the problem is not mysql but systemd. Here is a bit of mysql logs since you insist.
2024-06-13T20:03:56.282247Z 12 [Note] [MY-000000] [WSREP] Server status change initialized → joined
2024-06-13T20:03:56.282384Z 2 [Note] [MY-000000] [Galera] Draining apply monitors after IST up to 3491
2024-06-13T20:03:56.289551Z 2 [Note] [MY-000000] [Galera] IST received: a1e4ae57-245b-11ef-8331-d2c44d035d6c:3491
2024-06-13T20:03:56.289642Z 2 [Note] [MY-000000] [Galera] Recording CC from sst: 3491
2024-06-13T20:03:56.289666Z 2 [Note] [MY-000000] [Galera] Lowest cert index boundary for CC from sst: 3478
2024-06-13T20:03:56.289675Z 2 [Note] [MY-000000] [Galera] Min available from gcache for CC from sst: 3108
2024-06-13T20:03:56.290065Z 0 [Note] [MY-000000] [Galera] 0.0 (db1): State transfer from 1.0 (db3) complete.
2024-06-13T20:03:56.290093Z 0 [Note] [MY-000000] [Galera] SST leaving flow control
2024-06-13T20:03:56.290109Z 0 [Note] [MY-000000] [Galera] Shifting JOINER → JOINED (TO: 3491)
2024-06-13T20:03:56.290179Z 0 [Note] [MY-000000] [Galera] Processing event queue:… -nan% (0/0 events) complete.
2024-06-13T20:03:56.290548Z 0 [Note] [MY-000000] [Galera] Member 0.0 (db1) synced with group.
2024-06-13T20:03:56.290575Z 0 [Note] [MY-000000] [Galera] Processing event queue:…100.0% (1/1 events) complete.
2024-06-13T20:03:56.290590Z 0 [Note] [MY-000000] [Galera] Shifting JOINED → SYNCED (TO: 3491)
2024-06-13T20:03:56.290611Z 2 [Note] [MY-000000] [Galera] Server db1 synced with group
2024-06-13T20:03:56.290630Z 2 [Note] [MY-000000] [WSREP] Server status change joined → synced
2024-06-13T20:03:56.290646Z 2 [Note] [MY-000000] [WSREP] Synchronized with group, ready for connections
2024-06-13T20:03:56.395134Z 0 [Note] [MY-000000] [Galera] 1.0 (db3): State transfer to 0.0 (db1) complete.
2024-06-13T20:03:56.395585Z 0 [Note] [MY-000000] [Galera] Member 1.0 (db3) synced with group.
2024-06-13T20:03:56.768378Z 0 [Note] [MY-000000] [Galera] (0eed56b8-9060, ‘tcp://0.0.0.0:4567’) turning message relay requesting off
Bump.
Any hints at why the service file hangs by not recognizing that mysql actually starts?
there is no useful info in the log you provided,
Please follow @matthewb 's suggestion