How to manage MySQL or MariaDB service with systemctl in Linux

Managing the MySQL or MariaDB service is what turns configuration edits, crash recovery, and maintenance windows into controlled database changes instead of guessing whether the daemon is actually running.

On current Linux hosts that use systemd, the database server runs under a unit such as mysql.service, mysqld.service, or mariadb.service. systemctl is the standard interface for reading status, starting or stopping the daemon, changing boot behavior, and checking whether the service actually came back after a restart.

Package naming still varies by vendor and distribution, so the first step is to confirm the unit that exists on the local host. Current Oracle MySQL docs use mysql on Debian and Ubuntu packages and mysqld on RPM-based packages, while current MariaDB packages use mariadb.service and can also ship mysql.service or mysqld.service as aliases. Some MariaDB 10.6+ deployments also use systemd socket activation through mariadb.socket, so a new client connection can start mariadb.service again if that socket unit has been started for on-demand access.

Steps to manage MySQL or MariaDB service with systemctl in Linux:

Open a terminal with an account that can run sudo.
Identify the installed database unit before changing service state.
```
$ systemctl list-unit-files --type=service | grep --extended-regexp '^(mysql|mariadb|mysqld)\.service'
mariadb.service                              enabled         enabled
mysql.service                                alias           -
mysqld.service                               alias           -
```
Use the real unit shown on the left in the rest of the commands. Oracle MySQL packages typically use mysql on Debian and Ubuntu and mysqld on RPM-based systems, while current MariaDB packages use mariadb and may expose mysql or mysqld as aliases.

Review the full service status before a stop, start, or restart.

$ sudo systemctl status mariadb --no-pager
● mariadb.service - MariaDB 10.11.14 database server
     Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-09 21:46:41 UTC; 47s ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
    Process: 75 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
   Main PID: 117 (mariadbd)
     Status: "Taking your SQL requests now..."
      Tasks: 15 (limit: 94614)
     Memory: 196.0M (peak: 200.1M)
        CPU: 736ms

Replace mariadb with mysql or mysqld when that is the unit on the host. systemctl status is the quickest human-readable view because it shows the current state plus the most recent journal lines for the unit.

Stop the database service when the server must stop accepting connections.
```
$ sudo systemctl stop mariadb
```
Stopping the service drops active sessions and interrupts applications until the daemon starts again.

If MariaDB socket activation has been started with systemctl start mariadb.socket, a new local or TCP connection can start mariadb.service again. Stop mariadb.socket too when the server must stay down for planned maintenance.
Start the database service after maintenance or recovery work.
```
$ sudo systemctl start mariadb
```
Restart the database service when configuration or package changes need a full daemon restart.
```
$ sudo systemctl restart mariadb
```
A restart disconnects clients and can surface transient application errors while the server process exits and comes back.
Check quickly whether the unit is currently running.
```
$ systemctl is-active mariadb
active
```
systemctl is-active is the most useful quick check for scripts and runbooks because it returns success only while the named unit is active.

Read recent unit logs when the service shows failed, exits unexpectedly, or refuses to start.

$ sudo journalctl --unit=mariadb.service --no-pager --lines=20
Apr 09 21:47:31 dbhost mariadbd[389]: 2026-04-09 21:47:31 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
Apr 09 21:47:31 dbhost mariadbd[389]: 2026-04-09 21:47:31 0 [Note] Server socket created on IP: '127.0.0.1', port: '3306'.
Apr 09 21:47:31 dbhost mariadbd[389]: 2026-04-09 21:47:31 0 [Note] /usr/sbin/mariadbd: ready for connections.
Apr 09 21:47:31 dbhost systemd[1]: Started mariadb.service - MariaDB 10.11.14 database server.

Use the discovered unit file name, such as mysql.service, mysqld.service, or mariadb.service. journalctl shows more context than the short log excerpt inside systemctl status.

Disable automatic startup at boot when the host should not bring the database back after a reboot.

$ sudo systemctl disable mariadb
Synchronizing state of mariadb.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install disable mariadb
Removed "/etc/systemd/system/multi-user.target.wants/mariadb.service".

Use disable --now instead when you also want to stop the running service immediately.

Enable automatic startup at boot when the database should return with the host after a reboot.

$ sudo systemctl enable mariadb
Synchronizing state of mariadb.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable mariadb
Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service -> /usr/lib/systemd/system/mariadb.service.

Use enable --now if the service should also start immediately as part of the same change.

Confirm the boot-time setting after the enable or disable change.
```
$ systemctl is-enabled mariadb
enabled
```
Replace mariadb with the unit name discovered earlier. alias or static results usually mean the current unit name points to another service definition rather than being the primary boot target itself.