Chapter 5. Migration

This chapter provides information on migrating to versions of components included in Red Hat Software Collections 3.8.

5.1. Migrating to MariaDB 10.5

The rh-mariadb105 Software Collection is available for Red Hat Enterprise Linux 7, which includes MariaDB 5.5 as the default MySQL implementation.
The rh-mariadb105 Software Collection does not conflict with the mysql or mariadb packages from the core systems. Unless the *-syspaths packages are installed (see below), it is possible to install the rh-mariadb105 Software Collection together with the mysql or mariadb packages. It is also possible to run both versions at the same time, however, the port number and the socket in the my.cnf files need to be changed to prevent these specific resources from conflicting. Additionally, it is possible to install the rh-mariadb105 Software Collection while the rh-mariadb103 Collection is still installed and even running.
The rh-mariadb105 Software Collection includes the rh-mariadb105-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mariadb105*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mariadb105* packages. Note that the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mariadb103 and rh-mysql80 Software Collections. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.
The recommended migration path from MariaDB 5.5 to MariaDB 10.5 is to upgrade to MariaDB 10.0 first, and then upgrade by one version successively. For details, see instructions in earlier Red Hat Software Collections Release Notes: Migrating to MariaDB 10.0, Migrating to MariaDB 10.1, Migrating to MariaDB 10.2, and Migrating to MariaDB 10.3. Note that MariaDB 10.4 is not available as a Software Collection, so you must migrate directly from rh-mariadb103 to rh-mariadb105.

Note

The rh-mariadb105 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.

5.1.1. Notable Differences Between the rh-mariadb103 and rh-mariadb105 Software Collections

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 adds mariadb-* named binaries and mysql* symbolic links pointing to the mariadb-* binaires. For example, the mysqladmin, mysqlaccess, and mysqlshow symlinks point to the mariadb-admin, mariadb-access, and mariadb-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 to optimistic.
  • In the InnoDB storage engine, defaults of the following variables have been changed: innodb_adaptive_hash_index to OFF and innodb_checksum_algorithm to full_crc32.
  • MariaDB now uses the libedit implementation of the underlying software managing the MariaDB command history (the .mysql_history file) instead of the previously used readline 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.

    Note

    To increase security, you can consider not maintaining a history file. To disable the command history recording:
    1. Remove the .mysql_history file if it exists.
    2. 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
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 from 1 to 0 to prevent end users from starting wsrep 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 utilize additional PAM modules.
  • The helper binary can be executed only by users in the mysql group. By default, the group contains only the mysql user. Red Hat recommends that administrators do not add more users to the mysql 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 subpackage, mariadb-pam. As a result, no new setuid root binary is introduced on systems that do not use PAM authentication for MariaDB.
  • The rh-mariadb105-mariadb-pam package contains both PAM plug-in versions: version 2.0 is the default, and version 1.0 is available as the auth_pam_v1 shared object library.
  • The rh-mariadb105-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 the rh-mariadb105-mariadb-pam package manually.
For more information, see the upstream documentation about changes in MariaDB 10.4 and changes in MariaDB 10.5. See also upstream information about upgrading to MariaDB 10.4 and upgrading to MariaDB 10.5.

5.1.2. Upgrading from the rh-mariadb103 to the rh-mariadb105 Software Collection

Important

Prior to upgrading, back up all your data, including any MariaDB databases.
  1. Stop the rh-mariadb103 database server if it is still running.
    Before stopping the server, set the innodb_fast_shutdown option to 0, so that InnoDB performs a slow shutdown, including a full purge and insert buffer merge. Read more about this option in the upstream documentation. This operation can take a longer time than in case of a normal shutdown. 
    mysql -uroot -p -e "SET GLOBAL innodb_fast_shutdown = 0"
    Stop the rh-mariadb103 server: 
    systemctl stop rh-mariadb103-mariadb.service
  2. Install the rh-mariadb105 Software Collection, including the subpackage providing the mysql_upgrade utility: 
    yum install rh-mariadb105-mariadb-server rh-mariadb105-mariadb-server-utils
    Note that it is possible to install the rh-mariadb105 Software Collection while the rh-mariadb103 Software Collection is still installed because these Collections do not conflict.
  3. Inspect configuration of rh-mariadb105, which is stored in the /etc/opt/rh/rh-mariadb105/my.cnf file and the /etc/opt/rh/rh-mariadb105/my.cnf.d/ directory. Compare it with configuration of rh-mariadb103 stored in /etc/opt/rh/rh-mariadb103/my.cnf and /etc/opt/rh/rh-mariadb103/my.cnf.d/ and adjust it if necessary.
  4. All data of the rh-mariadb103 Software Collection is stored in the /var/opt/rh/rh-mariadb103/lib/mysql/ directory unless configured differently. Copy the whole content of this directory to /var/opt/rh/rh-mariadb105/lib/mysql/. You can move the content but remember to back up your data before you continue to upgrade. Make sure the data is owned by the mysql user and SELinux context is correct.
  5. Start the rh-mariadb105 database server: 
    systemctl start rh-mariadb105-mariadb.service
  6. Perform the data migration. Note that running the mysql_upgrade command is required due to upstream changes introduced in MDEV-14637. 
    scl enable rh-mariadb105 mysql_upgrade
    If the root user has a non-empty password defined (it should have a password defined), it is necessary to call the mysql_upgrade utility with the -p option and specify the password: 
    scl enable rh-mariadb105 -- mysql_upgrade -p
    Note that when the rh-mariadb105*-syspaths packages are installed, the scl enable command is not required. However, the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mariadb103 and rh-mysql80 Software Collections.

5.2. Migrating to MySQL 8.0

The rh-mysql80 Software Collection is available for Red Hat Enterprise Linux 7, which includes MariaDB 5.5 as the default MySQL implementation.
The rh-mysql80 Software Collection conflicts neither with the mysql or mariadb packages from the core systems nor with the rh-mysql* or rh-mariadb* Software Collections, unless the *-syspaths packages are installed (see below). It is also possible to run multiple versions at the same time; however, the port number and the socket in the my.cnf files need to be changed to prevent these specific resources from conflicting.
Note that it is possible to upgrade to MySQL 8.0 only from MySQL 5.7. If you need to upgrade from an earlier version, upgrade to MySQL 5.7 first. For instructions, see Migration to MySQL 5.7.

5.2.1. Notable Differences Between MySQL 5.7 and MySQL 8.0

Differences Specific to the rh-mysql80 Software Collection

  • The MySQL 8.0 server provided by the rh-mysql80 Software Collection is configured to use mysql_native_password as the default authentication plug-in because client tools and libraries in Red Hat Enterprise Linux 7 are incompatible with the caching_sha2_password method, which is used by default in the upstream MySQL 8.0 version.
    To change the default authentication plug-in to caching_sha2_password, edit the /etc/opt/rh/rh-mysql80/my.cnf.d/mysql-default-authentication-plugin.cnf file as follows: 
    [mysqld]
default_authentication_plugin=caching_sha2_password
    For more information about the caching_sha2_password authentication plug-in, see the upstream documentation.
  • The rh-mysql80 Software Collection includes the rh-mysql80-syspaths package, which installs the rh-mysql80-mysql-config-syspaths, rh-mysql80-mysql-server-syspaths, and rh-mysql80-mysql-syspaths packages. These subpackages provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mysql80*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mysql80* packages. Note that the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mariadb103 and rh-mariadb105 Software Collections. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.

General Changes in MySQL 8.0

  • Binary logging is enabled by default during the server startup. The log_bin system variable is now set to ON by default even if the --log-bin option has not been specified. To disable binary logging, specify the --skip-log-bin or --disable-log-bin option at startup.
  • For a CREATE FUNCTION statement to be accepted, at least one of the DETERMINISTIC, NO SQL, or READS SQL DATA keywords must be specified explicitly, otherwise an error occurs.
  • Certain features related to account management have been removed. Namely, using the GRANT statement to modify account properties other than privilege assignments, such as authentication, SSL, and resource-limit, is no longer possible. To establish the mentioned properties at account-creation time, use the CREATE USER statement. To modify these properties, use the ALTER USER statement.
  • Certain SSL-related options have been removed on the client-side. Use the --ssl-mode=REQUIRED option instead of --ssl=1 or --enable-ssl. Use the --ssl-mode=DISABLED option instead of --ssl=0, --skip-ssl, or --disable-ssl. Use the --ssl-mode=VERIFY_IDENTITY option instead of --ssl-verify-server-cert options. Note that these options remain unchanged on the server side.
  • The default character set has been changed from latin1 to utf8mb4.
  • The utf8 character set is currently an alias for utf8mb3 but in the future, it will become a reference to utf8mb4. To prevent ambiguity, specify utf8mb4 explicitly for character set references instead of utf8.
  • Setting user variables in statements other than SET has been deprecated.
  • The log_syslog variable, which previously configured error logging to the system logs, has been removed.
  • Certain incompatible changes to spatial data support have been introduced.
  • The deprecated ASC or DESC qualifiers for GROUP BY clauses have been removed. To produce a given sort order, provide an ORDER BY clause.
For detailed changes in MySQL 8.0 compared to earlier versions, see the upstream documentation: What Is New in MySQL 8.0 and Changes Affecting Upgrades to MySQL 8.0.

5.2.2. Upgrading to the rh-mysql80 Software Collection

Important

Prior to upgrading, back-up all your data, including any MySQL databases.
  1. Install the rh-mysql80 Software Collection. 
    yum install rh-mysql80-mysql-server
  2. Inspect the configuration of rh-mysql80, which is stored in the /etc/opt/rh/rh-mysql80/my.cnf file and the /etc/opt/rh/rh-mysql80/my.cnf.d/ directory. Compare it with the configuration of rh-mysql57 stored in /etc/opt/rh/rh-mysql57/my.cnf and /etc/opt/rh/rh-mysql57/my.cnf.d/ and adjust it if necessary.
  3. Stop the rh-mysql57 database server, if it is still running. 
    systemctl stop rh-mysql57-mysqld.service
  4. All data of the rh-mysql57 Software Collection is stored in the /var/opt/rh/rh-mysql57/lib/mysql/ directory. Copy the whole content of this directory to /var/opt/rh/rh-mysql80/lib/mysql/. You can also move the content but remember to back up your data before you continue to upgrade.
  5. Start the rh-mysql80 database server. 
    systemctl start rh-mysql80-mysqld.service
  6. Perform the data migration. 
    scl enable rh-mysql80 mysql_upgrade
    If the root user has a non-empty password defined (it should have a password defined), it is necessary to call the mysql_upgrade utility with the -p option and specify the password. 
    scl enable rh-mysql80 -- mysql_upgrade -p
    Note that when the rh-mysql80*-syspaths packages are installed, the scl enable command is not required. However, the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mariadb103 and rh-mariadb105 Software Collections.

5.3. Migrating to PostgreSQL 13

Red Hat Software Collections 3.8 is distributed with PostgreSQL 13, available only for Red Hat Enterprise Linux 7. The rh-postgresql13 Software Collection can be safely installed on the same machine in parallel with the base Red Hat Enterprise Linux system version of PostgreSQL or any PostgreSQL Software Collection. It is also possible to run more than one version of PostgreSQL on a machine at the same time, but you need to use different ports or IP addresses and adjust SELinux policy.
The rh-postgresql13 Software Collection includes the rh-postgresql13-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-postgresql13*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-postgresql13* packages. Note that the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.

Important

Before migrating to PostgreSQL 13, see the upstream compatibility notes for PostgreSQL 13.
In case of upgrading the PostgreSQL database in a container, see the container-specific instructions.
The following table provides an overview of different paths in a Red Hat Enterprise Linux 7 system version of PostgreSQL provided by the postgresql package, and in the rh-postgresql12 and rh-postgresql13 Software Collections.

Table 5.1. Diferences in the PostgreSQL paths

Contentpostgresqlrh-postgresql12rh-postgresql13
Executables/usr/bin//opt/rh/rh-postgresql12/root/usr/bin//opt/rh/rh-postgresql13/root/usr/bin/
Libraries/usr/lib64//opt/rh/rh-postgresql12/root/usr/lib64//opt/rh/rh-postgresql13/root/usr/lib64/
Documentation/usr/share/doc/postgresql/html//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql13/root/usr/share/doc/postgresql/html/
PDF documentation/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql13/root/usr/share/doc/postgresql-docs/
Contrib documentation/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql13/root/usr/share/doc/postgresql-contrib/
Sourcenot installednot installednot installed
Data/var/lib/pgsql/data//var/opt/rh/rh-postgresql12/lib/pgsql/data//var/opt/rh/rh-postgresql13/lib/pgsql/data/
Backup area/var/lib/pgsql/backups//var/opt/rh/rh-postgresql12/lib/pgsql/backups//var/opt/rh/rh-postgresql13/lib/pgsql/backups/
Templates/usr/share/pgsql//opt/rh/rh-postgresql12/root/usr/share/pgsql//opt/rh/rh-postgresql13/root/usr/share/pgsql/
Procedural Languages/usr/lib64/pgsql//opt/rh/rh-postgresql12/root/usr/lib64/pgsql//opt/rh/rh-postgresql13/root/usr/lib64/pgsql/
Development Headers/usr/include/pgsql//opt/rh/rh-postgresql12/root/usr/include/pgsql//opt/rh/rh-postgresql13/root/usr/include/pgsql/
Other shared data/usr/share/pgsql//opt/rh/rh-postgresql12/root/usr/share/pgsql//opt/rh/rh-postgresql13/root/usr/share/pgsql/
Regression tests/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql12/root/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql13/root/usr/lib64/pgsql/test/regress/ (in the -test package)

5.3.1. Migrating from a Red Hat Enterprise Linux System Version of PostgreSQL to the PostgreSQL 13 Software Collection

Red Hat Enterprise Linux 7 is distributed with PostgreSQL 9.2. To migrate your data from a Red Hat Enterprise Linux system version of PostgreSQL to the rh-postgresql13 Software Collection, you can either perform a fast upgrade using the pg_upgrade tool (recommended), or dump the database data into a text file with SQL commands and import it in the new database. Note that the second method is usually significantly slower and may require manual fixes; see the PostgreSQL documentation for more information about this upgrade method.

Important

Before migrating your data from a Red Hat Enterprise Linux system version of PostgreSQL to PostgreSQL 13, make sure that you back up all your data, including the PostgreSQL database files, which are by default located in the /var/lib/pgsql/data/ directory.

Procedure 5.1. Fast Upgrade Using the pg_upgrade Tool

To perform a fast upgrade of your PostgreSQL server, complete the following steps:
  1. Stop the old PostgreSQL server to ensure that the data is not in an inconsistent state. To do so, type the following at a shell prompt as root: 
    systemctl stop postgresql.service
    To verify that the server is not running, type: 
    systemctl status postgresql.service
  2. Verify that the old directory /var/lib/pgsql/data/ exists: 
    file /var/lib/pgsql/data/
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql13/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql13/lib/pgsql/data/
    If you are running a fresh installation of PostgreSQL 13, this directory should not be present in your system. If it is, back it up by running the following command as root: 
    mv /var/opt/rh/rh-postgresql13/lib/pgsql/data{,-scl-backup}
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql13 -- postgresql-setup --upgrade
    Alternatively, you can use the /opt/rh/rh-postgresql13/root/usr/bin/postgresql-setup --upgrade command.
    Note that you can use the --upgrade-from option for upgrading from different versions of PostgreSQL. The list of possible upgrade scenarios is available using the --upgrade-ids option.
    It is recommended that you read the resulting /var/lib/pgsql/upgrade_rh-postgresql13-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    systemctl start rh-postgresql13-postgresql.service
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql13 ~/analyze_new_cluster.sh'
  6. Optionally, you can configure the PostgreSQL 13 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    To enable the PostgreSQL 13 server, type as root: 
    chkconfig rh-postgresql13-postgresql on
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql13/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

Procedure 5.2. Performing a Dump and Restore Upgrade

To perform a dump and restore upgrade of your PostgreSQL server, complete the following steps:
  1. Ensure that the old PostgreSQL server is running by typing the following at a shell prompt as root: 
    systemctl start postgresql.service
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'pg_dumpall > ~/pgdump_file.sql'
  3. Stop the old server by running the following command as root: 
    systemctl stop postgresql.service
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql13 -- postgresql-setup initdb
  5. Start the new server as root: 
    systemctl start rh-postgresql13-postgresql.service
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql13 "psql -f ~/pgdump_file.sql postgres"'
  7. Optionally, you can configure the PostgreSQL 13 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    To enable the PostgreSQL 13 server, type as root: 
    chkconfig rh-postgresql13-postgresql on
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql13/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

5.3.2. Migrating from the PostgreSQL 12 Software Collection to the PostgreSQL 13 Software Collection

To migrate your data from the rh-postgresql12 Software Collection to the rh-postgresql13 Collection, you can either perform a fast upgrade using the pg_upgrade tool (recommended), or dump the database data into a text file with SQL commands and import it in the new database. Note that the second method is usually significantly slower and may require manual fixes; see the PostgreSQL documentation for more information about this upgrade method.

Important

Before migrating your data from PostgreSQL 12 to PostgreSQL 13, make sure that you back up all your data, including the PostgreSQL database files, which are by default located in the /var/opt/rh/rh-postgresql12/lib/pgsql/data/ directory.

Procedure 5.3. Fast Upgrade Using the pg_upgrade Tool

To perform a fast upgrade of your PostgreSQL server, complete the following steps:
  1. Stop the old PostgreSQL server to ensure that the data is not in an inconsistent state. To do so, type the following at a shell prompt as root: 
    systemctl stop rh-postgresql12-postgresql.service
    To verify that the server is not running, type: 
    systemctl status rh-postgresql12-postgresql.service
  2. Verify that the old directory /var/opt/rh/rh-postgresql12/lib/pgsql/data/ exists: 
    file /var/opt/rh/rh-postgresql12/lib/pgsql/data/
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql13/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql13/lib/pgsql/data/
    If you are running a fresh installation of PostgreSQL 13, this directory should not be present in your system. If it is, back it up by running the following command as root: 
    mv /var/opt/rh/rh-postgresql13/lib/pgsql/data{,-scl-backup}
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql13 -- postgresql-setup --upgrade --upgrade-from=rh-postgresql12-postgresql
    Alternatively, you can use the /opt/rh/rh-postgresql13/root/usr/bin/postgresql-setup --upgrade --upgrade-from=rh-postgresql12-postgresql command.
    Note that you can use the --upgrade-from option for upgrading from different versions of PostgreSQL. The list of possible upgrade scenarios is available using the --upgrade-ids option.
    It is recommended that you read the resulting /var/lib/pgsql/upgrade_rh-postgresql13-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    systemctl start rh-postgresql13-postgresql.service
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql13 ~/analyze_new_cluster.sh'
  6. Optionally, you can configure the PostgreSQL 13 server to start automatically at boot time. To disable the old PostgreSQL 12 server, type the following command as root: 
    chkconfig rh-postgresql12-postgreqsql off
    To enable the PostgreSQL 13 server, type as root: 
    chkconfig rh-postgresql13-postgresql on
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql13/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

Procedure 5.4. Performing a Dump and Restore Upgrade

To perform a dump and restore upgrade of your PostgreSQL server, complete the following steps:
  1. Ensure that the old PostgreSQL server is running by typing the following at a shell prompt as root: 
    systemctl start rh-postgresql12-postgresql.service
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'scl enable rh-postgresql12 "pg_dumpall > ~/pgdump_file.sql"'
  3. Stop the old server by running the following command as root: 
    systemctl stop rh-postgresql12-postgresql.service
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql13 -- postgresql-setup initdb
  5. Start the new server as root: 
    systemctl start rh-postgresql13-postgresql.service
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql13 "psql -f ~/pgdump_file.sql postgres"'
  7. Optionally, you can configure the PostgreSQL 13 server to start automatically at boot time. To disable the old PostgreSQL 12 server, type the following command as root: 
    chkconfig rh-postgresql12-postgresql off
    To enable the PostgreSQL 13 server, type as root: 
    chkconfig rh-postgresql13-postgresql on
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql13/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

5.4. Migrating to nginx 1.20

The root directory for the rh-nginx120 Software Collection is located in /opt/rh/rh-nginx120/root/. The error log is stored in /var/opt/rh/rh-nginx120/log/nginx by default.
Configuration files are stored in the /etc/opt/rh/rh-nginx120/nginx/ directory. Configuration files in nginx 1.20 have the same syntax and largely the same format as previous nginx Software Collections.
Configuration files (with a .conf extension) in the /etc/opt/rh/rh-nginx120/nginx/default.d/ directory are included in the default server block configuration for port 80.

Important

Before upgrading from nginx 1.18 to nginx 1.20, back up all your data, including web pages located in the /opt/rh/nginx118/root/ tree and configuration files located in the /etc/opt/rh/nginx118/nginx/ tree.
If you have made any specific changes, such as changing configuration files or setting up web applications, in the /opt/rh/nginx118/root/ tree, replicate those changes in the new /opt/rh/rh-nginx120/root/ and /etc/opt/rh/rh-nginx120/nginx/ directories, too.
You can use this procedure to upgrade directly from nginx 1.16 to nginx 1.20. Use the appropriate paths in this case.
For the official nginx documentation, refer to http://nginx.org/en/docs/.

5.5. Migrating to Redis 6

Redis 5.0, provided by the rh-redis5 Software Collection, is mostly a strict subset of Redis 6.0. Therefore, no major issues should occur when upgrading from version 5.0 to version 6.0.
To upgrade a Redis Cluster to version 6.0, a mass restart of all the instances is needed.

Compatibility Notes

  • When a set key does not exist, the SPOP <count> command no longer returns null. In Redis 6, the command returns an empty set in this scenario, similar to a situation when it is called with a 0 argument.
  • For minor non-backward compatible changes, see the upstream release notes.