Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 5. Migration

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

5.1. Migrating to MariaDB 10.3
Copiar enlace

The rh-mariadb103 Software Collection is available for Red Hat Enterprise Linux 7, which includes MariaDB 5.5 as the default MySQL implementation.
The rh-mariadb103 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-mariadb103 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-mariadb103 Software Collection while the rh-mariadb102 Collection is still installed and even running.
The rh-mariadb103 Software Collection includes the rh-mariadb103-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mariadb103*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mariadb103* packages. Note that the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mariadb102 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.3 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, and Migrating to MariaDB 10.2.

Note

The rh-mariadb103 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.
  • The mariadb-bench subpackage has been removed.
  • The default allowed level of the plug-in maturity has been changed to one level less than the server maturity. As a result, plug-ins with a lower maturity level that were previously working, will no longer load.
For more information regarding MariaDB 10.3, see the upstream documentation about changes and about upgrading.

Important

Prior to upgrading, back up all your data, including any MariaDB databases.
  1. Stop the rh-mariadb102 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"
    Copy to Clipboard Toggle word wrap
    Stop the rh-mariadb102 server. 
    systemctl stop rh-mariadb102-mariadb.service
    Copy to Clipboard Toggle word wrap
  2. Install the rh-mariadb103 Software Collection, including the subpackage providing the mysql_upgrade utility. 
    yum install rh-mariadb103-mariadb-server rh-mariadb103-mariadb-server-utils
    Copy to Clipboard Toggle word wrap
    Note that it is possible to install the rh-mariadb103 Software Collection while the rh-mariadb102 Software Collection is still installed because these Collections do not conflict.
  3. Inspect configuration of rh-mariadb103, which is stored in the /etc/opt/rh/rh-mariadb103/my.cnf file and the /etc/opt/rh/rh-mariadb103/my.cnf.d/ directory. Compare it with configuration of rh-mariadb102 stored in /etc/opt/rh/rh-mariadb102/my.cnf and /etc/opt/rh/rh-mariadb102/my.cnf.d/ and adjust it if necessary.
  4. All data of the rh-mariadb102 Software Collection is stored in the /var/opt/rh/rh-mariadb102/lib/mysql/ directory unless configured differently. Copy the whole content of this directory to /var/opt/rh/rh-mariadb103/lib/mysql/. You can move the content but remember to back up your data before you continue to upgrade. Make sure the data are owned by the mysql user and SELinux context is correct.
  5. Start the rh-mariadb103 database server. 
    systemctl start rh-mariadb103-mariadb.service
    Copy to Clipboard Toggle word wrap
  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-mariadb103 mysql_upgrade
    Copy to Clipboard Toggle word wrap
    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-mariadb103 -- mysql_upgrade -p
    Copy to Clipboard Toggle word wrap
    Note that when the rh-mariadb103*-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-mariadb102 and rh-mysql80 Software Collections.

5.2. Migrating to MariaDB 10.2
Copiar enlace

Red Hat Enterprise Linux 6 contains MySQL 5.1 as the default MySQL implementation. Red Hat Enterprise Linux 7 includes MariaDB 5.5 as the default MySQL implementation. MariaDB is a community-developed drop-in replacement for MySQL. MariaDB 10.1 has been available as a Software Collection since Red Hat Software Collections 2.2; Red Hat Software Collections 3.4 is distributed with MariaDB 10.2.
The rh-mariadb102 Software Collection, available for both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7, 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-mariadb102 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-mariadb102 Software Collection while the rh-mariadb101 Collection is still installed and even running.
The recommended migration path from MariaDB 5.5 to MariaDB 10.3 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 and Migrating to MariaDB 10.1.
For more information about MariaDB 10.2, see the upstream documentation about changes in version 10.2 and about upgrading.

Note

The rh-mariadb102 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.
Major changes in MariaDB 10.2 are described in the Red Hat Software Collections 3.0 Release Notes.
Since MariaDB 10.2, behavior of the SQL_MODE variable has been changed; see the upstream documentation for details.
Multiple options have changed their default values or have been deprecated or removed. For details, see the Knowledgebase article Migrating from MariaDB 10.1 to the MariaDB 10.2 Software Collection.
The rh-mariadb102 Software Collection includes the rh-mariadb102-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mariadb102*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mariadb102* packages. Note that the *-syspaths packages conflict with the corresponding packages from the base Red Hat Enterprise Linux system and from the rh-mysql80 Software Collection. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.

Important

Prior to upgrading, back up all your data, including any MariaDB databases.
  1. Stop the rh-mariadb101 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"
    Copy to Clipboard Toggle word wrap
    Stop the rh-mariadb101 server. 
    service rh-mariadb101-mariadb stop
    Copy to Clipboard Toggle word wrap
  2. Install the rh-mariadb102 Software Collection. 
    yum install rh-mariadb102-mariadb-server
    Copy to Clipboard Toggle word wrap
    Note that it is possible to install the rh-mariadb102 Software Collection while the rh-mariadb101 Software Collection is still installed because these Collections do not conflict.
  3. Inspect configuration of rh-mariadb102, which is stored in the /etc/opt/rh/rh-mariadb102/my.cnf file and the /etc/opt/rh/rh-mariadb102/my.cnf.d/ directory. Compare it with configuration of rh-mariadb101 stored in /etc/opt/rh/rh-mariadb101/my.cnf and /etc/opt/rh/rh-mariadb101/my.cnf.d/ and adjust it if necessary.
  4. All data of the rh-mariadb101 Software Collection is stored in the /var/opt/rh/rh-mariadb101/lib/mysql/ directory unless configured differently. Copy the whole content of this directory to /var/opt/rh/rh-mariadb102/lib/mysql/. You can move the content but remember to back up your data before you continue to upgrade. Make sure the data are owned by the mysql user and SELinux context is correct.
  5. Start the rh-mariadb102 database server. 
    service rh-mariadb102-mariadb start
    Copy to Clipboard Toggle word wrap
  6. Perform the data migration. 
    scl enable rh-mariadb102 mysql_upgrade
    Copy to Clipboard Toggle word wrap
    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-mariadb102 -- mysql_upgrade -p
    Copy to Clipboard Toggle word wrap
    Note that when the rh-mariadb102*-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-mysql80 Software Collection.

5.3. Migrating to MySQL 8.0
Copiar enlace

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.3.1. Notable Differences Between MySQL 5.7 and MySQL 8.0
Copiar enlace

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
    Copy to Clipboard Toggle word wrap
    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-mariadb102 and rh-mariadb103 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 option remains 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.3.2. Upgrading to the rh-mysql80 Software Collection
Copiar enlace

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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  6. Perform the data migration. 
    scl enable rh-mysql80 mysql_upgrade
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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-mariadb102 and rh-mariadb103 Software Collections.

5.4. Migrating to MongoDB 3.6
Copiar enlace

Red Hat Software Collections 3.4 is released with MongoDB 3.6, provided by the rh-mongodb36 Software Collection and available only for Red Hat Enterprise Linux 7.
The rh-mongodb36 Software Collection includes the rh-mongodb36-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mongodb36*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mongodb36* packages. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.

5.4.1. Notable Differences Between MongoDB 3.4 and MongoDB 3.6
Copiar enlace

General Changes

The rh-mongodb36 Software Collection introduces the following significant general change:
  • On Non-Uniform Access Memory (NUMA) hardware, it is possible to configure systemd services to be launched using the numactl command; see the upstream recommendation. To use MongoDB with the numactl command, you need to install the numactl RPM package and change the /etc/opt/rh/rh-mongodb36/sysconfig/mongod and /etc/opt/rh/rh-mongodb36/sysconfig/mongos configuration files accordingly.

Compatibility Changes

MongoDB 3.6 includes various minor changes that can affect compatibility with previous versions of MongoDB:
  • MongoDB binaries now bind to localhost by default, so listening on different IP addresses needs to be explicitly enabled. Note that this is already the default behavior for systemd services distributed with MongoDB Software Collections.
  • The MONGODB-CR authentication mechanism has been deprecated. For databases with users created by MongoDB versions earlier than 3.0, upgrade authentication schema to SCRAM.
  • The HTTP interface and REST API have been removed
  • Arbiters in replica sets have priority 0
  • Master-slave replication has been deprecated
For detailed compatibility changes in MongoDB 3.6, see the upstream release notes.

Backwards Incompatible Features

The following MongoDB 3.6 features are backwards incompatible and require the version to be set to 3.6 using the featureCompatibilityVersion command:
  • UUID for collections
  • $jsonSchema document validation
  • Change streams
  • Chunk aware secondaries
  • View definitions, document validators, and partial index filters that use version 3.6 query features
  • Sessions and retryable writes
  • Users and roles with authenticationRestrictions
For details regarding backward incompatible changes in MongoDB 3.6, see the upstream release notes.

Important

Before migrating from the rh-mongodb34 to the rh-mongodb36 Software Collection, back up all your data, including any MongoDB databases, which are by default stored in the /var/opt/rh/rh-mongodb34/lib/mongodb/ directory. In addition, see the Compatibility Changes to ensure that your applications and deployments are compatible with MongoDB 3.6.
To upgrade to the rh-mongodb36 Software Collection, perform the following steps.
  1. To be able to upgrade, the rh-mongodb34 instance must have featureCompatibilityVersion set to 3.4. Check featureCompatibilityVersion: 
    ~]$ scl enable rh-mongodb34 'mongo --host localhost --port 27017 admin' --eval 'db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})'
    Copy to Clipboard Toggle word wrap
    If the mongod server is configured with enabled access control, add the --username and --password options to the mongo command.
  2. Install the MongoDB servers and shells from the rh-mongodb36 Software Collections: 
    ~]# yum install rh-mongodb36
    Copy to Clipboard Toggle word wrap
  3. Stop the MongoDB 3.4 server: 
    ~]# systemctl stop rh-mongodb34-mongod.service
    Copy to Clipboard Toggle word wrap
  4. Copy your data to the new location: 
    ~]# cp -a /var/opt/rh/rh-mongodb34/lib/mongodb/* /var/opt/rh/rh-mongodb36/lib/mongodb/
    Copy to Clipboard Toggle word wrap
  5. Configure the rh-mongodb36-mongod daemon in the /etc/opt/rh/rh-mongodb36/mongod.conf file.
  6. Start the MongoDB 3.6 server: 
    ~]# systemctl start rh-mongodb36-mongod.service
    Copy to Clipboard Toggle word wrap
  7. Enable backwards incompatible features: 
    ~]$ scl enable rh-mongodb36 'mongo --host localhost --port 27017 admin' --eval 'db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )'
    Copy to Clipboard Toggle word wrap
    If the mongod server is configured with enabled access control, add the --username and --password options to the mongo command.

    Note

    After upgrading, it is recommended to run the deployment first without enabling the backwards incompatible features for a burn-in period of time, to minimize the likelihood of a downgrade.
For detailed information about upgrading, see the upstream release notes.
For information about upgrading a Replica Set, see the upstream MongoDB Manual.
For information about upgrading a Sharded Cluster, see the upstream MongoDB Manual.

5.5. Migrating to MongoDB 3.4
Copiar enlace

The rh-mongodb34 Software Collection, available for both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7, provides MongoDB 3.4.

5.5.1. Notable Differences Between MongoDB 3.2 and MongoDB 3.4
Copiar enlace

General Changes

The rh-mongodb34 Software Collection introduces various general changes. Major changes are listed in the Knowledgebase article Migrating from MongoDB 3.2 to MongoDB 3.4. For detailed changes, see the upstream release notes.
In addition, this Software Collection includes the rh-mongodb34-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-mongodb34*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-mongodb34* packages. To find out more about syspaths, see the Red Hat Software Collections Packaging Guide.

Compatibility Changes

MongoDB 3.4 includes various minor changes that can affect compatibility with previous versions of MongoDB. For details, see the Knowledgebase article Migrating from MongoDB 3.2 to MongoDB 3.4 and the upstream documentation.
Notably, the following MongoDB 3.4 features are backwards incompatible and require that the version is set to 3.4 using the featureCompatibilityVersion command:
  • Support for creating read-only views from existing collections or other views
  • Index version v: 2, which adds support for collation, decimal data and case-insensitive indexes
  • Support for the decimal128 format with the new decimal data type
For details regarding backward incompatible changes in MongoDB 3.4, see the upstream release notes.
Note that once you have upgraded to MongoDB 3.4 and started using new features, cannot downgrade to version 3.2.7 or earlier. You can only downgrade to version 3.2.8 or later.

Important

Before migrating from the rh-mongodb32 to the rh-mongodb34 Software Collection, back up all your data, including any MongoDB databases, which are by default stored in the /var/opt/rh/rh-mongodb32/lib/mongodb/ directory. In addition, see the compatibility changes to ensure that your applications and deployments are compatible with MongoDB 3.4.
To upgrade to the rh-mongodb34 Software Collection, perform the following steps.
  1. Install the MongoDB servers and shells from the rh-mongodb34 Software Collections: 
    ~]# yum install rh-mongodb34
    Copy to Clipboard Toggle word wrap
  2. Stop the MongoDB 3.2 server: 
    ~]# systemctl stop rh-mongodb32-mongod.service
    Copy to Clipboard Toggle word wrap
    Use the service rh-mongodb32-mongodb stop command on a Red Hat Enterprise Linux 6 system.
  3. Copy your data to the new location: 
    ~]# cp -a /var/opt/rh/rh-mongodb32/lib/mongodb/* /var/opt/rh/rh-mongodb34/lib/mongodb/
    Copy to Clipboard Toggle word wrap
  4. Configure the rh-mongodb34-mongod daemon in the /etc/opt/rh/rh-mongodb34/mongod.conf file.
  5. Start the MongoDB 3.4 server: 
    ~]# systemctl start rh-mongodb34-mongod.service
    Copy to Clipboard Toggle word wrap
    On Red Hat Enterprise Linux 6, use the service rh-mongodb34-mongodb start command instead.
  6. Enable backwards-incompatible features: 
    ~]$ scl enable rh-mongodb34 'mongo --host localhost --port 27017 admin' --eval 'db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )'
    Copy to Clipboard Toggle word wrap
    If the mongod server is configured with enabled access control, add the --username and --password options to mongo command.
    Note that it is recommended to run the deployment after the upgrade without enabling these features first.
For detailed information about upgrading, see the upstream release notes.
For information about upgrading a Replica Set, see the upstream MongoDB Manual.
For information about upgrading a Sharded Cluster, see the upstream MongoDB Manual.

5.6. Migrating to PostgreSQL 12
Copiar enlace

Red Hat Software Collections 3.4 is distributed with PostgreSQL 12, available only for Red Hat Enterprise Linux 7. The rh-postgresql12 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. See Section 5.7, “Migrating to PostgreSQL 9.6” for instructions how to migrate to an earlier version or when using Red Hat Enterprise Linux 6.
The rh-postgresql12 Software Collection includes the rh-postgresql12-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-postgreqsl12*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-postgreqsl12* 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 12, see the upstream compatibility notes for PostgreSQL 11 and PostgreSQL 12.
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-postgresql10 and rh-postgresql12 Software Colections.
Expand
Table 5.1. Diferences in the PostgreSQL paths
Contentpostgresqlrh-postgresql10rh-postgresql12
Executables/usr/bin//opt/rh/rh-postgresql10/root/usr/bin//opt/rh/rh-postgresql12/root/usr/bin/
Libraries/usr/lib64//opt/rh/rh-postgresql10/root/usr/lib64//opt/rh/rh-postgresql12/root/usr/lib64/
Documentation/usr/share/doc/postgresql/html//opt/rh/rh-postgresql10/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql/html/
PDF documentation/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql10/root/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql-docs/
Contrib documentation/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql10/root/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql12/root/usr/share/doc/postgresql-contrib/
Sourcenot installednot installednot installed
Data/var/lib/pgsql/data//var/opt/rh/rh-postgresql10/lib/pgsql/data//var/opt/rh/rh-postgresql12/lib/pgsql/data/
Backup area/var/lib/pgsql/backups//var/opt/rh/rh-postgresql10/lib/pgsql/backups//var/opt/rh/rh-postgresql12/lib/pgsql/backups/
Templates/usr/share/pgsql//opt/rh/rh-postgresql10/root/usr/share/pgsql//opt/rh/rh-postgresql12/root/usr/share/pgsql/
Procedural Languages/usr/lib64/pgsql//opt/rh/rh-postgresql10/root/usr/lib64/pgsql//opt/rh/rh-postgresql12/root/usr/lib64/pgsql/
Development Headers/usr/include/pgsql//opt/rh/rh-postgresql10/root/usr/include/pgsql//opt/rh/rh-postgresql12/root/usr/include/pgsql/
Other shared data/usr/share/pgsql//opt/rh/rh-postgresql10/root/usr/share/pgsql//opt/rh/rh-postgresql12/root/usr/share/pgsql/
Regression tests/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql10/root/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql12/root/usr/lib64/pgsql/test/regress/ (in the -test package)
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-postgresql12 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 12, 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
    Copy to Clipboard Toggle word wrap
    To verify that the server is not running, type: 
    systemctl status postgresql.service
    Copy to Clipboard Toggle word wrap
  2. Verify that the old directory /var/lib/pgsql/data/ exists: 
    file /var/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql12/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql12/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    If you are running a fresh installation of PostgreSQL 12, 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-postgresql12/lib/pgsql/data{,-scl-backup}
    Copy to Clipboard Toggle word wrap
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql12 -- postgresql-setup --upgrade
    Copy to Clipboard Toggle word wrap
    Alternatively, you can use the /opt/rh/rh-postgresql12/root/usr/bin/postgresql-setup --upgrade command.
    Note that you can use the --upgrade-from option for upgrade 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-postgresql12-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    systemctl start rh-postgresql12-postgresql.service
    Copy to Clipboard Toggle word wrap
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql12 ~/analyze_new_cluster.sh'
    Copy to Clipboard Toggle word wrap
  6. Optionally, you can configure the PostgreSQL 12 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 12 server, type as root: 
    chkconfig rh-postgresql12-postgresql on
    Copy to Clipboard Toggle word wrap
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql12/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
    Copy to Clipboard Toggle word wrap
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'pg_dumpall > ~/pgdump_file.sql'
    Copy to Clipboard Toggle word wrap
  3. Stop the old server by running the following command as root: 
    systemctl stop postgresql.service
    Copy to Clipboard Toggle word wrap
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql12 -- postgresql-setup initdb
    Copy to Clipboard Toggle word wrap
  5. Start the new server as root: 
    systemctl start rh-postgresql12-postgresql.service
    Copy to Clipboard Toggle word wrap
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql12 "psql -f ~/pgdump_file.sql postgres"'
    Copy to Clipboard Toggle word wrap
  7. Optionally, you can configure the PostgreSQL 12 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 12 server, type as root: 
    chkconfig rh-postgresql12-postgresql on
    Copy to Clipboard Toggle word wrap
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql12/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.
To migrate your data from the rh-postgresql10 Software Collection to the rh-postgresql12 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 10 to PostgreSQL 12, 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-postgresql10/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-postgresql10-postgresql.service
    Copy to Clipboard Toggle word wrap
    To verify that the server is not running, type: 
    systemctl status rh-postgresql10-postgresql.service
    Copy to Clipboard Toggle word wrap
  2. Verify that the old directory /var/opt/rh/rh-postgresql10/lib/pgsql/data/ exists: 
    file /var/opt/rh/rh-postgresql10/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql12/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql12/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    If you are running a fresh installation of PostgreSQL 12, 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-postgresql12/lib/pgsql/data{,-scl-backup}
    Copy to Clipboard Toggle word wrap
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql12 -- postgresql-setup --upgrade --upgrade-from=rh-postgresql10-postgresql
    Copy to Clipboard Toggle word wrap
    Alternatively, you can use the /opt/rh/rh-postgresql12/root/usr/bin/postgresql-setup --upgrade --upgrade-from=rh-postgresql10-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-postgresql12-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    systemctl start rh-postgresql12-postgresql.service
    Copy to Clipboard Toggle word wrap
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql12 ~/analyze_new_cluster.sh'
    Copy to Clipboard Toggle word wrap
  6. Optionally, you can configure the PostgreSQL 12 server to start automatically at boot time. To disable the old PostgreSQL 10 server, type the following command as root: 
    chkconfig rh-postgresql10-postgreqsql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 12 server, type as root: 
    chkconfig rh-postgresql12-postgresql on
    Copy to Clipboard Toggle word wrap
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql12/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-postgresql10-postgresql.service
    Copy to Clipboard Toggle word wrap
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'scl enable rh-postgresql10 "pg_dumpall > ~/pgdump_file.sql"'
    Copy to Clipboard Toggle word wrap
  3. Stop the old server by running the following command as root: 
    systemctl stop rh-postgresql10-postgresql.service
    Copy to Clipboard Toggle word wrap
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql12 -- postgresql-setup initdb
    Copy to Clipboard Toggle word wrap
  5. Start the new server as root: 
    systemctl start rh-postgresql12-postgresql.service
    Copy to Clipboard Toggle word wrap
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql12 "psql -f ~/pgdump_file.sql postgres"'
    Copy to Clipboard Toggle word wrap
  7. Optionally, you can configure the PostgreSQL 12 server to start automatically at boot time. To disable the old PostgreSQL 10 server, type the following command as root: 
    chkconfig rh-postgresql10-postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 12 server, type as root: 
    chkconfig rh-postgresql12-postgresql on
    Copy to Clipboard Toggle word wrap
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql12/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

5.7. Migrating to PostgreSQL 9.6
Copiar enlace

PostgreSQL 9.6 is available for both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 and it can be safely installed on the same machine in parallel with PostgreSQL 8.4 from Red Hat Enterprise Linux 6, PostgreSQL 9.2 from Red Hat Enterprise Linux 7, or any version of PostgreSQL released in previous versions of Red Hat Software Collections. 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.

Important

In case of upgrading the PostgreSQL database in a container, see the container-specific instructions. Note that it is currently impossible to upgrade PostgreSQL from 9.5 to 9.6 in a container in an OpenShift environment that is configured with Gluster file volumes.
The most notable changes between PostgreSQL 9.5 and PostgreSQL 9.6 are described in the upstream release notes.
The rh-postgresql96 Software Collection includes the rh-postgresql96-syspaths package, which installs packages that provide system-wide wrappers for binaries, scripts, manual pages, and other. After installing the rh-postgreqsl96*-syspaths packages, users are not required to use the scl enable command for correct functioning of the binaries and scripts provided by the rh-postgreqsl96* 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.
The following table provides an overview of different paths in a Red Hat Enterprise Linux system version of PostgreSQL (postgresql) and in the postgresql92, rh-postgresql95, and rh-postgresql96 Software Collections. Note that the paths of PostgreSQL 8.4 distributed with Red Hat Enterprise Linux 6 and the system version of PostgreSQL 9.2 shipped with Red Hat Enterprise Linux 7 are the same; the paths for the rh-postgresql94 Software Collection are analogous to rh-postgresql95.
Expand
Table 5.2. Diferences in the PostgreSQL paths
Contentpostgresqlpostgresql92rh-postgresql95rh-postgresql96
Executables/usr/bin//opt/rh/postgresql92/root/usr/bin//opt/rh/rh-postgresql95/root/usr/bin//opt/rh/rh-postgresql96/root/usr/bin/
Libraries/usr/lib64//opt/rh/postgresql92/root/usr/lib64//opt/rh/rh-postgresql95/root/usr/lib64//opt/rh/rh-postgresql96/root/usr/lib64/
Documentation/usr/share/doc/postgresql/html//opt/rh/postgresql92/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql95/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql96/root/usr/share/doc/postgresql/html/
PDF documentation/usr/share/doc/postgresql-docs//opt/rh/postgresql92/root/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql95/root/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql96/root/usr/share/doc/postgresql-docs/
Contrib documentation/usr/share/doc/postgresql-contrib//opt/rh/postgresql92/root/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql95/root/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql96/root/usr/share/doc/postgresql-contrib/
Sourcenot installednot installednot installednot installed
Data/var/lib/pgsql/data//opt/rh/postgresql92/root/var/lib/pgsql/data//var/opt/rh/rh-postgresql95/lib/pgsql/data//var/opt/rh/rh-postgresql96/lib/pgsql/data/
Backup area/var/lib/pgsql/backups//opt/rh/postgresql92/root/var/lib/pgsql/backups//var/opt/rh/rh-postgresql95/lib/pgsql/backups//var/opt/rh/rh-postgresql96/lib/pgsql/backups/
Templates/usr/share/pgsql//opt/rh/postgresql92/root/usr/share/pgsql//opt/rh/rh-postgresql95/root/usr/share/pgsql//opt/rh/rh-postgresql96/root/usr/share/pgsql/
Procedural Languages/usr/lib64/pgsql//opt/rh/postgresql92/root/usr/lib64/pgsql//opt/rh/rh-postgresql95/root/usr/lib64/pgsql//opt/rh/rh-postgresql96/root/usr/lib64/pgsql/
Development Headers/usr/include/pgsql//opt/rh/postgresql92/root/usr/include/pgsql//opt/rh/rh-postgresql95/root/usr/include/pgsql//opt/rh/rh-postgresql96/root/usr/include/pgsql/
Other shared data/usr/share/pgsql//opt/rh/postgresql92/root/usr/share/pgsql//opt/rh/rh-postgresql95/root/usr/share/pgsql//opt/rh/rh-postgresql96/root/usr/share/pgsql/
Regression tests/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/postgresql92/root/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql95/root/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql96/root/usr/lib64/pgsql/test/regress/ (in the -test package)
For changes between PostgreSQL 8.4 and PostgreSQL 9.2, refer to the Red Hat Software Collections 1.2 Release Notes. Notable changes between PostgreSQL 9.2 and PostgreSQL 9.4 are described in Red Hat Software Collections 2.0 Release Notes. For differences between PostgreSQL 9.4 and PostgreSQL 9.5, refer to Red Hat Software Collections 2.2 Release Notes.
Red Hat Enterprise Linux 6 includes PostgreSQL 8.4, 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-postgresql96 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. The following procedures are applicable for both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 system versions of PostgreSQL.

Important

Before migrating your data from a Red Hat Enterprise Linux system version of PostgreSQL to PostgreSQL 9.6, 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.5. 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: 
    service postgresql stop
    Copy to Clipboard Toggle word wrap
    To verify that the server is not running, type: 
    service postgresql status
    Copy to Clipboard Toggle word wrap
  2. Verify that the old directory /var/lib/pgsql/data/ exists: 
    file /var/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql96/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql96/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    If you are running a fresh installation of PostgreSQL 9.6, 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-postgresql96/lib/pgsql/data{,-scl-backup}
    Copy to Clipboard Toggle word wrap
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql96 -- postgresql-setup --upgrade
    Copy to Clipboard Toggle word wrap
    Alternatively, you can use the /opt/rh/rh-postgresql96/root/usr/bin/postgresql-setup --upgrade command.
    Note that you can use the --upgrade-from option for upgrade 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-postgresql96-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    service rh-postgresql96-postgresql start
    Copy to Clipboard Toggle word wrap
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql96 ~/analyze_new_cluster.sh'
    Copy to Clipboard Toggle word wrap
  6. Optionally, you can configure the PostgreSQL 9.6 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 9.6 server, type as root: 
    chkconfig rh-postgresql96-postgresql on
    Copy to Clipboard Toggle word wrap
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql96/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

Procedure 5.6. 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: 
    service postgresql start
    Copy to Clipboard Toggle word wrap
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'pg_dumpall > ~/pgdump_file.sql'
    Copy to Clipboard Toggle word wrap
  3. Stop the old server by running the following command as root: 
    service postgresql stop
    Copy to Clipboard Toggle word wrap
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql96-postgresql -- postgresql-setup --initdb
    Copy to Clipboard Toggle word wrap
  5. Start the new server as root: 
    service rh-postgresql96-postgresql start
    Copy to Clipboard Toggle word wrap
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql96 "psql -f ~/pgdump_file.sql postgres"'
    Copy to Clipboard Toggle word wrap
  7. Optionally, you can configure the PostgreSQL 9.6 server to start automatically at boot time. To disable the old system PostgreSQL server, type the following command as root: 
    chkconfig postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 9.6 server, type as root: 
    chkconfig rh-postgresql96-postgresql on
    Copy to Clipboard Toggle word wrap
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql96/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.
To migrate your data from the rh-postgresql95 Software Collection to the rh-postgresql96 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 9.5 to PostgreSQL 9.6, 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-postgresql95/lib/pgsql/data/ directory.

Procedure 5.7. 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: 
    service rh-postgresql95-postgresql stop
    Copy to Clipboard Toggle word wrap
    To verify that the server is not running, type: 
    service rh-postgresql95-postgresql status
    Copy to Clipboard Toggle word wrap
  2. Verify that the old directory /var/opt/rh/rh-postgresql95/lib/pgsql/data/ exists: 
    file /var/opt/rh/rh-postgresql95/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql96/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql96/lib/pgsql/data/
    Copy to Clipboard Toggle word wrap
    If you are running a fresh installation of PostgreSQL 9.6, 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-postgresql96/lib/pgsql/data{,-scl-backup}
    Copy to Clipboard Toggle word wrap
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql96 -- postgresql-setup --upgrade --upgrade-from=rh-postgresql95-postgresql
    Copy to Clipboard Toggle word wrap
    Alternatively, you can use the /opt/rh/rh-postgresql96/root/usr/bin/postgresql-setup --upgrade --upgrade-from=rh-postgresql95-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-postgresql96-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    service rh-postgresql96-postgresql start
    Copy to Clipboard Toggle word wrap
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql96 ~/analyze_new_cluster.sh'
    Copy to Clipboard Toggle word wrap
  6. Optionally, you can configure the PostgreSQL 9.6 server to start automatically at boot time. To disable the old PostgreSQL 9.5 server, type the following command as root: 
    chkconfig rh-postgresql95-postgreqsql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 9.6 server, type as root: 
    chkconfig rh-postgresql96-postgresql on
    Copy to Clipboard Toggle word wrap
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql96/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

Procedure 5.8. 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: 
    service rh-postgresql95-postgresql start
    Copy to Clipboard Toggle word wrap
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'scl enable rh-postgresql95 "pg_dumpall > ~/pgdump_file.sql"'
    Copy to Clipboard Toggle word wrap
  3. Stop the old server by running the following command as root: 
    service rh-postgresql95-postgresql stop
    Copy to Clipboard Toggle word wrap
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql96-postgresql -- postgresql-setup --initdb
    Copy to Clipboard Toggle word wrap
  5. Start the new server as root: 
    service rh-postgresql96-postgresql start
    Copy to Clipboard Toggle word wrap
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql96 "psql -f ~/pgdump_file.sql postgres"'
    Copy to Clipboard Toggle word wrap
  7. Optionally, you can configure the PostgreSQL 9.6 server to start automatically at boot time. To disable the old PostgreSQL 9.5 server, type the following command as root: 
    chkconfig rh-postgresql95-postgresql off
    Copy to Clipboard Toggle word wrap
    To enable the PostgreSQL 9.6 server, type as root: 
    chkconfig rh-postgresql96-postgresql on
    Copy to Clipboard Toggle word wrap
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql96/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.
If you need to migrate from the postgresql92 Software Collection, refer to Red Hat Software Collections 2.0 Release Notes; the procedure is the same, you just need to adjust the version of the new Collection. The same applies to migration from the rh-postgresql94 Software Collection, which is described in Red Hat Software Collections 2.2 Release Notes.

5.8. Migrating to nginx 1.16
Copiar enlace

The root directory for the rh-nginx116 Software Collection is located in /opt/rh/rh-nginx116/root/. The error log is stored in /var/opt/rh/rh-nginx116/log/nginx by default.
Configuration files are stored in the /etc/opt/rh/rh-nginx116/nginx/ directory. Configuration files in nginx 1.16 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-nginx116/nginx/default.d/ directory are included in the default server block configuration for port 80.

Important

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

5.9. Migrating to Redis 5
Copiar enlace

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

Compatibility Notes

  • The format of RDB files has been changed. Redis 5 is able to read formats of all the earlier versions, but earlier versions are incapable of reading the Redis 5 format.
  • Since version 4.0, the Redis Cluster bus protocol is no longer compatible with Redis 3.2.
  • For minor non-backward compatible changes, see the upstream release notes for version 4.0 and version 5.0.
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat