Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.1.20
-
Debian 8 x64
Description
To start multiple instances of MariaDB, you added a /lib/systemd/system/mariadb@.service, indicating that we must create config file for the second daemon in /etc/mysql/conf.d/my{instancename}.cnf.
But this file is read by the main daemon! In /etc/mysql/my.cnf, we found at the bottom:
!includedir /etc/mysql/conf.d/*
So the main daemon:
- reads the port/socket/etc. from my.cnf
- change those values later when reading my{instancename}.cnf
I you comment the !includedir and add as many !include /etc/mysql/conf.d/{conf}.cnf you have, it works as expected.
To my mind, the "clean" way of fixing it si to read those my{instancename}.cnf files from /etc/mysql, and NOT from /etc/mysql/conf.d.
Attachments
Issue Links
- causes
-
-
- Closed
-
Activity
Hello,
yes, to my mind it is a good idea to have suffixes. It is a clean way to configure the server.
Seems this might be the very very last pre-GA chance to change this to a saner implementation. I have used this in anger (like MDEV-15685) and its quite flexible.
+1
Ubuntu 16.04
This prevented the default service from starting when upgrading to the latest version of mariadb-server while using multiple instances.
On ubuntu the install script does not seem to handle multiple instances at all and refuses to install if it can't stop mysql.service (which on my install has been disabled in favor of using the multiple instances).
When I attempted to start mysql.service it tried to load the last server instance and naturally can't because the socket is already in use. So I was left with a broken system and needed to edit the mariadb@.service file to change the path to the instance configuration files.
Thanks for your feedback ProCycleDev.
There are probably some lingering issues with multiinstance in the packaging that need to be addressed however I though this was a good start.
MDEV-12646 covers a lot of these issues for single instance.
The associated PR removes Galera support from the systemd template unit file because of some unspecified problem with the SST scripts. I don't personally think that Galera support should be removed.
What is the specific problem that the SST scripts have with the systemd template unit file when managing multiple instances?
GeoffMontee, no problem with Galera support (though I didn't explicitly test it) was hoping the removal would make it easier to assess/merge however this doesn't seem to be the case.
pr #1143 / MDEV-19210 is quite compatible with the pr #510 (https://github.com/MariaDB/server/pull/1143#issuecomment-472393702) and I forsee merging both would maintain Galera support correctly in multiinstance scripts. Rather than trying to line up out of tree patches that wait for considerable months/years I'm going leave it to axel to manage the merging debt.
axel apologies for bullying this into 10.4, it had the wrong Fix Version and the foundation finally tested and reviewed in February 2019 along with other users. The faults that this fixes has left have lingered too long in major versions and really needs to a pre GA release.
Apologies Worst - does https://github.com/MariaDB/server/pull/510 look acceptable?