How to manage MySQL or MariaDB service in Linux

Managing the MySQL or MariaDB service is what turns planned maintenance, configuration changes, and recovery work into a controlled action instead of a blind restart during an outage. Knowing how to inspect the unit state, stop it safely, and bring it back cleanly reduces guesswork when the database has to go down or come back up.

On current Linux distributions, packaged database servers are usually controlled by systemd. Current MySQL documentation uses mysql.service on Debian and Ubuntu packages and mysqld.service on RPM-based platforms, while current MariaDB documentation uses mariadb.service. Once the correct unit name is known, systemctl handles start, stop, restart, status, and boot-time enablement, and journalctl shows the recent unit log lines tied to the service.

Restarting or stopping the service disconnects current clients, and changing boot behavior is separate from changing the live process state unless --now is used. The steps below stay focused on systemd-managed hosts, use mysql.service in the examples, and call out where mariadb.service or mysqld.service should be substituted.

1. Identify the installed database service unit before sending any control command.

   $ systemctl list-unit-files --type=service | grep --extended-regexp '^(mysql|mariadb|mysqld)\.service'
   mysql.service                                enabled         enabled

   Current MySQL docs use mysql.service on Debian-based systems and mysqld.service on RPM-based systems. Current MariaDB docs use mariadb.service, and some current MariaDB packages also install mysql.service and mysqld.service compatibility aliases. When multiple names appear, prefer the unit whose state is not alias.

2. Review the full unit status before or after a service change.

   $ sudo systemctl status --no-pager --full mysql.service
   ● mysql.service - MySQL Community Server
        Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; preset: enabled)
        Active: active (running) since Fri 2026-04-10 03:18:22 UTC; 8s ago
      Main PID: 966 (mysqld)
        Status: "Server is operational"
         Tasks: 38 (limit: 9396)
        Memory: 365.6M
           CPU: 348ms
   ##### snipped #####

   The status output shows the current Active state, the unit file path, the main database process, and the newest journal lines tied to the unit. Replace mysql.service with the canonical unit name found in the previous step.

3. Start the database service after maintenance or recovery work.

   $ sudo systemctl start mysql.service

4. Stop the database service when the server must stop accepting connections.

   $ sudo systemctl stop mysql.service

   Stopping the service terminates current client sessions and can immediately break applications that depend on the database.

5. Restart the database service when a full process restart is required.

   $ sudo systemctl restart mysql.service

   Use a restart for server binary, environment, or configuration changes that do not take effect in the running process. Expect a brief connection interruption during the restart window.

6. Disable automatic startup at boot and stop the server now when the host should stay down after reboot.

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

   Omit --now if the next reboot should leave the service disabled but the current instance should keep running until a separate stop.

7. Enable automatic startup at boot and start the server now.

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

   Use the matching canonical unit name on the host, such as mariadb.service or mysqld.service.

8. Read recent unit logs when the service fails to start, exits unexpectedly, or comes back in a degraded state.

   $ sudo journalctl --unit=mysql.service --no-pager --lines=50
   Apr 10 03:18:22 host systemd[1]: Starting mysql.service - MySQL Community Server...
   Apr 10 03:18:22 host systemd[1]: Started mysql.service - MySQL Community Server.
   Apr 10 03:19:04 host systemd[1]: Stopping mysql.service - MySQL Community Server...
   ##### snipped #####

   The unit journal usually shows the last permission error, missing file, bad option, or port/socket problem immediately before the final failure state.

   Related: How to view the MySQL or MariaDB server error log

9. Confirm the service is active after the change.

   $ systemctl is-active mysql.service
   active

   Common results include active, inactive, activating, and failed.

10. Confirm the boot-time setting after enable or disable changes.

    $ systemctl is-enabled mysql.service
    enabled

    Common results include enabled, disabled, alias, static, and masked.