Skip to main content

So there's this blog post circling around, claiming full native systemd s...

- 2015-08-10T16:59:04+0000 - Updated: 2015-08-11T20:48:25+0000
So there's this blog post circling around, claiming full native systemd suport in MySQL. It's quite a stretch and not really true.

It boils down to MySQL shipping mysqld.service unit. It invokes database as Type=forking and does not even scratch systemd support.

At the minimum, MySQL should implement Type=notify behaviour. It would give perfect, 100% correct readiness notification. It would open a door to utilizing the watchdog, which is important for people caring about reliability. It would make sysadmins happier by providing extended status messages.

Above the minimum level would be to support for socket-activation. This is often asked by various people. It would bring fully implicit dependencies, make the database always available and allow for restarts without dropping any client connections.

The team behind the blogpost writes: ”It would be great if systemd provides some sort of generic readiness protocol without linking to their library”. Uhm, hello?  Systemd's protocol is extremally simple: get a socket location from an environment variable, open it and write a text string. You can't go more simple and generic than that! The protocol is fully described in ”man sd_notify”.

There's no need to link to systemd libraries if you don't want to. The protocol can be implemented in few lines of code in any given language. libsystemd is a great example how to do it – few concise lines of basic C. 
Even if you don't like LGPL-2.1+ license, you can grab liberally, MIT-licensed earlier version from systemd git.

To sum up, what's in MysSQL 5.7.6 is not a native systemd support.

Update 2015-08-11: MariaDB developers got systemd support right – (thanks +Clement Wong for spotting.) 

MySQL 5.7 -- Native Systemd Support

- 2015-08-10T18:03:54+0000
Yeah, they are saying that implementing double forking to have full daemonization was easier then sticking sd_notify("READY=1") in the right spot.

They also have a separate binary to pre-create directories and mysql cannot read its configuration from a config file, so environment variables have to be used.

But all in all, it doesn't look too bad. At least it doesn't do anything harmful.
- 2015-08-10T19:45:32+0000
a pity that i cannot share your posting rather than just the mysql link via g+. Stupid g+...
- 2015-08-10T19:52:50+0000
This is laughable brilliant! mysql natively supporting systemd my ass ;)
- 2015-08-10T20:12:25+0000
Besides the things I outlined in my comment on this blog post, I wrote regarding some more ugly things I stumbled across to the devs as the blog engine refused to accept any further comments:
- 2015-08-10T20:16:10+0000
+Zbyszek Jedrzejewski-Szmek writing persistent data to /tmp isn't something I'd call "At least it doesn't do anything harmful." :)
- 2015-08-10T20:41:58+0000
PrivateTmp=no is noop, since it's the default.

I couldn't tell from the unit file that it tries to write persistent data /tmp... But I would still say that it's not harmful (to others). It simply does not work.
- 2015-08-10T21:04:16+0000
+Zbyszek Jedrzejewski-Szmek I was referring to the mail conversation with the MySQL devs in the linked Gist.
Quoting the MySQL guys here directly:

[…] Replication and other parts of server saves file in /tmp and we don't those files to be removed during mysql restart or server reboot. […]

Nothing to add, I'd say :)
- 2015-08-10T21:07:55+0000
mysql was always about squeezing out every last bit of performance. Using tmpfs to store data might not make all happy though.
- 2015-08-11T10:03:58+0000
+Elias Probst whut?? oh lord, there go all our replicating mysql setups.


Comments powered by Disqus