Almost all database work belongs in cPanel: creating databases, adding users, granting privileges. WHM holds the few decisions that apply to the whole server.
Which version the server runs
Under SQL Services → MySQL/MariaDB Upgrade, WHM shows the running version and offers upgrades.
Read the warning on that screen properly, because it is accurate: the upgrade is one-way. There is no supported downgrade, and the route back is restoring a dump into a freshly installed older version.
Before upgrading, take a full dump of every database on the server and confirm you can read it:
mysqldump --single-transaction --routines --all-databases > /root/all-$(date +%F).sql
Then check the applications. Older code occasionally relies on behaviour a newer version tightened, strict mode around empty values and zero dates is the usual one, and it surfaces as an insert that used to work and now returns an error.
What remote access actually means
By default the database accepts connections only from the server itself. Your website connects over localhost and nothing is exposed.
Remote access changes that: the database begins accepting connections from elsewhere, and anything that can reach the port can attempt to authenticate.
The dangerous shortcut is granting the host %, which is a wildcard meaning every address there is. It appears constantly in tutorials because it makes the immediate problem go away. What it leaves behind is a database endpoint on the public internet whose only defence is a password.
Grant one address
If someone genuinely needs to connect from a desktop tool, add that one address. In cPanel, Remote MySQL takes a host per account; in WHM, the server-level controls decide whether such connections are possible at all.
The requirement is a fixed address. Home connections usually are not fixed, and an address added today stops matching after the router reconnects, which is how % ends up in the list, as the second attempt after the first one stopped working.
The better answer is a tunnel
When the address is not fixed, do not open the database. Tunnel to it over SSH:
ssh -L 3307:127.0.0.1:3306 user@server
Point the local tool at 127.0.0.1:3307. The database keeps listening only to itself, the connection is encrypted, and the thing being authenticated is an SSH key instead of a database password reachable from anywhere.
This is the right answer often enough that it is worth trying first. Managing SSH keys in cPanel goes over the key side.
Server-wide settings worth knowing
WHM exposes the database configuration for the whole server. Two areas produce most of the real-world questions.
Memory allocation. The buffer pool decides how much of the working set stays in memory. On a busy server this is the single setting with the largest effect, and on a shared server it is also the one that, set too high, causes the whole machine to run out of memory in place of one site to run slowly.
Connection limits. A site that reports "too many connections" under load is usually not sized wrongly; it is usually failing to close connections, and raising the limit postpones the same failure to a larger number.
Where per-account work belongs
Creating databases, adding users and setting privileges are cPanel jobs, and doing them there keeps ownership and naming consistent with how the panel expects accounts to look.
Managing database users and privileges goes into granting the minimum a site actually needs, which matters more than any server-wide setting on this page: an application user with full administrative rights turns one SQL injection into a compromise of every database on the account.
Find out what is actually reachable
Before changing any setting, establish whether the database is listening beyond the machine at all.
ss -tlnp | grep -E '3306|3307' mysql -e "SHOW VARIABLES LIKE 'bind_address'"
An address of 127.0.0.1 means only this machine can connect and no allowlist entry will change that. A wildcard means the port is open to whatever the firewall permits.
Then test from somewhere else, because the server's own view is not the visitor's:
nc -zv -w 3 203.0.113.10 3306
A refused connection is fine. A successful one from an arbitrary machine on the internet is the finding, whatever the panel says about permitted addresses.
One wildcard grant undoes the allowlist
Access is decided in two places, and people configure one while assuming it is the only one.
mysql -e "SELECT user, host FROM mysql.user WHERE host NOT IN ('localhost','127.0.0.1')"
A user defined with a host of % may connect from anywhere that can reach the port. The panel's allowlist and the firewall are what stand in front of it, and either being relaxed for a moment exposes the account fully.
Define users against the specific address they connect from instead. It produces more entries and each one states plainly who may connect from where, which is a list you can review later. A single wildcard entry is not reviewable and tends to outlive the reason it was created.
Encrypt the connection if it leaves the machine
A database connection across the internet carries the credentials and every row of the result, and by default it may do so in the clear.
mysql -e "SHOW VARIABLES LIKE 'have_ssl'" mysql -e "SELECT user, host, ssl_type FROM mysql.user WHERE ssl_type = ''"
Requiring encryption per user is the setting that has effect, since supporting it and demanding it are different things. A user without that requirement will happily connect unencrypted.
Where the application permits it, a tunnel remains the simpler answer, because it removes the exposed port entirely rather than protecting it. SSH config, jump hosts and key agents goes into keeping that convenient.
When remote access stops working
It usually stops for one of four reasons, and checking them in order is faster than reconfiguring anything.
The address changed. A home or office connection with a dynamic address silently leaves the allowlist. This is by far the commonest cause.
The protection service intervened. Repeated failed attempts can block the address at the server level, which looks exactly like a firewall problem.
The entry was per account. Allowlist entries added inside one account do not apply to another.
The password expired or the user was recreated. A user rebuilt without the same host part connects from nowhere.
curl -s ifconfig.me; echo mysql -e "SELECT user, host FROM mysql.user WHERE user='appuser'"
Compare the address you are actually coming from with the entries that exist. cPHulk brute force protection deals with the second.