Comment 2 for bug 2003835

Some findings so far
(1) "strangely a first workaround for units such as keystone or neutron-api is to install the mysql client and through the CLI to connect at least once to the database with the logins generated by Juju. Strangely after that, the units are able to initialise their database."

(2) "on Jammy, deploying mysql-router to the original version (8.0.28-0ubuntu4) does fix the issue with pymsql. however this cannot be used as a workaround as the newer mysqlrouter.conf doesn't work with the old version. it was just a quick test that indicates maybe mysql-router is the problematic component". However I tested mysql-router 8.0.32 working fine in at least one case. so it's not the entire story.

(3) unattended-upgrades (if enabled) will restart mysql (server) automaically - different cluster members may or may not restart/upgrade at the same time.

juju run --application mysql/leader cluster-status # will show the current versions/if they are up.

(4) unattended-upgrades (if enabled) will not restart mysql-router in a charmed deployment as a custom systemd unit is created that is not restarted automatically by the postinst script, but will upgrade to the new version if restarted (e.g. systemctl restart keystone-mysql-router)