How To Perform MySQL/MariaDB Upgrades In cPanel Running CloudLinux with MySQL Governor

Check out our guide to learn how to perform a MySQL/MariaDB upgrade using MySQL Governor on your cPanel Server running CloudLinux.

On this page
  1. Prerequisites & References
  2. Stage 1 – ALWAYS Backup First
  3. Stage 2 – Remove MySQL Governor/DB Governor
  4. Stage 3 – Run MySQL/MariaDB Upgrade VIA cPanel/WHM
  5. Stage 4 – Reinstall MySQL Governor/DB Governor
  6. Finished

MySQL Governor & DB Governor are aliases and mostly interchangeable.

Database Governor from CloudLinux is a remarkable tool for keeping database resource usage under control for the plethora of sites that may be running on your cPanel servers. However, due to its nature, it throws a bit of a wrench into the process of upgrading your particular flavor of database software.

NameHero makes liberal use of the DB Governor product on all of our shared hosting servers, and thus we have worked out the best procedure for our teams to follow when performing database software upgrades on these busy systems. We can openly admit that this method is not the only method available. This is just the one we follow as it minimizes the risks while still leveraging the built-in tools available in your cPanel servers.

We use a four-stage procedure in our upgrade process. Each stage is a prerequisite of its previous stages and ensures that we maintain a solid path forward and, God-forbidding, backward should anything come crashing down. let’s go over the basic outline, shall we?

#Prerequisites & References

Today’s article depends on the knowledge contained within the following external documentation:

How to tell if you are running MySQL Governor?

If you are not sure whether your cPanel server is running MySQL Governor already, there are two easy ways to check.

Method 1 → Command Line

You can deduce the answer to the question based on the service status results.

service db_governor status

  • A missing/unknown service status means that DB Governor is not installed.
  • Otherwise, an active status means DB Governor is installed.

Example: MySQL Governor is NOT installed → A missing/unknown service Status

Code
~ $ service db_governor status
Redirecting to /bin/systemctl status db_governor.service
Unit db_governor.service could not be found.

Example: MySQL Governor IS installed → An active/enabled status

Code
~ $ service db_governor status
Redirecting to /bin/systemctl status db_governor.service
● db_governor.service - MySQL watcher service
   Loaded: loaded (/usr/lib/systemd/system/db_governor.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2023-12-28 11:50:41 CST; 57s ago
  Process: 3337005 ExecStopPost=/bin/sh -c if pgrep db_governor 1>/dev/null; then pkill -SIGTERM db_governor 2>/dev/null; fi (code=>
 Main PID: 3337048 (db_governor)
    Tasks: 1 (limit: 802244)
   Memory: 5.8M
   CGroup: /system.slice/db_governor.service
           └─3337048 /usr/sbin/db_governor

Method 2 → Web Browser

Step 1 ) Open WHM Interface

Log in to your server’s WHM Interface. If you are not sure how to access the WHM Interface, please review the following cPanel Documentation on the topic → How to access WHM.

Step 2) Open the MySQL/MariaDB Upgrade tool

Once inside the WHM Interface, you can quickly isolate the correct tool by searching for the term “maria” in the quick search box located at the top of the left navigation pane.

Step 3) Look for the following warning message:

If you do not see the warning message, then DB Governor is not installed.

#Stage 1 – ALWAYS Backup First

⚠ Caution: Do Not Proceed Without A Complete Backup!
Always be prepared for catastrophic failures, even on seemingly trivial tasks.

First and foremost, we have to create a full backup of the database data. This includes all databases, system tables, routines (a.k.a. stored procedures), and triggers. Having a pre-upgrade backup is the best way to ensure that you can recover adequately from any potential catastrophic data loss incidents resulting from human error or unexpected edge cases.

How to create a complete database Backup

There are many different ways to accomplish creating a backup like this. More so than we can cover in this topic. You will need to review your particular backup solutions product documentation to determine exactly how to go about creating your backup and restoration procedures. For NameHero, all of our servers are backed up nightly using JetBackup. Thus, we always have a full backup of all: databases, system tables, routines, and triggers from the night before.

Follow a proper maintenance plan

Having a proper maintenance plan is vital. What is equally important is knowing just when to schedule your event windows so that it makes the most sense for your business. For example, when performing a procedure that requires full backups first (which should be all maintenance plans, really…), we simply schedule the upgrade to occur in the hours after the nightly JetBackup has finished for that server.

This ensures that we have both the backups we need to recover from a problematic maintenance. Additionally, this practice ensures we are not leveraging additional server resources unnecessarily by running two separate backup processes that overlap and compete for resources with each other. So this stage in our maintenance plans is to simply confirm that the nightly JetBackup for that server was successful before proceeding.

#Stage 2 – Remove MySQL Governor/DB Governor

We know from the CloudLinux DB Governor Documentation that it’s possible to do in-place upgrades of your database software with the tools included in the DB Governor installation. However, we have found that those upgrades can become problematic, especially when you need to jump multiple major releases of the database software or switch between database software flavors like: MySQL, MariaDB, or Percona.

The manual procedure for jumping major releases requires repeatedly running through the entire upgrade process for each version change. This is time-consuming and prone to human error. So we eliminate those concerns by first removing DB Governor. This then enables us to directly leverage the native tools built-in to cPanel’s WHM interface for automating MySQL/MariaDB upgrades. The MySQL/MariaDB upgrade tool will automatically conduct any necessary incremental upgrades needed to get from your starting point to the target version you require.

How to remove MySQL Governor/DB Governor

Step 2.1) Open WHM Interface

Log in to your server’s WHM Interface. If you are not sure how to access the WHM Interface, please review the following cPanel Documentation on the topic → How to access WHM.

Step 2.2) Run the helper script in –delete mode

Run the following command to remove the db_governor service.

/usr/share/lve/dbgovernor/mysqlgovernor.py –delete

This sets your server back to using the standard MySQL/MariaDB binaries and service files and restores the ability to leverage the built-in MySQL/MariaDB Upgrade tool within WHM.

#Stage 3 – Run MySQL/MariaDB Upgrade VIA cPanel/WHM

🛑 STOP! – Do Not Continue Without A Complete Backup!

The following stage will guide you through running the MySQL/MariaDB Upgrade process via your cPanel server’s WHM interface.

Step 3.1) Open WHM Interface

Log in to your server’s WHM Interface. If you are not sure how to access the WHM Interface, please review the following cPanel Documentation on the topic → How to access WHM.

Step 3.2) Click On The MySQL/MariaDB Upgrade Tool

Once inside the WHM Interface, you can quickly isolate the correct tool by searching for the term “maria” in the quick search box located at the top of the left navigation pane.

Step 3.3) On Page → MySQL/MariaDB Upgrade (Step 1 of 5)

🛑STOP! — If you see the following warning:

Follow → Stage 2 – Remove MySQL Governor/DB Governor to disable MySQL governor.

In the Select a Version section, toggle the current cPanel “Recommended” version, (Unless you have a specific reason to use a different version) then click the [Continue] button.

Step 3.4) On Page → MySQL/MariaDB Upgrade (Step 2 of 5)

Review the context of each warning displayed and check the corresponding checkbox when satisfied and ready to proceed. After all confirmation boxes are checked, click [Continue].

Step 3.5) On Page → MySQL/MariaDB Upgrade (Step 3 of 5)

Choose the “Unattended Upgrade“ option and click [Continue].

Step 3.6) On Page → MySQL/MariaDB Upgrade (Step 4 of 5)

There is no (Step 4 of 5) when running the “Unattended Upgrade” option.

Step 3.7) On Page → MySQL/MariaDB Upgrade (Step 5 of 5)

Monitor the output of the upgrade process on this page until completed.
Stage 3 is now complete, move on to stage 4.

#Stage 4 – Reinstall MySQL Governor/DB Governor

In stage 4, we will re-install the db_governor service for the correct database software flavor and version to match what we just installed in stage 3.

Step 4.1) Open Command Line

Log in to your server’s command line Interface. If you are not sure how to access the command line, please review the following cPanel Documentation on the topic → How to access the command line.

Step 4.2) Install Database Control Utilities Package

Run the following command to install the DB Governor Control Utilities Package.

yum install governor-mysql -y

Step 4.3) Configure the correct version

Below you will find a comprehensive list of the different database software flavors that cPanel supports or has supported in the past. Choosing one will provide you with the correct command line snippet you will need to run in your terminal to select that particular software flavor & version for installation. This should be the same version you already installed back in Stage 3 – Run MySQL/MariaDB Upgrade VIA cPanel/WHM earlier.

MySQL v5.1

MySQL v5.5

MySQL v5.6

MySQL v5.7

MySQL v8.0

MariaDB v5.5

MariaDB v10.0

MariaDB v10.1

MariaDB v10.2

MariaDB v10.3

MariaDB v10.4

MariaDB v10.5

MariaDB v10.6

Percona Server v5.6

Auto Detect

MySQL v5.1 – Version Slug: mysql51

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql51

MySQL v5.5 – Version Slug: mysql55

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql55

MySQL v5.6 – Version Slug: mysql56

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql56

MySQL v5.7 – Version Slug: mysql57

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql57

MySQL v8.0 – Version Slug: mysql80

MySQL Governor1.2-37+ Required

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql80

MariaDB v5.5 – Version Slug: mariadb55

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb55

MariaDB v10.0 – Version Slug: mariadb100

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb100

**MariaDB v10.**1 – Version Slug: mariadb101

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb101

MariaDB v10.2 – Version Slug: mariadb102

⚠ Warning! — End of Life. Do not use in production environments.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb102

MariaDB v10.3 – Version Slug: mariadb103

⚠ Warning! — End of Life. Do not use in production environments.

MySQL Governor1.2-41+ Required

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb103

MariaDB v10.4 – Version Slug: mariadb104

MySQL Governor1.2-53+ Required

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb104

MariaDB v10.5 – Version Slug: mariadb105

MySQL Governor1.2-62+ Required

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb105

MariaDB v10.6 – Version Slug: mariadb106

MySQL Governor1.2-76+ Required

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb106

Percona Server v5.6 – Version Slug: percona56

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=percona56

Autodetect – Version Slug: auto

The following slug attempts to detect the DB flavor & version based on the OS & cPanel settings. Unfortunately, this slug is prone to error. If you encounter trouble, then you must specify the correct –mysql-version slug manually instead.

/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=auto

Step 4.4) Run the installer

After setting the correct software flavor and version in the previous step, run the following command to initiate the installation of db_governor service.

/usr/share/lve/dbgovernor/mysqlgovernor.py –install

Monitor the output of the above command to make sure it has succeeded. You can then confirm that the db_governor service is running with the following command.

service status db_governor

Stage 4 – Complete – If everything went well, you should have an updated database software installation alongside a running db_governor service.

#Finished

This concludes our guide on How To Perform MySQL/MariaDB Upgrades In cPanel Running CloudLinux with MySQL Governor. As mentioned earlier, this is not the only procedure to achieve these upgrades. However, we have found that it is the most reliable and straightforward method. Our teams run through this guide routinely to keep our database product stack running in tandem with the latest security standards these upgrades provide.

Photo of Jason Potter
Written by

Jason Potter

Jason Potter writes for the NameHero blog.

More from Jason →