Upgrading from MariaDB 10.4 to MariaDB 10.5
How to Upgrade
For Windows, see Upgrading MariaDB on Windows instead.
Before you upgrade, it would be best to take a backup of your database. This is always a good idea to do before an upgrade. We would recommend Mariabackup.
The suggested upgrade procedure is:
- Modify the repository configuration, so the system's package manager installs MariaDB 10.5. For example,
- On Debian, Ubuntu, and other similar Linux distributions, see Updating the MariaDB APT repository to a New Major Release for more information.
- On RHEL, CentOS, Fedora, and other similar Linux distributions, see Updating the MariaDB YUM repository to a New Major Release for more information.
- On SLES, OpenSUSE, and other similar Linux distributions, see Updating the MariaDB ZYpp repository to a New Major Release for more information.
- Stop MariaDB.
- Uninstall the old version of MariaDB.
- On Debian, Ubuntu, and other similar Linux distributions, execute the following:
sudo apt-get remove mariadb-server
- On RHEL, CentOS, Fedora, and other similar Linux distributions, execute the following:
sudo yum remove MariaDB-server
- On SLES, OpenSUSE, and other similar Linux distributions, execute the following:
sudo zypper remove MariaDB-server
- On Debian, Ubuntu, and other similar Linux distributions, execute the following:
- Install the new version of MariaDB.
- On Debian, Ubuntu, and other similar Linux distributions, see Installing MariaDB Packages with APT for more information.
- On RHEL, CentOS, Fedora, and other similar Linux distributions, see Installing MariaDB Packages with YUM for more information.
- On SLES, OpenSUSE, and other similar Linux distributions, see Installing MariaDB Packages with ZYpp for more information.
- Make any desired changes to configuration options in option files, such as
my.cnf
. This includes removing any options that are no longer supported. - Start MariaDB.
- Run mysql_upgrade.
-
mysql_upgrade
does two things:- Ensures that the system tables in the#mysql database are fully compatible with the new version.
- Does a very quick check of all tables and marks them as compatible with the new version of MariaDB .
-
Incompatible Changes Between 10.4 and 10.5
On most servers upgrading from 10.4 should be painless. However, there are some things that have changed which could affect an upgrade:
Binary name changes
All binaries previously beginning with mysql now begin with mariadb, with symlinks for the corresponding mysql command.
Usually that shouldn't cause any changed behavior, but when starting the MariaDB server via systemd, or via the mysqld_safe script symlink, the server process will now always be started as mariadbd
, not mysqld
.
So anything looking for the mysqld
name in the system process list, like e.g. monitoring solutions, now needs for mariadbd
instead when the server / service is not started directly, but via mysqld_safe
or as a system service.
GRANT PRIVILEGE changes
A number of statements changed the privileges that they require. The old privileges were historically inappropriately chosen in the upstream. 10.5.2 fixes this problem. Note, these changes are incompatible to previous versions. A number of GRANT commands might be needed after upgrade.
-
SHOW BINLOG EVENTS
now requires theBINLOG MONITOR
privilege (requredREPLICATION SLAVE
prior to 10.5.2). -
SHOW SLAVE HOSTS
now requires theREPLICATION MASTER ADMIN
privilege (requiredREPLICATION SLAVE
prior to 10.5.2). -
SHOW SLAVE STATUS
now requires theREPLICATION SLAVE ADMIN
or theSUPER
privilege (requiredREPLICATION CLIENT
orSUPER
prior to 10.5.2). -
SHOW RELAYLOG EVENTS
now requires theREPLICATION SLAVE ADMIN
privilege (requiredREPLICATION SLAVE
prior to 10.5.2).
Options That Have Changed Default Values
Option | Old default value | New default value |
---|---|---|
innodb_adaptive_hash_index | ON | OFF |
innodb_checksum_algorithm | crc32 | full_crc32 |
innodb_log_optimize_ddl | ON | OFF |
slave_parallel_mode | conservative | optimistic |
performance_schema_max_cond_classes | 80 | 90 |
performance_schema_max_file_classes | 50 | 80 |
performance_schema_max_mutex_classes | 200 | 210 |
performance_schema_max_rwlock_classes | 40 | 50 |
performance_schema_setup_actors_size | 100 | -1 |
performance_schema_setup_objects_size | 100 | -1 |
Options That Have Been Removed or Renamed
The following options should be removed or renamed if you use them in your option files:
Option | Reason |
---|---|
innodb_checksums | Deprecated and functionality replaced by innodb_checksum_algorithms in MariaDB 10.0. |
idle_flush_pct | Has had no effect since merging InnoDB 5.7 from mysql-5.7.9 (MariaDB 10.2.2). |
innodb_locks_unsafe_for_binlog | Deprecated in MariaDB 10.0. Use READ COMMITTED transaction isolation level instead. |
innodb_rollback_segments | Deprecated and replaced by innodb_undo_logs in MariaDB 10.0. |
innodb_stats_sample_pages | Deprecated in MariaDB 10.0. Use innodb_stats_transient_sample_pages instead. |
max_long_data_size | Deprecated and replaced by max_allowed_packet in MariaDB 5.5. |
multi_range_count | Deprecated and has had no effect since MariaDB 5.3. |
thread_concurrency | Deprecated and has had no effect since MariaDB 5.5. |
timed_mutexes | Deprecated and has had no effect since MariaDB 5.5. |
Deprecated Options
The following options have been deprecated. They have not yet been removed, but will be in a future version, and should ideally no longer be used.
Option | Reason |
---|---|
innodb_adaptive_max_sleep_delay | No need for thread throttling any more. |
innodb_background_scrub_data_check_interval | Problematic ‘background scrubbing’ code removed. |
innodb_background_scrub_data_interval | Problematic ‘background scrubbing’ code removed. |
innodb_background_scrub_data_compressed | Problematic ‘background scrubbing’ code removed. |
innodb_background_scrub_data_uncompressed | Problematic ‘background scrubbing’ code removed. |
innodb_buffer_pool_instances | Having more than one buffer pool is no longer necessary. |
innodb_commit_concurrency | No need for thread throttling any more. |
innodb_concurrency_tickets | No need for thread throttling any more. |
innodb_log_files_in_group | Redo log was unnecessarily split into multiple files. Limited to 1 from MariaDB 10.5. |
innodb_log_optimize_ddl | Prohibited optimizations. |
innodb_page_cleaners | Having more than one page cleaner task no longer necessary. |
innodb_replication_delay | No need for thread throttling any more. |
innodb_scrub_log | Never really worked as intended, redo log format is being redone. |
innodb_scrub_log_speed | Never really worked as intended, redo log format is being redone. |
innodb_thread_concurrency | No need for thread throttling any more. |
innodb_thread_sleep_delay | No need for thread throttling any more. |
innodb_undo_logs | It always makes sense to use the maximum number of rollback segments. |
large_page_size | Unused since multiple page size support was added. |
Major New Features To Consider
You might consider using the following major new features in MariaDB 10.5:
- The S3 storage engine allows one to archive MariaDB tables in Amazon S3, or any third-party public or private cloud that implements S3 API.
- ColumnStore columnar storage engine.
- See also System Variables Added in MariaDB 10.5.
See Also
© 2021 MariaDB
Licensed under the Creative Commons Attribution 3.0 Unported License and the GNU Free Documentation License.
https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/