All documentation
  1. Home
  2. Docs
  3. Databases

Databases

One database, one user, granted on that database only, from localhost. Root stays on the Unix socket and no credential is shared between sites.

Creating a database

klyrn db list
klyrn db create acme acme_wp
klyrn db user-add 3 acme_wp2      # a second user on database 3
klyrn db password 5               # reset a user's password
klyrn db user-delete 5
klyrn db delete 3

A WordPress site creates its database and user as part of klyrn site create; you only need these commands for extra databases or extra users.

A name that does not match the allowed pattern is refused, and so is one starting with -: the MariaDB client would read a leading dash as one of its own options rather than as a database name.

Exporting

klyrn db export acme_wp     # run the dump
klyrn db exports            # what is available and when it expires

An export is a job. It runs a real mariadb-dump --single-transaction --quick --routines --triggers --events, gzips it, and writes it to /var/lib/klyrn/<state>/db-exports/<token>/ as root:klyrn mode 0750.

An export never lands under a document root. A customer's database dump must not become a URL on their own website. Nothing under that directory is served by nginx.

The download link contains a 32-character token, but the token is not authority: the download still checks that the signed-in principal owns the account. A different tenant holding the URL gets the same answer as a missing export, "that export is not here", which does not confirm it exists.

Exports are kept for 24 hours and pruned when a new one is created or the list is read. The job refuses to start if free space under the state directory is below 512 MB, and says to remove old backups or exports first.

Importing

klyrn db import acme_wp /root/dump.sql
klyrn db import acme_wp /root/dump.sql.gz

Through the panel, upload a .sql or .sql.gz; the file is staged outside any document root and applied as a job. A gzip is decompressed with a ceiling of the lower of 8 GB and the free disk minus a 256 MB margin. Exceeding it stops before writing anything and says to import from the command line on the server instead.

The last step counts the tables and fails the job if the count is zero: a dump that applied nothing is not a successful import.

An import is not transactional, and the message says so. A dump that fails part way leaves what it already wrote. The error names the database and states that it holds whatever the dump applied before the error, rather than implying a clean rollback that did not happen.

The uploaded file is removed whenever the job stops, successfully or not.

There is no phpMyAdmin

Not an omission. phpMyAdmin is a large PHP application with a long CVE history, and bundling it means running it next to every customer's data on every server, updated on somebody else's schedule.

If you want it, install it yourself as an ordinary PHP site in its own account, where it is isolated from everything else the way any other site is. KLYRN's own answer (export, import, and a database browser of its own) is deliberately smaller.