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
- Stage 1 – ALWAYS Backup First
- Stage 2 – Remove MySQL Governor/DB Governor
- Stage 3 – Run MySQL/MariaDB Upgrade VIA cPanel/WHM
- Step 3.1) Open WHM Interface
- Step 3.2) Click On The MySQL/MariaDB Upgrade Tool
- Step 3.3) On Page → MySQL/MariaDB Upgrade (Step 1 of 5)
- Step 3.4) On Page → MySQL/MariaDB Upgrade (Step 2 of 5)
- Step 3.5) On Page → MySQL/MariaDB Upgrade (Step 3 of 5)
- Step 3.6) On Page → MySQL/MariaDB Upgrade (Step 4 of 5)
- Step 3.7) On Page → MySQL/MariaDB Upgrade (Step 5 of 5)
- Stage 4 – Reinstall MySQL Governor/DB Governor
- Finished
Prerequisites & References
Today’s article depends on the knowledge contained within the following external documentation:
- cPanel Documentation → How To Access The Command Line
- cPanel Documentation → How To Access WHM
- CloudLinux Documentation → MySQL Governor
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
~ $ 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
~ $ 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 – 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: mysql5
5
⚠ 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: mysql5
7
⚠ Warning! — End of Life. Do not use in production environments.
/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mysql57
MySQL v8.0 – Version Slug: mysql
80
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: mariadb10
1
⚠ Warning! — End of Life. Do not use in production environments.
/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb101
MariaDB v10.2 – Version Slug: mariadb10
2
⚠ Warning! — End of Life. Do not use in production environments.
/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb102
MariaDB v10.3 – Version Slug: mariadb10
3
⚠ 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: mariadb10
4
MySQL Governor1.2-53+ Required
/usr/share/lve/dbgovernor/mysqlgovernor.py –mysql-version=mariadb104
MariaDB v10.5 – Version Slug: mariadb10
5
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.
Jason Potter is a Senior Linux Systems Administrator & Technical Writer with more than 20 years experience providing technical support to customers and has a passion for writing competent and thorough technical documentation at all skill levels.
Leave a Reply