Fedora 45 ships MariaDB 12.3 as the default mariadb-server. Fedora 44 still installs 11.8, and both releases carry the other LTS lines as separately named packages. Pick the line first, because the packages conflict and switching later means a package swap and a data upgrade.
This guide installs MariaDB on Fedora from the default repositories, sets a root password without breaking sudo mariadb, turns on the password policy that Fedora ships disabled, and creates an application database with a user that can connect over the network. It also covers firewalld, a tuning drop-in, logical and physical backups with a tested restore, and the MariaDB 11.8 to 12.3 upgrade on Fedora 44, including what a Fedora 44 to 45 system upgrade does to the server. Everything below was run in October 2026 on Fedora 45 with MariaDB 12.3 and Fedora 44 with MariaDB 11.8, with SELinux enforcing.
Choose a MariaDB version
Three LTS lines are packaged for both releases. The unversioned mariadb-server is the release default; the others carry the series in the package name:
| MariaDB line | Fedora 45 package | Fedora 44 package | Community support ends |
|---|---|---|---|
| 12.3 LTS | mariadb-server (default) | mariadb12.3-server | June 2029 |
| 11.8 LTS | mariadb11.8-server | mariadb-server (default) | June 2028 |
| 10.11 LTS | mariadb10.11-server | mariadb10.11-server | February 2028 |
The support dates come from the MariaDB maintenance policy. Every server package provides mariadb-server-any and conflicts with every other one, so a machine runs exactly one line. List what your release offers:
dnf list --available "mariadb*-server"On Fedora 45 the default resolves to the 12.3 build from the fedora repository:
Available packages
mariadb-gssapi-server.x86_64 3:12.3.2-101.fc45 fedora
mariadb-server.x86_64 3:12.3.2-101.fc45 fedora
mariadb10.11-gssapi-server.x86_64 3:10.11.18-4.fc45 fedora
mariadb10.11-server.x86_64 3:10.11.18-4.fc45 fedora
mariadb11.8-gssapi-server.x86_64 3:11.8.8-101.fc45 fedora
mariadb11.8-server.x86_64 3:11.8.8-101.fc45 fedoraNew servers should take 12.3, the newest LTS. Stay on 11.8 only if an application vendor certifies nothing newer. The rest of this guide uses mariadb-server; to install a different line, put its package name in the install command instead. If an application insists on the Oracle build, the MySQL on Fedora guide covers it. MySQL and MariaDB server packages conflict too.
Install MariaDB Server
One package pulls in the client, mariadb-backup, the SELinux policy module and the server utilities:
sudo dnf install -y mariadb-serverOn a minimal Fedora 45 system the transaction is 21 packages and about 141 MiB:
Installing:
mariadb-server x86_64 3:12.3.2-101.fc45 fedora 80.4 MiB
Installing dependencies:
mariadb x86_64 3:12.3.2-101.fc45 fedora 28.2 MiB
mariadb-common noarch 3:12.3.2-101.fc45 fedora 302.9 KiB
mariadb-connector-c x86_64 0:3.4.9-3.fc45 fedora 505.5 KiB
mariadb-connector-c-config noarch 0:3.4.9-3.fc45 fedora 26.4 KiB
mariadb-errmsg noarch 3:12.3.2-101.fc45 fedora 2.4 MiB
mysql-selinux noarch 0:1.0.18-2.fc45 fedora 50.1 KiB
perl-DBD-MariaDB x86_64 0:1.24-8.fc45 fedora 382.9 KiB
perl-DBI x86_64 0:1.655-1.fc45 fedora 2.2 MiB
perl-File-Copy noarch 0:2.43-527.fc45 fedora 19.6 KiB
perl-Math-BigInt noarch 1:2.0050.03-527.fc45 fedora 1.1 MiB
perl-Math-Complex noarch 0:1.63-527.fc45 fedora 85.1 KiB
perl-Module-Load noarch 1:0.36-527.fc45 fedora 14.9 KiB
perl-Sys-Hostname x86_64 0:1.25-527.fc45 fedora 15.7 KiB
policycoreutils-python-utils noarch 0:3.11-2.fc45 fedora 94.5 KiB
snappy x86_64 0:1.2.2-6.fc45 fedora 79.9 KiB
Installing weak dependencies:
mariadb-backup x86_64 3:12.3.2-101.fc45 fedora 25.3 MiB
mariadb-client-utils noarch 3:12.3.2-101.fc45 fedora 193.2 KiB
mariadb-cracklib-password-check x86_64 3:12.3.2-101.fc45 fedora 12.9 KiB
mariadb-gssapi-server x86_64 3:12.3.2-101.fc45 fedora 19.8 KiB
mariadb-server-utils noarch 3:12.3.2-101.fc45 fedora 34.2 KiB
Transaction Summary:
Installing: 21 packagesThe service is disabled after install. Enable and start it:
sudo systemctl enable --now mariadbEnabling it also creates mysql.service and mysqld.service aliases, so old scripts that restart mysqld keep working:
Created symlink '/etc/systemd/system/mysql.service' → '/usr/lib/systemd/system/mariadb.service'.
Created symlink '/etc/systemd/system/mysqld.service' → '/usr/lib/systemd/system/mariadb.service'.
Created symlink '/etc/systemd/system/multi-user.target.wants/mariadb.service' → '/usr/lib/systemd/system/mariadb.service'.Confirm the server is up:
systemctl status mariadb --no-pagerThe unit description names the series, and the status line reads Taking your SQL requests now... once the server accepts connections:
● mariadb.service - MariaDB 12.3 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Tue 2026-10-13 07:43:59 UTC; 6ms ago
Invocation: 35994a8d30ec4215bb335b1312ca29e3
Docs: man:mariadbd(8)
https://mariadb.com/kb/en/library/systemd/
Process: 5615 ExecStartPre=/usr/libexec/mariadb-check-socket (code=exited, status=0/SUCCESS)
Process: 5638 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir mariadb.service (code=exited, status=0/SUCCESS)
Process: 5722 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && echo _WSREP_START_POSITION=$VAR > /run/mariadb/wsrep-start-position || exit 1 (code=exited, status=0/SUCCESS)
Process: 5740 ExecStartPost=/usr/libexec/mariadb-check-upgrade (code=exited, status=0/SUCCESS)
Process: 5771 ExecStartPost=/bin/rm -f /run/mariadb/wsrep-start-position (code=exited, status=0/SUCCESS)
Main PID: 5724 (mariadbd)
Status: "Taking your SQL requests now..."
Tasks: 14 (limit: 4593)
Memory: 136.6M (peak: 139.6M)
CPU: 678ms
CGroup: /system.slice/mariadb.service
└─5724 /usr/libexec/mariadbd --basedir=/usrNote the mariadb-check-upgrade step after start. It compares the data directory with the installed series and logs a warning when they differ, which matters in the upgrade section. Defaults worth knowing: data in /var/lib/mysql, the error log in /var/log/mariadb/mariadb.log, a 128 MiB InnoDB buffer pool, 151 max connections, and TCP port 3306 on every interface.
Set a root password and keep socket login
The first start initialises the data directory with two admin accounts, root@localhost and mysql@localhost. Neither has a password. Both use unix_socket, so only the matching Linux user gets in. A normal login is refused, even when it asks for root:
mariadb -u root -e "SELECT 1;"The error is 1698, the socket plugin rejecting a Linux user that is not root:
ERROR 1698 (28000): Access denied for user 'root'@'localhost'With sudo it works, and you can read how root is defined:
sudo mariadb -e "SHOW CREATE USER root@localhost\G"Root accepts either a password that can never match (invalid) or the socket:
*************************** 1. row ***************************
CREATE USER for root@localhost: CREATE USER `root`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socketThat’s a safe default, and there is less to clean up than older guides suggest. A fresh 12.3 or 11.8 data directory has no anonymous users and no test database, so most of what mariadb-secure-installation asks has already been done. Tools that log in with a password over TCP, such as phpMyAdmin or a backup agent on another host, still need a real root password. Set one and keep the socket path, so sudo mariadb keeps working. Start by setting the variables used through the rest of the guide. The passwords are read from the terminal, so they never land in shell history:
export APP_DB=appdb APP_USER=appuser APP_NET="10.0.1.%"
read -rsp "MariaDB root password: " DB_ROOT_PASS; echo
read -rsp "App user password: " APP_PASS; echoAPP_NET is the subnet your application servers connect from. Now give root both methods:
sudo mariadb -e "ALTER USER root@localhost IDENTIFIED VIA unix_socket OR mysql_native_password USING PASSWORD('${DB_ROOT_PASS}');"Test the password path from your normal account:
mariadb -u root -p"${DB_ROOT_PASS}" -e "SELECT CURRENT_USER(), USER(), VERSION();"The password login works without sudo, and sudo mariadb still gets in through the socket:
CURRENT_USER() USER() VERSION()
root@localhost root@localhost 12.3.2-MariaDBRunning ALTER USER root@localhost IDENTIFIED BY '...' instead removes unix_socket from the account. Any script that relied on sudo mariadb, including log rotation hooks and your own cron jobs, then stops working.
Turn on the password policy
Fedora installs mariadb-cracklib-password-check as a weak dependency, but its config line is commented out. Until you enable it, the server accepts password1 as a password. Check the shipped file:
cat /etc/my.cnf.d/cracklib_password_check.cnfBoth Fedora 45 and Fedora 44 ship it like this:
[mariadb]
#plugin-load-add=cracklib_password_check.soUncomment the line and restart:
sudo sed -i "s/^#plugin-load-add=cracklib_password_check.so/plugin-load-add=cracklib_password_check.so/" /etc/my.cnf.d/cracklib_password_check.cnf
sudo systemctl restart mariadbA dictionary password is now refused:
sudo mariadb -e "CREATE USER weak@localhost IDENTIFIED BY 'password1';"The plugin names itself in the error, which helps when an application installer fails with a vague message:
ERROR 1819 (HY000) at line 1: Your password does not satisfy the current policy requirements (cracklib_password_check)The check runs only when a password is set, so existing accounts keep working. That includes the root password from the previous step, which was never checked. On a new server, enable the plugin before you set any passwords.
Create a database and an application user
Leave the character set and collation out of CREATE DATABASE. On both 12.3 and 11.8 the server default is utf8mb4 with the utf8mb4_uca1400_ai_ci collation, which is newer than the utf8mb4_unicode_ci that older guides hardcode:
sudo mariadb -e "CREATE DATABASE ${APP_DB}; CREATE USER ${APP_USER}@localhost IDENTIFIED BY '${APP_PASS}'; GRANT ALL PRIVILEGES ON ${APP_DB}.* TO ${APP_USER}@localhost;"Log in as the new user and confirm it sees only its own database:
mariadb -u "${APP_USER}" -p"${APP_PASS}" -e "SHOW DATABASES; SELECT CURRENT_USER();"Apart from information_schema, the only schema listed is appdb:
Database
appdb
information_schema
CURRENT_USER()
appuser@localhostFor a quick sanity table, create one and insert a few rows as the application user. The backup and upgrade tests later in this guide restore this table and count its rows:
mariadb -u "${APP_USER}" -p"${APP_PASS}" "${APP_DB}" -e "CREATE TABLE orders (id INT AUTO_INCREMENT PRIMARY KEY, item VARCHAR(64), qty INT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP); INSERT INTO orders (item, qty) VALUES ('bolts', 40), ('washers', 120), ('nuts', 75); SELECT * FROM orders;"Three rows come back:
id item qty created_at
1 bolts 40 2026-10-13 07:45:40
2 washers 120 2026-10-13 07:45:40
3 nuts 75 2026-10-13 07:45:40Allow remote connections
MariaDB on Fedora already listens on all interfaces. The bind-address line in /etc/my.cnf.d/mariadb-server.cnf is commented out, and the socket table confirms it:
sudo ss -tlnp | grep -E "3306|mariadbd"Both the IPv4 and IPv6 wildcard addresses are bound:
LISTEN 0 80 0.0.0.0:3306 0.0.0.0:* users:(("mariadbd",pid=5724,fd=27))
LISTEN 0 80 [::]:3306 [::]:* users:(("mariadbd",pid=5724,fd=28))So the work is two parts: an account whose host matches the client, and a firewall rule. Accounts are keyed on user and host, so the remote user is a second account next to appuser@localhost:
sudo mariadb -e "CREATE USER ${APP_USER}@'${APP_NET}' IDENTIFIED BY '${APP_PASS}'; GRANT ALL PRIVILEGES ON ${APP_DB}.* TO ${APP_USER}@'${APP_NET}';"Be careful with the host format. MariaDB takes a % wildcard or an address with a dotted netmask. CIDR notation such as 10.0.1.0/24 is accepted by CREATE USER without a warning, but no client ever matches it. We created one account of each kind and connected from an application host at 10.0.1.51:
The CIDR account fails with ERROR 1045, the same error as a wrong password, which makes this hard to spot. Use 10.0.1.% or 10.0.1.0/255.255.255.0.
What the firewall does depends on the edition. Fedora Server puts the interface in the FedoraServer zone, which allows only ssh, cockpit and dhcpv6-client, so a remote client fails with an error such as ERROR 2002 (HY000): Can't connect to server on '10.0.1.50' (115) until you add a rule. The FedoraWorkstation zone is the opposite: it opens every TCP and UDP port from 1025 to 65535, so MariaDB on a Workstation install is reachable from the whole network as soon as it starts. Cloud images ship without firewalld. On those, install it first; it starts in the public zone, which allows ssh on port 22, so your session stays up. If sshd listens on another port, add that port to the zone before you enable firewalld:
sudo dnf install -y firewalld
sudo systemctl enable --now firewalldOn Server and Cloud, allow the predefined mysql service from the application subnet only. The source address must cover the same hosts as APP_NET, so change both together:
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="mysql" accept'
sudo firewall-cmd --reloadFirewalld does understand CIDR, so the rule uses it. List the active rules to confirm:
sudo firewall-cmd --list-rich-rulesThe mysql service maps to 3306/tcp:
rule family="ipv4" source address="10.0.1.0/24" service name="mysql" acceptZones, sources and rich rules are covered in more depth in the firewalld on Fedora guide. On a host that should never be reached from outside, set bind-address=127.0.0.1 under [mariadb] in /etc/my.cnf.d/mariadb-server.cnf instead and skip the firewall rule. On Workstation the rich rule adds nothing, because the zone already opens 3306, so use bind-address or move the interface to a stricter zone as the firewalld guide shows.
Test from the application host. It only needs the client package, sudo dnf install -y mariadb. Set APP_USER and APP_PASS there too, with the same export and read lines used on the server:
mariadb -h 10.0.1.50 -u "${APP_USER}" -p"${APP_PASS}" -e "SELECT CURRENT_USER(), @@hostname, @@version; SELECT COUNT(*) FROM appdb.orders;"The server reports the wildcard account that matched and the rows created earlier:
CURRENT_USER() @@hostname @@version
[email protected].% db01 12.3.2-MariaDB-log
COUNT(*)
3This test ran after the tuning in the next section. That turns on binary logging, which adds the -log suffix to the version string.
Tune MariaDB with a drop-in file
Keep your settings out of mariadb-server.cnf, which the package owns. Files in /etc/my.cnf.d/ load in name order, so a 99- file wins. Create it:
sudo vim /etc/my.cnf.d/99-tuning.cnfThis is the file used on the 4 GB test server:
[mariadbd]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
max_connections = 200
skip_name_resolve = ON
server_id = 1
log_bin = mariadb-bin
binlog_expire_logs_seconds = 604800Size the buffer pool to the machine. On a dedicated database server 50 to 70 percent of RAM is normal; on a box that also runs the application, a quarter is safer. The binary log is what replication and point-in-time recovery read, and binlog_expire_logs_seconds keeps seven days of it. skip_name_resolve stops the server doing a reverse DNS lookup on every TCP connection. Without it, the error log filled with lines like [Warning] IP address '10.0.1.51' could not be resolved: Temporary failure in name resolution during the remote test. With it on, grants must use IP addresses, not host names.
Configs copied from older guides often carry innodb_flush_method = O_DIRECT and expire_logs_days. Both still start on 12.3. The first logs [Warning] --innodb-flush-method is deprecated and will be removed in a future release, and expire_logs_days is the older spelling of binlog_expire_logs_seconds. Leave them out. Restart and read the values back:
sudo systemctl restart mariadb
sudo mariadb -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS buffer_pool_mb, @@innodb_log_file_size/1024/1024 AS redo_mb, @@max_connections, @@skip_name_resolve, @@log_bin, @@binlog_expire_logs_seconds;"Every value from the file took effect:
buffer_pool_mb redo_mb @@max_connections @@skip_name_resolve @@log_bin @@binlog_expire_logs_seconds
1024.00000000 256.00000000 200 1 1 604800After the restart the error log carries one harmless line, [Warning] 'proxies_priv' entry '@% mysql@db01' ignored in --skip-name-resolve mode. It refers to a default proxy grant keyed on the host name and does not affect logins. New files in /etc/my.cnf.d/ get the right SELinux type, mysqld_etc_t, so no relabelling is needed.
Back up and restore
Two tools ship with the server. mariadb-dump writes SQL, which is portable and fine for databases up to a few gigabytes:
sudo mariadb-dump --single-transaction --routines --triggers --events --databases "${APP_DB}" | gzip > "${APP_DB}-$(date +%F).sql.gz"Test the dump before you need it. On a test server, drop the database:
sudo mariadb -e "DROP DATABASE ${APP_DB};"Because of --databases, the dump includes the CREATE DATABASE statement, so a restore needs no target name. Use the file name with the date of your dump:
zcat "${APP_DB}-2026-10-13.sql.gz" | sudo mariadbThe first line of a dump from 12.3 or 11.8 is /*M!999999\- enable the sandbox mode */, which stops a restore from running shell commands embedded in the file. Verify the result before you trust the dump:
sudo mariadb -e "SELECT COUNT(*) FROM ${APP_DB}.orders;"All three rows came back:
COUNT(*)
3For larger data sets, mariadb-backup copies the data files while the server runs, and a restore is a file copy. Run it with sudo, and the root socket login handles authentication:
BACKUP_DIR=/var/backups/mariadb/full-$(date +%F)
sudo mkdir -p /var/backups/mariadb
sudo mariadb-backup --backup --target-dir="${BACKUP_DIR}"
sudo mariadb-backup --prepare --target-dir="${BACKUP_DIR}"Each step ends with completed OK!. The prepared copy of this small server was 47 MB. The restore is where people get caught. --copy-back refuses to run with Original data directory /var/lib/mysql is not empty!, so move the old one aside and create an empty one. The files then land owned by root, with the generic var_lib_t SELinux type, and the server won’t start. This is the test restore on Fedora 45, with the fix:
The full sequence, with the ownership and label fix included. In a new shell, set BACKUP_DIR to the backup you are restoring first, for example BACKUP_DIR=/var/backups/mariadb/full-2026-10-13:
sudo systemctl stop mariadb
sudo mv /var/lib/mysql /var/lib/mysql.broken && sudo mkdir /var/lib/mysql
sudo mariadb-backup --copy-back --target-dir="${BACKUP_DIR}"
sudo chown -R mysql:mysql /var/lib/mysql
sudo restorecon -R /var/lib/mysql
sudo systemctl start mariadbDelete /var/lib/mysql.broken once the restored data checks out. One more thing: the backup does not include mariadb_upgrade_info, so the first start after a restore logs the “needs to be upgraded” warning from mariadb-check-upgrade even though nothing changed. Running sudo mariadb-upgrade recreates the file, but as root with mode 0640. The check runs as the mysql user, cannot read it, and keeps warning on every start. Fix the owner:
sudo mariadb-upgrade
sudo chown mysql:mysql /var/lib/mysql/mariadb_upgrade_infoFor scheduled physical backups with binary log replay to a point in time, see MariaDB backup and point-in-time recovery.
Upgrade MariaDB 11.8 to 12.3 on Fedora 44
A Fedora 44 server can move to 12.3 without waiting for Fedora 45. Take a logical dump of everything first, because a series upgrade has no downgrade path:
sudo mariadb-dump --all-databases --single-transaction --routines --events | gzip > pre-12.3-$(date +%F).sql.gzStop the server and swap the package. --allowerasing lets dnf remove the 11.8 packages that conflict with the new ones:
sudo systemctl stop mariadb
sudo dnf swap -y mariadb-server mariadb12.3-server --allowerasingRead the end of the transaction. The scriptlet in the new package disables the service:
Running transaction
>>> Running %post scriptlet: mariadb12.3-server-3:12.3.2-2.fc44.x86_64
>>> Finished %post scriptlet: mariadb12.3-server-3:12.3.2-2.fc44.x86_64
>>> Scriptlet output:
>>> Removed '/etc/systemd/system/multi-user.target.wants/mariadb.service'.
>>> Removed '/etc/systemd/system/mysql.service'.
>>> Removed '/etc/systemd/system/mysqld.service'.
>>>
Complete!If you only run systemctl start, the server works until the next reboot and then stays down. Every series swap in testing did this: 12.3 to 11.8 and back on Fedora 45, and 11.8 to 12.3 on Fedora 44. Enable it again, then run the upgrade tool:
sudo systemctl enable --now mariadb
sudo mariadb-upgradeThe upgrade tool detects the major version change and starts checking every system and user table:
After the last table, the run ends with the plugin and privilege phases:
Phase 7/8: uninstalling plugins
Phase 8/8: Running 'FLUSH PRIVILEGES'
OKThe Fedora 44 mariadb12.3-server build has a quirk. Its mariadb-check-upgrade script reads only the old mysql_upgrade_info file, which the 12.3 mariadb-upgrade deletes. So the “datadir needs to be upgraded” warning keeps appearing on every start after a clean upgrade. The Fedora 45 build reads mariadb_upgrade_info first and does not have the problem. On Fedora 44, copy the file to silence it:
sudo -u mysql cp -p /var/lib/mysql/mariadb_upgrade_info /var/lib/mysql/mysql_upgrade_infoDo not run mariadb-upgrade with sudo -u mysql to dodge the ownership problem. It still connects as root by default and fails with ERROR 1698 (28000): Access denied for user 'root'@'localhost'.
What a Fedora 44 to 45 upgrade does to MariaDB
It depends on which package you have. A Fedora 44 server on the default mariadb-server comes back from the system upgrade on 12.3 automatically, because the default package moved. The data directory is still from 11.8, so the server starts with the mariadb-check-upgrade warning in the journal until you run sudo mariadb-upgrade. The full walkthrough, with snapshots and rollback, is in the Fedora 44 to 45 upgrade guide.
A server you already moved to mariadb12.3-server is a different case. Fedora 45 has no package by that name, so the system upgrade leaves the Fedora 44 builds installed. MariaDB keeps running, but those packages never get another update. Swap them for the Fedora 45 default, which is the same 12.3 series and needs no mariadb-upgrade. This is the test server straight after the system upgrade:
The commands from that session, which need no mariadb-upgrade because the series does not change:
sudo systemctl stop mariadb
sudo dnf swap -y mariadb12.3-server mariadb-server --allowerasing
sudo systemctl enable --now mariadbThe swap disabled the service once more, which is why enable --now is part of it. The keyring lock error from rpm -qa appeared once, on the first boot after the upgrade, and did not affect the query. To check a machine for leftovers, run dnf list --extras; any fc44 MariaDB package in that list needs the swap.
Run 11.8 or 10.11 on Fedora 45
On a fresh Fedora 45 machine, install mariadb11.8-server or mariadb10.11-server instead of mariadb-server and follow the same steps. On a machine that already runs 12.3, plain dnf install mariadb11.8-server fails on the mariadb-server-any conflict, and a dnf swap ... --allowerasing goes through. In our test 11.8 even started on the 12.3 data directory, but MariaDB does not support downgrades in place, and the system tables were written by the newer series. Go back the safe way: install the older line on an empty data directory and load the mariadb-dump file. Whichever direction you swap, enable the service again afterwards.
Checks before it takes production traffic
- Root has both
unix_socketand a password, andsudo mariadbstill works. - The cracklib plugin is active:
SELECT plugin_status FROM information_schema.plugins WHERE plugin_name='cracklib_password_check';returnsACTIVE. - Remote accounts use
%or netmask hosts, never CIDR, and port 3306 is reachable only from the application subnet. On Workstation, check the zone. - A restore has been tested end to end, including
chownandrestoreconfor physical backups. systemctl is-enabled mariadbsaysenabledafter every package swap or release upgrade, andjournalctl -u mariadb -n 20after a restart shows nomariadb-check-upgradewarning.
For metrics, the MariaDB Prometheus and Grafana guide works against this server unchanged. When one node is no longer enough, MariaDB Galera with HAProxy and Keepalived is the next step. The LAMP stack on Fedora and phpMyAdmin on Fedora guides build on it directly.
