2.7. Migrating to MariaDB 10.5
In RHEL 8, the MariaDB server is available in versions 10.3 and 10.5, each provided by a separate module stream. RHEL 9 provides MariaDB 10.5 and MySQL 8.0. This part describes migration from a RHEL 8 version of MariaDB 10.3 to RHEL 9 version of MariaDB 10.5.
2.7.1. Notable differences between MariaDB 10.3 and MariaDB 10.5
Significant changes between MariaDB 10.3 and MariaDB 10.5 include:
-
MariaDB now uses the
unix_socket
authentication plug-in by default. The plug-in enables users to use operating system credentials when connecting to MariaDB through the local UNIX socket file. -
MariaDB
addsmariadb-*
named binaries andmysql*
symbolic links pointing to themariadb-*
binaires. For example, themysqladmin
,mysqlaccess
, andmysqlshow
symlinks point to themariadb-admin
,mariadb-access
, andmariadb-show
binaries, respectively. -
The
SUPER
privilege has been split into several privileges to better align with each user role. As a result, certain statements have changed required privileges. -
In parallel replication, the
slave_parallel_mode
now defaults tooptimistic
. -
In the InnoDB storage engine, defaults of the following variables have been changed:
innodb_adaptive_hash_index
toOFF
andinnodb_checksum_algorithm
tofull_crc32
. MariaDB now uses the
libedit
implementation of the underlying software managing the MariaDB command history (the.mysql_history
file) instead of the previously usedreadline
library. This change impacts users working directly with the.mysql_history
file. Note that.mysql_history
is a file managed by the MariaDB or MySQL applications, and users should not work with the file directly. The human-readable appearance is coincidental.NoteTo increase security, you can consider not maintaining a history file. To disable the command history recording:
-
Remove the
.mysql_history
file if it exists. Use either of the following approaches:
-
Set the
MYSQL_HISTFILE
variable to/dev/null
and include this setting in any of your shell’s startup files. Change the
.mysql_history
file to a symbolic link to/dev/null
:$ ln -s /dev/null $HOME/.mysql_history
-
Set the
-
Remove the
MariaDB Galera Cluster has been upgraded to version 4 with the following notable changes:
- Galera adds a new streaming replication feature, which supports replicating transactions of unlimited size. During an execution of streaming replication, a cluster replicates a transaction in small fragments.
- Galera now fully supports Global Transaction ID (GTID).
-
The default value for the
wsrep_on
option in the/etc/my.cnf.d/galera.cnf
file has changed from1
to0
to prevent end users from startingwsrep
replication without configuring required additional options.
Changes to the PAM plug-in in MariaDB 10.5 include:
-
MariaDB 10.5 adds a new version of the Pluggable Authentication Modules (PAM) plug-in. The PAM plug-in version 2.0 performs PAM authentication using a separate
setuid root
helper binary, which enables MariaDB to use additional PAM modules. -
The helper binary can be executed only by users in the
mysql
group. By default, the group contains only themysql
user. Red Hat recommends that administrators do not add more users to themysql
group to prevent password-guessing attacks without throttling or logging through this helper utility. -
In MariaDB 10.5, the Pluggable Authentication Modules (PAM) plug-in and its related files have been moved to a new package,
mariadb-pam
. As a result, no newsetuid root
binary is introduced on systems that do not use PAM authentication forMariaDB
. -
The
mariadb-pam
package contains both PAM plug-in versions: version 2.0 is the default, and version 1.0 is available as theauth_pam_v1
shared object library. -
The
mariadb-pam
package is not installed by default with the MariaDB server. To make the PAM authentication plug-in available in MariaDB 10.5, install themariadb-pam
package manually.
2.7.2. Migrating from a RHEL 8 version of MariaDB 10.3 to a RHEL 9 version of MariaDB 10.5
This procedure describes migrating from the MariaDB 10.3 to the MariaDB 10.5 using the mariadb-upgrade
utility.
The mariadb-upgrade
utility is provided by the mariadb-server-utils
subpackage, which is installed as a dependency of the mariadb-server
package.
Conditions préalables
- Before performing the upgrade, back up all your data stored in the MariaDB databases.
Procédure
Ensure that the
mariadb-server
package is installed on the RHEL 9 system:# dnf install mariadb-server
Ensure that the
mariadb
service is not running on either of the source and target systems at the time of copying data:# systemctl stop mariadb.service
-
Copy the data from the source location to the
/var/lib/mysql/
directory on the RHEL 9 target system. Set the appropriate permissions and SELinux context for copied files on the target system:
# restorecon -vr /var/lib/mysql
Ensure that
mysql:mysql
is owner of all data in the/var/lib/mysql
directory:# chown -R mysql:mysql /var/lib/mysql
-
Adjust configuration so that option files located in
/etc/my.cnf.d/
include only options valid for MariaDB 10.5. For details, see upstream documentation for MariaDB 10.4 and MariaDB 10.5. Start the MariaDB server on the target system.
When upgrading a database running standalone:
# systemctl start mariadb.service
When upgrading a Galera cluster node:
# galera_new_cluster
The
mariadb
service will be started automatically.
Execute the mariadb-upgrade utility to check and repair internal tables.
When upgrading a database running standalone:
$ mariadb-upgrade
When upgrading a Galera cluster node:
$ mariadb-upgrade --skip-write-binlog
There are certain risks and known problems related to an in-place upgrade. For example, some queries might not work or they will be run in different order than before the upgrade. For more information about these risks and problems, and for general information about an in-place upgrade, see MariaDB 10.5 Release Notes.