Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.21
-
CentOS 7.3.1611
Description
SELinux is disabled. "datadir" points to a different location (/mysql/data).
Starting MariaDB via systemd fails with the following entries in /var/log/messages:
Feb 21 09:54:53 node3 systemd: Starting MariaDB database server...
|
Feb 21 09:54:54 node3 sh: 2017-02-21 9:54:54 140406696990976 [Note] /usr/sbin/mysqld (mysqld 10.1.21-MariaDB) starting as process 3448 ...
|
Feb 21 09:54:57 node3 sh: WSREP: Recovered position ded77f9d-d376-11e5-a55e-aafa472da560:34395298
|
Feb 21 09:54:57 node3 mysqld: 2017-02-21 9:54:57 139832490531072 [Note] /usr/sbin/mysqld (mysqld 10.1.21-MariaDB) starting as process 3481 ...
|
Feb 21 09:54:57 node3 mysqld: 2017-02-21 9:54:57 139832490531072 [Warning] Can't create test file /var/lib/mysql/node3.lower-test
|
Feb 21 09:54:57 node3 mysqld: #007/usr/sbin/mysqld: Can't change dir to '/var/lib/mysql/' (Errcode: 2 "No such file or directory")
|
Feb 21 09:54:57 node3 mysqld: 2017-02-21 9:54:57 139832490531072 [ERROR] Aborting
|
Feb 21 09:54:57 node3 systemd: mariadb.service: main process exited, code=exited, status=1/FAILURE
|
Feb 21 09:54:57 node3 systemd: Failed to start MariaDB database server.
|
Feb 21 09:54:57 node3 systemd: Unit mariadb.service entered failed state.
|
Feb 21 09:54:57 node3 systemd: mariadb.service failed.
|
It looks like systemd completely ignores the configuration.
Starting it via "mysqld_safe --verbose --user=mysql &" works like a charm:
170221 09:57:07 mysqld_safe WSREP: Running position recovery with --log_error='/mysql/data/wsrep_recovery.Yqi3QT' --pid-file='/mysql/data/node3.cluster.local-recover.pid'
|
2017-02-21 9:57:07 140438949714176 [Note] /usr/sbin/mysqld (mysqld 10.1.21-MariaDB) starting as process 3775 ...
|
170221 09:57:11 mysqld_safe WSREP: Recovered position ded77f9d-d376-11e5-a55e-aafa472da560:34395298
|
2017-02-21 9:57:11 139689894865152 [Note] /usr/sbin/mysqld (mysqld 10.1.21-MariaDB) starting as process 3816 ...
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: Read nil XID from storage engines, skipping position init
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so'
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: wsrep_load(): Galera 25.3.19(r3667) by Codership Oy <info@codership.com> loaded successfully.
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: CRC-32C: using hardware acceleration.
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: Found saved state: ded77f9d-d376-11e5-a55e-aafa472da560:34395298, safe_to_bootsrap: 0
|
2017-02-21 9:57:11 139689894865152 [Note] WSREP: Passing config to GCS: base_dir = /mysql/wsrep; base_host = 192.168.1.10; base_port = 4567; ...
|
...
|
2017-02-21 9:57:20 139689894546176 [Note] WSREP: Synchronized with group, ready for connections
|
Attachments
Activity
The datadir-option is not specified under the [mysqd_safe] - section.
Please find the server-specific settings, without wsrep- and innodb-specific options, attached: server-pas.cnf
My Ticket is possibly a duplicate of the MySQL-Ticket: https://bugs.mysql.com/bug.php?id=82709
Have you previously had mysql installed? The systemd implementation or mysql and mariadb is rather different.
Can you show/attach ```systemclt show mariadb.service```?
```journalctl -u mariadb.service``` might show some additional system information regarding the failed attempt at restarting the service.
We did a fresh-install on centos7. Please find the logs attached.
systemctl_show.txt
journalctl_mariadb.txt
Meanwhile we re-installed the system. It is working now.
Attached are the logfiles of the working system (for future reference). systemctl_mariadb.service_20170320.txt journalctl_mariadb.service_20170320.txt
Since the re-installed version is 10.1.22, while the failing one was 10.1.21, and that Galera is in use, it's quite possible that the problem was fixed by this commit:
https://github.com/MariaDB/server/commit/ea31755760
Could you please paste or attach your config file? Is it possible that your non-default datadir is configured in [mysqld_safe] section of the config file? In this case mysqld_safe would pass it over to mysqld, however when you start the server directly (like systemd does), it wouldn't even look into mysqld_safe options, and you'd get the exact error that you've got.