liburing is a new optional dependency (WITH_URING=auto|yes|no)
that replaces libaio when it is available.
aio_uring: class which wraps io_uring stuff
aio_uring::bind()/unbind(): optional optimization
aio_uring::submit_io(): mutex prevents data race. liburing calls are
thread-unsafe. But if you look into it's implementation you'll see
atomic operations. They're used for synchronization between kernel and
user-space only. That's why our own synchronization is still needed.
For systemd, we add LimitMEMLOCK=524288 (ulimit -l 524288)
because the io_uring_setup system call that is invoked
by io_uring_queue_init() requests locked memory. The value
was found empirically; with 262144, we would occasionally
fail to enable io_uring when using the maximum values of
innodb_read_io_threads=64 and innodb_write_io_threads=64.
aio_uring::thread_routine(): Tolerate -EINTR return from
io_uring_wait_cqe(), because it may occur on shutdown
on Ubuntu 20.10 (Groovy Gorilla).
This was mostly implemented by Eugene Kosov. Systemd integration
and improved startup/shutdown error handling by Marko Mäkelä.
don't ignore LIBSYSTEMD_LDFLAGS when trying out systemd
(and put them in LIBSYSTEMD, because MYSQLD_LINK_FLAGS has stuff like
-lmtmalloc and is used only for mysqld, not for, say, explain_filename-t)
LIBSYSTEMD_LDFLAGS come from libsystemd.pc via pkg-config
special cases:
* change systemd detection to use CHECK_LIBRARY_EXISTS at least once,
to have it detected by build_depends.cmake
* similarly, use find_library for pam
* unixODBC is weird, libodbc.so is in the unixODBC package, not
in the unixODBC-devel, where normally all .so files belong.
Packaging bug? As a workaround, use find_file(sql.h) instead of
find_path(sql.h) to make sure that /usr/include/sql.h (not /usr/include)
is cached by cmake, and later build_depends.cmake will select
unixODBC-devel, as a package owning /usr/include/sql.h file.
Even if cmake can find pkg-config (e.g the one supplied with strawberry perl
), we cannot link with pkg-config-found libraries or use the headers -they
are mingw, 32bit-only.
The control file contents must be correct from the start and cannot
be modified at build time by CMake. Also all static Debian package
analyzers will fail to see all manipulations by CMake later on.
It is best to do all manipulations like these in autobake-deb.sh.
Galera recovery process works in two phases. In the first
phase, mysqld is started as non-daemon with --wsrep-recover
to recover and fetch the last logged global transaction ID.
This ID is then used in second phase as the start position
(--wsrep-start-position=XX) to start mysqld as daemon.
As this process was implemented in mysqld_safe script, the
recovery did not work when server was started using systemd.
Fixed by introducing a shell script (wsrep_recovery.sh) that
mimics the first phase of the recovery process.
Use galera_new_cluster instead. systemctl start mariadb@bootstrap
will generate error message, use_galera_new_cluster.conf is the name
of the file that will generate this error.
Output:
Job for mariadb@bootstrap.service failed. See "systemctl status
mariadb@bootstrap.service" and "journalctl -xe" for details.
● mariadb@bootstrap.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb@.service; disabled;
vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/mariadb@bootstrap.service.d
└─use_galera_new_cluster.conf
Active: failed (Result: exit-code) since Thu 2015-10-15 19:27:52
CEST; 5s ago
Process: 24334 ExecStart=/usr/bin/false (code=exited,
status=1/FAILURE)
Process: 24330 ExecStart=/usr/bin/echo Please use galera_new_cluster
to start the mariadb service with --wsrep-new-cluster (code=exited,
status=0/SUCCESS)
Main PID: 24334 (code=exited, status=1/FAILURE)
Oct 15 19:27:52 spaceman systemd[1]: Starting MariaDB database server...
Oct 15 19:27:52 spaceman systemd[1]: mariadb@bootstrap.service: main
process exited, code=exited, status=1/FAILURE
Oct 15 19:27:52 spaceman systemd[1]: Failed to start MariaDB database
server.
Oct 15 19:27:52 spaceman systemd[1]: Unit mariadb@bootstrap.service
entered failed state.
Oct 15 19:27:52 spaceman systemd[1]: mariadb@bootstrap.service failed.
mariadb-service-convert during migration can create a file containing
ExecStartPre=/usr/sbin/sysctl -q -w vm.drop_caches=3 if the users my.cnf
contains [mysqld_safe] flush_caches. This sysctl entry change requires root
access. No existing ExecStartPre requires execution requires execution
as another user.
There is a comment in the mariadb{,@}.service.in that indicates
mysqld_install which would require -u mysql to explicity change user to
mysql from root since PermissionsStartOnly=true.
Otherwise the following error would be generated:
Oct 14 07:38:38 spaceman systemd[1]: Starting MariaDB database server...
-- Subject: Unit mariadb.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has begun starting up.
Oct 14 07:38:38 spaceman sysctl[10089]: sysctl: permission denied on key 'vm.drop_caches'
Oct 14 07:38:38 spaceman systemd[1]: mariadb.service: control process exited, code=exited status=255
Oct 14 07:38:38 spaceman systemd[1]: Failed to start MariaDB database server.
