How to Install MariaDB 12.3 on Ubuntu 26.04, 24.04 and 22.04

MariaDB 12.3 consolidates the 12.x development series into an LTS branch maintained through June 2029. Installing MariaDB 12.3 on Ubuntu includes a MySQL-compatible caching_sha2_password authentication plugin and SQL additions such as IS JSON plus CTE-backed UPDATE and DELETE. Existing servers need application testing because innodb_snapshot_isolation now defaults to ON.

Ubuntu’s default repositories do not provide this branch, so the installation uses the MariaDB.org APT repository. Pinning the source to 12.3 keeps maintenance updates inside the LTS series on Ubuntu 26.04, 24.04, and 22.04. Use the default MariaDB package guide for Ubuntu when you prefer Ubuntu to own the branch and update cadence.

Install MariaDB 12.3 on Ubuntu

MariaDB.org publishes 12.3 packages for Ubuntu 26.04 LTS (Resolute), Ubuntu 24.04 LTS (Noble), and Ubuntu 22.04 LTS (Jammy). Each release uses the same upstream package names and APT workflow, while Ubuntu’s default candidate remains an older branch.

Ubuntu release	Default Ubuntu branch	MariaDB 12.3 path
Ubuntu 26.04 LTS	MariaDB 11.8	MariaDB.org 12.3 repository
Ubuntu 24.04 LTS	MariaDB 10.11	MariaDB.org 12.3 repository
Ubuntu 22.04 LTS	MariaDB 10.6	MariaDB.org 12.3 repository

The copy-ready source is intentionally limited to Ubuntu’s amd64 architecture. For another architecture, use the official MariaDB repository configuration tool to check whether 12.3 packages exist for your Ubuntu release, then verify the package candidate on that architecture before adapting the source. Do not delete the guard and assume the package set is equivalent.

Do not treat these clean-install commands as an in-place database upgrade. Back up existing databases, record the current package source and server version, then test the major-version change with your application before replacing an existing MariaDB or MySQL installation.

Install MariaDB 12.3 from the MariaDB.org Repository

Check for Existing MariaDB or MySQL Packages

Inspect installed database packages before adding another source. No output means the listed MariaDB and MySQL package families are not currently installed through DPKG.

dpkg-query -W -f='${binary:Package}\t${Version}\n' 2>/dev/null | grep -E '^(mariadb|mysql)'

Check for older MariaDB repository definitions as well. A duplicate source can produce conflicting Signed-By settings or let APT select packages from an unintended branch.

grep -RniE 'mariadb|deb\.mariadb\.org' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

If either command finds an existing server or repository, stop and inventory that installation before continuing. Keep one MariaDB source for the active branch instead of layering 12.3 over old .list, .sources, or repository-setup-script files.

Update the Ubuntu Package Index

Refresh Ubuntu’s package metadata before installing the tools used to configure the MariaDB repository.

sudo apt update

A full system upgrade is not required to add this repository. On a new host or during an approved maintenance window, apply pending Ubuntu upgrades before adding the vendor source. Review the transaction before confirming because this updates the wider system, not only MariaDB prerequisites; kernel or core-library changes can require a reboot.

sudo apt upgrade

Skip that broad upgrade during a package-only production change and handle it through the server’s normal maintenance and rollback process. The remaining installation steps change only the required repository tools and MariaDB package family.

These commands use sudo for package management and system configuration. Set up an administrator account first if your user cannot run sudo commands, or follow the steps to add a user to sudoers on Ubuntu.

Install the Repository Requirements

Install ca-certificates for HTTPS certificate validation, curl for the key download, and gpg for fingerprint inspection.

sudo apt install ca-certificates curl gpg

Download and Verify the MariaDB Signing Key

MariaDB.org owns the repository used in this method. APT uses the dedicated MariaDB release key to verify repository signatures, while the branch-specific repository can update the MariaDB packages it publishes. A guarded shell block downloads the armored key into a unique temporary directory, checks it against MariaDB’s published Debian and Ubuntu signing-key fingerprint, converts it to an APT-compatible binary keyring, and grants trust only after both fingerprint checks pass.

(
    set -e
    key_tmp="$(mktemp -d)"
    trap 'rm -rf -- "$key_tmp"' EXIT
    install -m 0700 -d "$key_tmp/gnupg"

    curl -fsSLo "$key_tmp/mariadb-keyring.pgp" \
        https://mariadb.org/mariadb_release_signing_key.pgp

    expected_fingerprint='177F4010FE56CA3336300305F1656F24C74CD1D8'
    actual_fingerprint="$(
        GNUPGHOME="$key_tmp/gnupg" gpg --batch --quiet --show-keys \
            --with-colons --fingerprint "$key_tmp/mariadb-keyring.pgp" |
            awk -F: '$1 == "fpr" {print toupper($10); exit}'
    )"

    if [ "$actual_fingerprint" != "$expected_fingerprint" ]; then
        printf 'MariaDB signing key fingerprint mismatch; do not continue.\n' >&2
        exit 1
    fi

    GNUPGHOME="$key_tmp/gnupg" gpg --batch --yes --dearmor \
        --output "$key_tmp/mariadb-keyring.gpg" \
        "$key_tmp/mariadb-keyring.pgp"

    dearmored_fingerprint="$(
        GNUPGHOME="$key_tmp/gnupg" gpg --batch --quiet --show-keys \
            --with-colons --fingerprint "$key_tmp/mariadb-keyring.gpg" |
            awk -F: '$1 == "fpr" {print toupper($10); exit}'
    )"

    if [ "$dearmored_fingerprint" != "$expected_fingerprint" ]; then
        printf 'Dearmored MariaDB keyring fingerprint mismatch; do not continue.\n' >&2
        exit 1
    fi

    sudo install -m 0755 -d /etc/apt/keyrings
    sudo install -m 0644 "$key_tmp/mariadb-keyring.gpg" \
        /etc/apt/keyrings/mariadb-keyring.gpg
    printf 'MariaDB signing key fingerprint verified.\n'
)

MariaDB signing key fingerprint verified.

Add the MariaDB 12.3 DEB822 Repository

This DEB822 source uses the same MariaDB.org repository and signing key in a format that is easy to inspect and remove. The guard reads Ubuntu’s codename and DPKG architecture, then fails before writing anything unless the host matches one of the supported amd64 release tuples.

. /etc/os-release
codename="${VERSION_CODENAME:-}"
arch="$(dpkg --print-architecture)"

case "${codename}:${arch}" in
    resolute:amd64|noble:amd64|jammy:amd64)
        printf '%s\n' \
        'X-Repolib-Name: MariaDB 12.3' \
        'Types: deb' \
        'URIs: https://deb.mariadb.org/12.3/ubuntu' \
        "Suites: ${codename}" \
        'Components: main' \
        'Architectures: amd64' \
        'Signed-By: /etc/apt/keyrings/mariadb-keyring.gpg' \
        | sudo tee /etc/apt/sources.list.d/mariadb.sources > /dev/null
        ;;
    *)
        printf 'Unsupported Ubuntu release or architecture: %s:%s\n' \
            "$codename" "$arch" >&2
        false
        ;;
esac

Refresh APT after adding the source.

sudo apt update

Verify the MariaDB 12.3 Package Candidate

Confirm that APT now selects a 12.3 candidate from deb.mariadb.org before installing the server. The installed field can show an older version when you are deliberately preparing an upgrade, but the candidate must be in the 12.3 series for this method.

apt-cache policy mariadb-server

Relevant output on Ubuntu 26.04 includes the following candidate. Ubuntu 24.04 and 22.04 use the same upstream version with release-specific package suffixes.

Candidate: 1:12.3.2+maria~ubu2604

Do not continue when the candidate is missing, still comes from an Ubuntu archive, or points to another MariaDB branch. Resolve the source, key, or duplicate-repository problem first.

Install MariaDB Server and Client Packages

Install the server daemon and terminal client from the verified 12.3 candidate. Keep the transaction interactive and review any proposed removals before confirming, especially when the system previously contained MySQL or another MariaDB branch.

sudo apt install mariadb-server mariadb-client

Verify MariaDB 12.3

Check the installed client version. The result should identify a stable 12.3.x-MariaDB build; a newer maintenance release than 12.3.2 is normal after the branch receives updates.

mariadb --version

Example output from the first 12.3 LTS release is:

mariadb from 12.3.2-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using  EditLine wrapper

Verify the systemd service separately from the client binary.

systemctl is-active mariadb
systemctl is-enabled mariadb

Ubuntu 26.04 and 24.04 normally return active and enabled after installation. Ubuntu 22.04 can return active and disabled; enable the unit when either result is missing.

sudo systemctl enable --now mariadb

Repeat both state checks after enabling the unit. A ready server returns:

systemctl is-active mariadb
systemctl is-enabled mariadb

active
enabled

Ask the running server for its version and current administrative account. This checks the database process rather than only the package metadata.

sudo mariadb -NBe "SELECT VERSION(), CURRENT_USER();"

Example output on Ubuntu 26.04 is:

12.3.2-MariaDB-ubu2604	root@localhost

The version field should begin with 12.3. If the command cannot authenticate, continue with the security and troubleshooting sections instead of changing the root account blindly.

Secure MariaDB 12.3

Review the MariaDB Security Script

MariaDB packages include the interactive mariadb-secure-installation hardening helper. Confirm the current command exists before running it.

command -v mariadb-secure-installation

The MariaDB 12.3 client package installs the helper at:

/usr/bin/mariadb-secure-installation

Run the helper when the command returns a path.

sudo mariadb-secure-installation

The exact prompts can change between packages and existing account states. For a normal local server, keep administrative access local, remove anonymous accounts and the test database when offered, block remote root access, and reload privileges. Do not replace socket-based root administration with password authentication unless your application or operations model genuinely requires that change.

Create a Database and Local Application User

Applications should use a dedicated account instead of the MariaDB root user. Open an administrative session.

sudo mariadb

Create one database and grant one localhost account privileges only on that database. Replace the example password before executing these SQL statements.

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'replace_with_a_strong_password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
SHOW GRANTS FOR 'appuser'@'localhost';
EXIT;

Test the account from the shell. MariaDB asks for the password without exposing it in shell history.

mariadb -u appuser -p appdb -e "SELECT DATABASE(), CURRENT_USER();"

This local account is suitable for an application running on the same host. For a complete web deployment, the guide to install WordPress with Nginx, MariaDB, and PHP on Ubuntu covers the surrounding web-server and PHP workflow.

Confirm the Listener and Bind Address

Inspect MariaDB’s effective bind address and TCP port from the running server.

sudo mariadb -NBe "SHOW VARIABLES WHERE Variable_name IN ('bind_address','port');"

A clean local installation returns:

bind_address	127.0.0.1
port	3306

Check the listening socket seen by Ubuntu. The local address should be 127.0.0.1:3306; a wildcard or non-loopback address expands network exposure and needs deliberate access controls.

sudo ss -ltnp 'sport = :3306'

Keep MariaDB bound to localhost when the application and database share one server. Remote access needs a specific private bind address, host-restricted database grants, encrypted transport where required, and a source-limited firewall rule. The Ubuntu UFW firewall guide covers rule verification and removal.

Plan Upgrades to MariaDB 12.3 LTS

MariaDB 12.3 is an LTS branch, but moving to it from 10.6, 10.11, 11.4, or 11.8 is still a major database upgrade. MariaDB changed innodb_snapshot_isolation to default to ON in 12.3, so applications that depend on transaction-isolation behaviour need staging tests rather than a package-only assumption.

Before changing an existing server, record the current version, active package source, database size, authentication plugins, configuration overrides, replication or Galera state, and application maintenance procedure. Verify a restore from a recent backup, then review the MariaDB 12.3 LTS release announcement and linked release notes for compatibility changes.

Do not downgrade a data directory by changing the repository back to an older branch. Restore a compatible backup or follow a documented rollback plan instead of starting older server binaries against files already upgraded by MariaDB 12.3.

Manage MariaDB 12.3 on Ubuntu

Manage the MariaDB Service

Use the systemd command that matches the required service action rather than running every command as one sequence. The systemctl command examples explain unit states and enablement in more depth.

Task	Command
Check service status	systemctl status mariadb --no-pager
Start MariaDB	sudo systemctl start mariadb
Stop MariaDB	sudo systemctl stop mariadb
Restart MariaDB	sudo systemctl restart mariadb
Enable MariaDB at boot	sudo systemctl enable mariadb

Use restart after a configuration change only after checking the edited setting and reviewing the service logs. Stopping MariaDB interrupts connected applications and should be planned on production systems.

Find the Active Configuration and Data Directory

MariaDB packages use configuration files under /etc/mysql/, but included files and effective values matter more than guessing one filename. Print the options read by the server binary, then query the running instance for its active data directory.

mariadbd --print-defaults
sudo mariadb -NBe "SHOW VARIABLES LIKE 'datadir';"

Create a separate override file under the existing MariaDB include directory when possible instead of editing a package-owned default without a rollback copy. Restart the service and re-query the affected variable to prove the new value is active.

Update MariaDB 12.3 Packages

The /12.3/ repository path keeps APT on the 12.3 branch while allowing newer maintenance releases. Refresh package metadata, then update the installed server, client, and common package set without switching to another major series.

sudo apt update
sudo apt install --only-upgrade mariadb-server mariadb-client mariadb-common

Recheck the package candidate, client version, service state, and a simple SQL query after updates.

apt-cache policy mariadb-server
mariadb --version
systemctl is-active mariadb
sudo mariadb -NBe "SELECT VERSION();"

Back Up MariaDB 12.3 Databases

Create a logical backup before package upgrades, configuration changes, schema work, or removal. The following command exports all databases, stored routines, events, and triggers to a dated SQL file in the current directory.

backup_file="mariadb-all-$(date +%Y%m%d).sql"
sudo mariadb-dump --all-databases --single-transaction --routines --events --triggers > "$backup_file"
test -s "$backup_file" && ls -lh "$backup_file"

--single-transaction gives a consistent logical view for transactional tables without holding a global read lock for the entire dump. It does not make non-transactional tables consistent automatically. Copy the result off the database server and test a restore in a disposable environment before calling the backup usable.

Do not copy the live data directory as a normal backup while MariaDB is running. Physical backups require a database-aware tool and a restore procedure that matches the server version, storage engines, and workload.

Remove MariaDB 12.3 from Ubuntu

Record the effective data directory and confirm your backup before removing packages. Package removal is not the same as deleting database files.

sudo mariadb -NBe "SHOW VARIABLES LIKE 'datadir';"

Stop and disable the service, then remove the main server and client packages. Review the transaction before confirming.

sudo systemctl disable --now mariadb
sudo apt remove mariadb-server mariadb-client

Inspect remaining MariaDB packages and the shared mysql-common package before using apt autoremove or purging configuration. Keep libraries or clients still required by local applications.

dpkg-query -W -f='${binary:Package}\t${Version}\n' 2>/dev/null | grep -E '^(mariadb|mysql-common)'

Remove the branch source only after the package inventory shows that no retained MariaDB package still needs it. If you keep a package from MariaDB.org, leave the source and keyring configured so APT can continue to update it.

sudo rm -f /etc/apt/sources.list.d/mariadb.sources

Remove the MariaDB keyring only when no other APT source references it. This guarded check treats exit status 1 as “no references,” preserves the key when it finds a user, and refuses deletion when the audit itself fails.

key_path='/etc/apt/keyrings/mariadb-keyring.gpg'
source_paths=(/etc/apt/sources.list.d)
[ -f /etc/apt/sources.list ] && source_paths+=(/etc/apt/sources.list)

if key_references="$(sudo grep -RliF -- "$key_path" "${source_paths[@]}")"; then
    printf 'Keep the keyring; it is referenced by:\n%s\n' "$key_references"
else
    key_check_status=$?
    if [ "$key_check_status" -eq 1 ]; then
        sudo rm -f -- "$key_path"
        printf 'Removed the unused MariaDB keyring.\n'
    else
        printf 'Keyring reference audit failed; the key was not removed.\n' >&2
        false
    fi
fi

Refresh APT after the guarded check removes an unused key.

sudo apt update

Database files and manually created configuration can remain after package removal. Delete them only after confirming the exact data and configuration paths, validating a restorable backup, and establishing that no other MariaDB installation or application needs those files.

Troubleshoot MariaDB 12.3 on Ubuntu

APT Does Not Select MariaDB 12.3

Inspect the source file and package policy together.

cat /etc/apt/sources.list.d/mariadb.sources
apt-cache policy mariadb-server

Confirm that the URI contains /12.3/ubuntu, the suite matches resolute, noble, or jammy, and the candidate comes from deb.mariadb.org. After correcting the source, refresh APT and repeat the candidate check.

sudo apt update
apt-cache policy mariadb-server

Continue only when APT selects a 12.3 candidate from deb.mariadb.org.

APT Reports Conflicting Signed-By Values

This error normally means the same MariaDB repository exists in more than one source file with different keyring paths. Find every relevant entry.

grep -RniE 'deb\.mariadb\.org|mariadb.org/repo|MariaDB' /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null

Keep the intended /etc/apt/sources.list.d/mariadb.sources entry and remove only confirmed duplicate files. Do not delete unrelated sources because their filenames happen to mention a database package.

Refresh APT after removing the confirmed duplicate. A clean update must finish without the conflicting Signed-By error.

sudo apt update

APT Reports a MariaDB Key Error

If APT says the keyring has an unsupported filetype and also reports NO_PUBKEY F1656F24C74CD1D8, an armored .pgp download was probably copied directly into the keyring path. APT needs the dearmored .gpg file created by the verified key workflow. Display the installed binary keyring fingerprint before downloading or replacing anything.

(
    set -e
    gpg_home="$(mktemp -d)"
    trap 'rm -rf -- "$gpg_home"' EXIT
    install -m 0700 -d "$gpg_home"
    GNUPGHOME="$gpg_home" gpg --batch --quiet --show-keys \
        --with-fingerprint /etc/apt/keyrings/mariadb-keyring.gpg
)

Repeat the verified key-download workflow when the file is missing, unreadable, or has the wrong fingerprint. Do not bypass APT signature checks to force the repository to load.

Refresh APT after restoring the verified binary keyring. The update must finish without NO_PUBKEY, unsupported-filetype, or signature-verification errors.

sudo apt update

MariaDB Fails to Start

Check the unit state and read the MariaDB service journal with journalctl before changing permissions or deleting files.

sudo systemctl status mariadb --no-pager
sudo journalctl -u mariadb -n 100 --no-pager

Look for the first concrete configuration, storage, permission, port, or upgrade error. A later shutdown message is often a consequence rather than the original cause. Revert the last configuration change when the failure began immediately after an edit.

After correcting the first error, restart MariaDB and repeat the active-state check. Success returns active.

sudo systemctl restart mariadb
systemctl is-active mariadb

Local Root Access Is Denied

Confirm the service is running, then inspect the account definition through an administrative route that still works. Do not reset authentication until you know whether the account expects socket or password authentication.

systemctl is-active mariadb
sudo mariadb -e "SHOW CREATE USER 'root'@'localhost'\G"

If sudo mariadb also fails on a clean installation, review the journal and package transaction before attempting a password-recovery procedure. On an upgraded server, use the authentication method and credentials defined by the previous installation until the migration plan changes them deliberately.

An Existing Database Breaks After the Major Upgrade

Stop application writes and preserve the failed state for diagnosis. Do not delete the data directory, reinstall packages repeatedly, or start an older MariaDB binary against files already opened by 12.3. Compare the server journal, release notes, configuration overrides, authentication plugins, and application errors, then restore the tested backup when rollback is required.

Conclusion

MariaDB 12.3 is available from a branch-pinned MariaDB.org repository with a verified keyring, package candidate, service, local account workflow, backup path, and guarded source cleanup. Keep the listener local unless a separate application host requires controlled access, and test restores plus transaction-isolation-sensitive workloads before moving an existing database to this LTS branch.