Databases and phpMyAdmin

Nearly every website keeps its content in a database: WordPress, a webshop, a forum. This page shows how to create one, who may reach it, and how to look inside.

Screenshot — Panel → Hosting → Accounts → your account → Databases. The page has three parts: Databases, Database users and Grants. Screenshots are captured with openwolf designqc into .wolf/designqc-captures/.

Two things, not one

It helps to keep them apart:

• A database is the cupboard the data sits in.
• A database user (or login) is the key to that cupboard.

An application always needs both, plus the agreement about who may open which cupboard. That last part is called grants.

Both names automatically get your account name in front. Fill in shop on an account called web1 and the database is called web1_shop. That is not decoration — it is what stops two customers on the same server from claiming each other's database name.

Which database server is running

Above the list sits a badge with a glyph in front of it, for example MARIADB 10.11. That is the engine your databases live in, and its version — useful when an application's install guide names a minimum.

MariaDB and MySQL share one glyph. That is not sloppiness: they speak the same protocol, they read the same settings file, and every button on this page works identically on both. What is actually running is in the name and the version number in the badge itself. The glyph is our own drawing and not the vendor's logo; see The design system.

If there is no badge at all, the server has not reported yet — reload the page, or ask your hosting provider if it stays that way.

The Database server panel, under the lists

Below the two lists sits a small panel that names the machine itself:

• Server — the machine's own name, for example db2.corecp.dev, with a copy button. This is the first thing support asks for, and it is the name you use if you ever connect from somewhere else.
• Version — the engine and its version, with a label beside it:

Under it, one sentence with the date: "MariaDB 10.11 LTS is frozen: security and bug fixes until 2028-02-16, no new features."

If your website and your database are on two different machines, a second line says so and names the host to put in your configuration file. In that case it is the server's name and not localhost.

Moving to another version

A database server runs one version and it is never changed underneath your databases — that is not something the makers of MariaDB support. Moving to another version means moving your database to a machine that already runs it, which your hosting provider does for you: your data is copied across, checked row by row, and only then does the old copy go. Nothing on this page changes; the Server and Version in the panel are what tell you it happened.

Creating a database

1. Click Create database.
2. Fill in a name: letters, digits and underscores only. The account name is already in front.
3. Click Create.

You get a database and a login of the same name in one go. The password is generated by the server and shown once, on a card with a copy button. CoreCP keeps it nowhere.

corectl db add web1 shop        # creates web1_shop, with login web1_shop
corectl db list
corectl db passwd web1_shop     # a new password, again shown once
corectl db remove web1_shop

This is exactly what wp-config.php or an .env file needs:

DB_NAME     web1_shop
DB_USER     web1_shop
DB_PASSWORD (the password you just saw)
DB_HOST     localhost

localhost is right: applications on the same server talk to the database over a socket, not over the network.

Choosing a password yourself

Below the name there is a Password question. By default CoreCP makes one, and that is the better choice: a generated password is stronger than one somebody thought of. Pick I will fill one in myself and a field appears, with a generator button beside it. At least ten characters.

Why you might want to: the password is already in a configuration file you would rather not touch, or you are putting a site back from another server.

What you do not get then is the card with the password on it — you typed it yourself a moment ago, and CoreCP stores it nowhere. Not in a log, not in a task list, and not in the audit trail: that records only that you created a database.

A database on a login you already have

If this account already has one or more logins, a second question appears above the password: Login. By default the new database gets a new login with the same name. Pick A login that already exists and nothing new is made: the login you point at gets full access to the new database and keeps the password it already had.

That helps: one application with four databases then has to know one password instead of four.

On the command line that is --user, with the full name:

corectl db add web1 reporting --user web1_app

The password question disappears from the form when you do, because nothing that needs one is being created.

When your package is full

Your package can set a maximum for databases and another for database logins. Once you are at it, the Create a database button is greyed out with the reason beside it: "Your package allows 3 databases, and all of them are in use." You no longer have to think of a name to be told it cannot be done.

The two are counted separately. A package can be out of databases and still have room for logins, or the other way round.

What you can do:

• Remove a database you no longer use. The button comes back as soon as it is gone.
• Ask your hosting provider for a larger package. Moving to another package changes nothing about what is already there.

If your package sets no maximum, there is no limit — and nothing to see.

Rare: if you are told "this package could not be read", something is wrong with the package itself and the panel is refusing to be safe. It deliberately lets you create nothing while it does not know your limit. Try again in a minute, and report it to your provider if it stays.

A second login for the same database

Sometimes you want an extra login with fewer rights — a reporting tool that may only read, say. Then you create a login without a database and grant it access afterwards.

1. Go to Database users and click Create login.
2. Go to Grants, pick the database and the user, choose read only and click Apply.

corectl db user add web1 reporting                                    # → web1_reporting
corectl db grant web1_shop web1_reporting --account web1 --privileges readonly
corectl db grant list web1_shop --account web1
corectl db revoke web1_shop web1_reporting --account web1
corectl db user remove web1_reporting --account web1

The three levels in the panel:

Opening phpMyAdmin

Click phpMyAdmin on a database. A new tab opens in which you are already signed in — you type no password. The ticket behind it is single-use and expires within ninety seconds.

What you are signed in as

Not as your database's own login, and that saves you a risk. For that one click the server creates a temporary login that may only touch the database you opened, and cleans it up again afterwards. You can see it in the top left of phpMyAdmin as ccp_sso_….

What that means for you:

• Your own database password never reaches your browser, so it is not in your browsing history or in a server log either.
• If such a link does end up with somebody else, the worst case is a login that may touch one database and will not exist tomorrow.
• To connect with anything else — your application, a tool on your own computer — you still use your own login and password. Nothing here changes that.

"You are not signed in", right after you clicked

For a while the button ended on phpMyAdmin's login screen. The sign-on itself was fine; what went wrong was the redirect after it — a browser does not send a fresh session cookie along when the visit came from another website, and the panel is another website than the server phpMyAdmin runs on. The sign-on page no longer redirects and shows you phpMyAdmin straight away.

corectl phpmyadmin signon web1        # a single-use sign-on from the command line
corectl webapps status                # is phpMyAdmin served on this node?
corectl webapps set --phpmyadmin on

If you do not see the button, this server does not offer phpMyAdmin. That is your hosting provider's choice; ask them about it. Note the difference between switched on and served: a server that changes webserver keeps the setting while nothing answers on phpmyadmin.yoursite.com any more. The panel shows the button only in the second case — otherwise it would land on the parked page.

corectl --json webapps status | grep served    # is it actually offered?
#   "served": false
corectl phpmyadmin signon web1                 # then it refuses honestly
#   phpmyadmin_not_served: phpMyAdmin is configured but the litespeed provider
#   does not render its vhost; nothing is served

Your databases keep working: an application on your site connects as usual, and import/export works from the panel buttons or the command line.

When your databases are on another server

When your databases live on a separate database server, there is no web server there and so no phpMyAdmin. The phpMyAdmin button still works: you land in phpMyAdmin on the server your website lives on, which connects to the database server. The temporary login made for that may only connect from that web server, and goes away by itself.

If you get a message that your server cannot show phpMyAdmin, ask your administrator to turn phpMyAdmin on for your website's server.

What is inside a database

Click a database and you get its detail page: how big it is, how many tables it holds, which collation it uses, and a list giving each table's storage engine, row count and size.

Size        12.4 MB   (measured 3 minutes ago · Measure again)
Contents    41 tables, 1 view, 1 routine, 1 trigger
Free space  1.1 MB    (reclaimable with Optimize)

Why does it say "measured 3 minutes ago"? Because the size of a database is not stored anywhere: the server has to work it out, and on a database with many tables that takes noticeable time. So we work it out once, keep the answer, and say honestly how old it is. If you want this moment's number, click Measure again — it takes a while, which is exactly why it is a button and not something that happens on every page load.

After a maintenance run (below) the measurement is retaken automatically, so the number you see afterwards is current.

On the command line:

corectl db detail web1_shop --account web1
corectl db detail web1_shop --account web1 --refresh      # measure now

Maintenance: check, optimize, repair

The detail page has two or three buttons under Database operations. You see what is happening per table as it happens — the lines arrive while it runs, not only at the end.

Why can't I see "Repair"? Because your database does not need it. REPAIR TABLE only exists for the older storage engines (Aria, MyISAM, CSV). If everything runs on InnoDB — which on a modern WordPress or webshop site it almost always does — the database repairs itself, and the button could only ever produce an error message. So we leave it out rather than grey it out: a button that is there and cannot work is worse than no button.

Optimize skips views (there is no storage under one) and says so, so you are not left looking for a table that seems to be missing.

corectl db check    web1_shop --account web1
corectl db optimize web1_shop --account web1
corectl db repair   web1_shop --account web1

Only certain tables

Above the three buttons is one sentence saying what will be covered: "Runs over all 41 tables." Press Choose tables, tick the ones you want, and the sentence follows: "Runs over 2 of the 41 tables." Clear selection puts you back to the whole database in one press.

That is what you want when a single table has swollen — a log table you have just deleted hundreds of thousands of rows from — and you would rather not have the rest rebuilt for twenty minutes.

corectl db optimize web1_shop --account web1 --tables wp_options,wp_postmeta

Name a table that does not exist and the whole command is refused rather than half done. That is deliberate: otherwise you would read "0 B reclaimed" as an answer about your table when it is an answer about your typo.

What you get back

When the round finishes, What it did says which tables were covered and how much space came back. That figure is there even when it is 0 B: that is a real answer — there was nothing to reclaim — and it is exactly what you wanted to know when you pressed the button.

That figure is a real measurement: the size of the tables the round rebuilt, before it minus after it. Tables you did not choose do not count, so a large import that the database server is still adding up cannot cancel it out. To make the subtraction mean something, Optimize takes a fresh look at the tables it is about to rebuild first. The database server keeps its sizes rather than counting them again on every question, and an old "before" beside a fresh "after" reported 0 B reclaimed on rounds that had in fact freed space. That look costs a fraction of a second and changes nothing about what the round does.

Maintenance only ever starts because you pressed something. The panel schedules nothing and starts nothing by itself; a signal on the detail page takes you at most to the tab where the button lives.

On the Databases list every row has a small menu (the three dots) with Maintenance in it, so you can get there without opening the database first.

Access from elsewhere (extra addresses)

By default a database login may only connect from the server itself. That is what your website does, and for most sites it is the whole story.

To connect with a database client on your own computer, or with a reporting tool on another server, add that address: Database users → a login → Access hosts → Add address.

corectl db host list   web1_shop --account web1
corectl db host add    web1_shop '203.0.113.%' --account web1
corectl db host remove web1_shop '203.0.113.%' --account web1

What to know:

• The password stays the same. An extra address is the same login, now also reachable from there. Nothing needs setting up again.
• % is a wildcard. 203.0.113.% means any address in that block; % on its own means anywhere in the world. That is allowed, and the screen marks it as a wildcard — but prefer your own fixed IP address.
• localhost cannot be removed. It is the address your own website connects on.
• Thirty fit. More is almost always a list nobody prunes.
• The port has to be open too. Adding an address gives the login permission; whether port 3306 is reachable from outside is the server's firewall. Ask your hosting provider if the connection just hangs.

Exporting (making a copy)

In the panel — open the database and click Export. The panel stays open while the export runs, and when it finishes the Download button is in it: one press and the file comes to your computer. The file also stays in your own backups/db/ folder, so you can leave it there for your own backups, or fetch it later through the file manager, FTP or SFTP.

Lost the panel — an export of a large database takes a while — and the same download button is on the task: Tasks in the menu, click the export. Two choices come with the export itself:

• Compress (gzip) — on by default. A SQL file shrinks about tenfold.
• Make it loadable on another server — on by default. Leave it on if you are going to restore the file somewhere else (see below).

If you have set up your own backup destination (S3, FTP, Dropbox, Google Drive), the file can be copied there in the same go.

In the terminal:

corectl db export web1_shop --account web1
corectl db export web1_shop --account web1 --gzip=false     # plain .sql
corectl db export web1_shop --account web1 --dest offsite   # also to your destination
ls -lh ~/backups/db/

With phpMyAdmin — open the database, tab Export, method Quick, format SQL, and click Go. Fine for a small database; for a large one the panel button is more reliable, because a browser cannot stop halfway through.

"Make it loadable on another server" — what does that change?

A database copy describes not only your data but also, a little, the server it came from. Three of those descriptions make the file refuse to load elsewhere — at another host, on your own laptop, or on a server running Oracle MySQL instead of MariaDB:

1. The owner of views and routines. The copy names a login that only exists on this server. Elsewhere that is ERROR 1227.
2. The name of a sort order. Since version 11.4 MariaDB uses a name MySQL does not know: ERROR 1273: Unknown collation.
3. A server setting MySQL 8 dropped. ERROR 1231.

With this option on, all three are replaced by something both databases understand, and you are told afterwards exactly how often that happened. The copy also carries no CREATE DATABASE and no USE, so you can restore it into any database:

zcat ~/backups/db/web1_shop-20260813T104502Z.sql.gz | mysql web1_other

Restoring onto this same server and want the file kept verbatim? Use --portable=false.

Importing (putting a copy back)

A dump from your old host, a colleague's backup, or your own export from last week: the panel reads the file first, tells you what it found in it, and only then lets you press import.

Step by step

1. Open the database it has to go into: Databases → click the database.
2. Press Import a database. Under From this computer, choose the .sql or .sql.gz file on your own machine. If the dump is already on the server — because you uploaded it over FTP or SFTP, or because it is your own export — click it under Already in backups/db, or type the path.
3. Press Upload. The file goes to the backups/db folder in pieces. You see how much has been sent, and above the button how much disk space you have left.
4. Choose what happens to what is in there now: Keep it (the default) or Erase it first.
5. Press Read the file first. The server now reads your dump end to end and says what it meets. Nothing has been loaded yet.
6. Read what it says, then press Import now. You see line by line what happens.

When the connection drops

A dump of a few hundred megabytes over wifi that cuts out is exactly what this was built for. The panel says "The upload stopped at 142 MB." and puts two buttons under it:

• Continue — the panel asks the server how much really arrived and sends the rest. You do not start over.
• Start over — for when you changed your mind, or want to send a different file.

If the file does not fit in your disk space you are told before the transfer starts, with the numbers: "The dump is 320 MB and 41 MB is free."

An upload you break off half way leaves a small file starting with .corecp-part- in the same folder. That is the half that arrived; it counts against your disk space and you may delete it through Files like anything else. Send the same dump again from the start and it is simply overwritten.

What the warnings mean

Keep or erase first

• Keep it (the default): the dump is added to what is already there. A table that is in the dump and already exists is overwritten.
• Erase it first: every table, view and routine goes before the load. This is the only thing on this screen that can lose data, so you type the name of the database to confirm it. Take an export first if you are unsure.

Your database logins and their passwords survive either way — they belong to the database, not to its contents.

Cleaning up afterwards

When the import finishes the panel asks whether the dump may go: "backups/db/… is still on the server." with a Remove the dump button. It goes to the wastebasket, so you can still get it back from there.

The panel never throws it away by itself. That dump is also the only copy of what you have just loaded, and whether that is a backup you want to keep is yours to know, not the panel's. Nothing is asked about a file that was already there before you started — that one is yours.

On the command line

# see what is in it first, without loading anything
corectl db import analyze web1_shop backups/db/shop.sql.gz --account web1

# and then for real
corectl db import web1_shop backups/db/shop.sql.gz --account web1
corectl db import web1_shop backups/db/shop.sql.gz --account web1 --wipe

The path is always relative to your own home directory: the server reads the file as you, so anything outside your own folders simply does not exist for this command.

And phpMyAdmin? Still there, and fine for a small file. Above that the browser hits its upload limit, and phpMyAdmin does not read your dump first.

What your application connects with

The Connecting tab on a database's page holds the four things you fill into wp-config.php, .env or your database client, each with a copy button:

Host            localhost
Port            3306
Database name   web1_shop
Socket          /run/mysqld/mysqld.sock

Use what the tab says. Usually that is localhost: your website is then on the same machine as the database, and with the server name it works from nowhere. To connect from your own computer you open an access address (above) — localhost stays what the site itself uses.

Is there a server name instead? Then your database is on a different machine from your website, and that name is the right answer:

Host            stck2.corecp.dev
Port            3306
Database name   web1_shop

The screen says so out loud: "Your website is on a different server from your database." There is nothing to arrange for it — the access and the firewall between those two machines were set up when your account was created.

The password is not there, and that is not an omission: we do not store it. Lost it? Set a new password on the login and put that in your configuration.

A login that may only read

For a reporting tool, a dashboard or a colleague who wants a look, you rarely want a login that may do everything. The Connecting tab has a Read-only login button: give it a name and you get a login that may read everything in this database and change nothing in it. You see the password once.

corectl db user add web1 reporting
corectl db grant web1_shop web1_reporting --account web1 --privileges readonly

Signals on the detail page

Under Signals is what stands out about your database. Nothing there is ever repaired for you — they are observations, not tasks.

How much are you allowed?

The number of databases comes from your hosting plan; you see it on the account overview. Beyond that the server caps the number of concurrent connections and queries per hour per account, so one busy site cannot flatten the rest.

corectl db limits show web1

If you see "too many connections", it is nearly never a full database — it is an application that does not close its connections properly.

When something is not right

If phpMyAdmin does not open

The Open phpMyAdmin button does the same thing as the webmail button: it asks the server for a one-time ticket and opens a new tab with it. Here too the tab was requested a fraction too late, so the browser refused it and the button appeared to do nothing. That is fixed.

If you get an amber message within a second instead — the server is busy with another change, so signing in did not start; nothing was changed — nothing is broken: signing in is a change too and stands in the same queue as the rest, and the machine will be done with it shortly. Try again in a moment. Until recently you watched "signing you in…" for up to a minute in that case and then got the same answer.

If you do not see the button at all, phpMyAdmin is not installed on the server your account is on. Ask your hosting provider; this is how they check:

ssh root@stck1.corecp.dev 'corectl db phpmyadmin status'
ssh root@stck1.corecp.dev 'corectl db phpmyadmin install'

If the tab still does not open while the button is there, your browser is blocking pop-ups for the panel's address. Allow them for that one address.

A folder that points out of your home

When the server creates a folder for you in your home directory (the backups/db folder a database export is written to), it does not follow a link that leads out of your home. If you replaced such a folder with a link to somewhere else on the server, the action is refused and says why. Remove the link, or let it point inside your own home, and try again. A link that stays inside your home, like the document root an import leaves behind, works as before.

See also

• The web terminal — where mysql and mysqldump run.
• Files, FTP and SSH — where you fetch the export file (backups/db/).
• Your own backups — a backup of your account contains your databases.
• Installing WordPress — the database is created for you there.

Why the server sometimes gets faster on its own

On servers where your provider runs the database tuning agent, the database's own settings are reviewed and, when the provider accepts a recommendation, changed. That is a server-level thing: it affects how much memory the database keeps for caches and how many connections it holds ready, not anything about your databases or their contents.

Two things worth knowing:

• It cannot break your data. A change that stops the database is undone automatically — the server restores the previous settings, restarts and checks that the database answers before it calls the change done.
• Your own slow queries are not part of it. The tuner looks at the server as a whole. To see which of your queries were slow, open the slow database queries log for your account in Reading logs — that one is scoped to you and to nobody else.

If a query of yours is slow, no amount of server tuning fixes it: an index does.

What database tuning changes on your server

When your administrator turns database tuning on, it does not edit the database server's existing configuration in place. It writes a separate settings file beside it, and the original configuration is left alone.

That is deliberate: putting one file back is nothing at all, whereas unpicking a change from the middle of somebody else's configuration file never is.

ssh root@stck1.corecp.dev 'corectl db tuner status'

engine     MariaDB 11.8 (Ubuntu LTS)
applied    9 setting(s), 14 Aug 2026 09:12
file       /etc/mysql/corecp.conf.d/z_aiops_mysql.cnf
previous   kept — corectl db tuner revert puts it back

Going back to how it was is one command:

ssh root@stck1.corecp.dev 'corectl db tuner revert'

The file is readable by the database server itself, because that is what has to read it — nothing secret is kept in it. Your exports are stored differently: they hold your own data, and only their owner can read them.

Where an export ends up, and who may read it

An export is a copy of your database, so it is written with the narrowest permissions there are: the owner reads it and nobody else on the server does.

ssh root@stck1.corecp.dev 'ls -l /var/backups/corecp/acc-1/'

-rw------- 1 root root 1.2M Aug 14 09:13 acc1_shop.sql.gz

Downloading it through the panel sends it over the secure connection, and nothing is left behind on the server once the download finishes.

A new password: where it appears

Passwords the server makes for you are shown once. So they always appear where you asked for them, and not somewhere else on the screen:

• Ask for a new password in a database user's own panel and that panel stays open, with the card carrying the password in the middle of it, above the button you just pressed.
• Create something new and that panel closes itself the moment it worked, and the card is on the page underneath — which is what you are looking at by then.

Copy it or write it down straight away. If you lose it there is no way to get it back; there is only a way to have a new one made.

If something goes wrong you see it in exactly the same place: the message is in the panel where you pressed the button, not on the page behind it.

The server's own databases, and why you do not see them

Besides your databases, a server keeps a few records of its own: the mail list the mail server reads from, the nameserver's zone data, and the webmail's settings. You do not see them in your list and they do not count against your plan's limit — they are not a customer's databases.

On servers your administrator has converted they are also no longer in the same database server as yours. That has one consequence you may notice: if your administrator ever switches database engine (MariaDB to MySQL or back), only customers' databases move. Mail delivery and the nameserver keep running right through such a switch.

Your own databases stay exactly where they were. After a maintenance notice, feel free to check that your site still connects:

mysql -h localhost -u youruser -p yourdatabase -e "SELECT 1;"

If that returns 1, nothing changed on your side. If you get an access error, your password is the first thing to check — server maintenance does not change it.

Where the database software comes from

MariaDB or MySQL comes to a server from the same package source as CoreCP itself, as the installer recorded it on the server — not from a fixed address in the software. A server without a recorded source refuses to install or switch the database software and says what has to be set. Example names in error messages, such as db1.example.net, are examples.

After a database update: the one step that goes with it

MariaDB keeps, beside your data, the version that data was last brought into step with. When that falls behind the database server now running, one step goes with it: the system tables are checked and repaired where needed, and the new version is written into that little file. Whether it is needed is MariaDB's own judgement — not for an ordinary patch inside the same branch, yes for data that is a release behind.

Normally the package does this itself. But only when the database server happens to be running at that moment. If it was stopped during the update, it comes back running newer software over an older schema. The database keeps working, says something about it in its own log, and nobody else notices.

Since this release CoreCP does that step itself, during the nightly maintenance run, straight after the packages. You do not have to do anything.

If it is still outstanding — because the maintenance run is switched off on that server, for instance — you will see it under Servers → the server → Checklist as Database upgrade step, with the command beside it. If you do not want to wait for the night:

corectl maintenance run --now

If the question cannot be asked at all (the database server is not running, or it does not answer), that row says so rather than saying it is fine. A check that could not look is not a check that passed.

This is MariaDB. MySQL does this work itself on first start after an update and has no separate step.

Where phpMyAdmin itself comes from

Out of CoreCP's own application mirror since this release, and no longer straight from files.phpmyadmin.net while your server sets it up. phpMyAdmin runs with a database login in its session, so what arrives matters: the digest of every release is recorded in CoreCP's own source, checked against both upstream's checksum file and the project's OpenPGP signature, and a file that does not match that digest is refused rather than installed.

Nothing changes in how you use it — the same button, the same one-time sign-on described above. Installing applications explains the mirror itself.

Where the database server comes from on production

A production server installs MariaDB 10.11 or 11.4 and MySQL 8.4 from the mirror of its own package source (the production panel), which fetches the series from the build server, verifies it and serves it re-signed — never straight from mariadb.org or Oracle. The series Ubuntu ships itself (11.8) simply comes from Canonical. Since round 6 the mirror of the 11.x series also carries the two -compat packages that provide the familiar mysql, mysqladmin and mysqldump names; without them the platform could not reach a fresh 11.4 server. Nothing to do on your side; Managing releases → The mirrors shows which snapshot the source serves.