Search
SupportConsoleDevelopersStart a trialContact

Chapter 5. Migration

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

5.1. Migrating to MariaDB 10.1

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.0 has been available as a Software Collection since Red Hat Software Collections 2.0; Red Hat Software Collections 2.2 is distributed with MariaDB 10.1.
The rh-mariadb101 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, so it is possible to install the rh-mariadb101 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-mariadb101 Software Collection while the rh-mariadb100 Collection is still installed and even running.
Note that if you are using an MariaDB 5.5, it is necessary to upgrade to the rh-mariadb100 Software Collection first, which is described in the Red Hat Software Collections 2.0 Release Notes.
For more information about MariaDB 10.1, see the upstream documentation about changes in version 10.1 and about upgrading.

Note

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

5.1.1. Notable Differences Between the mariadb100 and rh-mariadb101 Software Collections

  • Galera Cluster, a synchronous multi-master cluster, which is a standard part of MariaDB 10.1. See the Knowledgebase article about setting up Galera Cluster with the rh-mariadb101 Software Collection.
  • Since MariaDB 10.1.7, the SQL_MODE variable is by default set to NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER while in earlier versions of MariaDB no default was set. Consequently, the GRANT statement does not create a user by default. The setting of the SQL_MODE variable can be changed in the configuration file. See the upstream documentation for details.

5.1.2. Upgrading from the rh-mariadb100 to the rh-mariadb101 Software Collection

Important

Prior to upgrading, back up all your data, including any MariaDB databases.
  1. Install the rh-mariadb101 Software Collection. 
    yum install rh-mariadb101-mariadb-server
  2. Inspect the configuration of rh-mariadb101, which is stored in the /etc/opt/rh/rh-mariadb101/my.cnf file and the /etc/opt/rh/rh-mariadb101/my.cnf.d/ directory. Compare it with the configuration of rh-mariadb100 stored in /etc/opt/rh/rh-mariadb100/my.cnf and /etc/opt/rh/rh-mariadb100/my.cnf.d/ and adjust it if necessary.
  3. Stop the rh-mariadb100 database server, if it is still running. 
    service rh-mariadb100-mariadb stop
  4. All the data of the rh-mariadb100 Software Collection is stored in the /var/opt/rh/rh-mariadb100/lib/mysql/ directory. Copy the whole content of this directory to /var/opt/rh/rh-mariadb101/lib/mysql/. You can also move the content but remember to back up your data before you continue to upgrade.
  5. Start the rh-mariadb101 database server. 
    service rh-mariadb101-mariadb start
  6. Perform the data migration. 
    scl enable rh-mariadb101 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-mariadb101 -- mysql_upgrade -p

5.2. Migrating to MongoDB 3.2

Red Hat Software Collections 2.2 is shipped with MongoDB 3.2, provided by the rh-mongodb32 Software Collection and available for Red Hat Enterprise Linux 7. Previously released MongoDB Software Collections, mongodb24 and rh-mongodb26 are available for both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7. See the Red Hat Software Collections 2.0 Release Notes if you need to upgrade to MongoDB 2.6.
Note that when migrating from the rh-mongodb26 to the rh-mongodb32 Software Collection, it is necessary to first upgrade to the 3.0-series release of MongoDB, which is provided by the rh-mongodb30upg Collection.

5.2.1. Notable Differences Between MongoDB 2.6 and MongoDB 3.2

General Changes

The rh-mongodb32 Software Collection introduces several general changes listed below.
  • MongoDB now ships configuration files in the YAML format
  • MongoDB server and tools are no longer shipped in a single package; MongoDB tools are packaged in rh-mongodb32-mongo-tools
  • Improved MongoDB testsuite provided by the rh-mongodb32-mongodb-test package. For more information about usage, install this package and read the /opt/rh/rh-mongodb32/root/usr/share/mongodb-test/README file.

Compatibility Changes

MongoDB 3.2 includes various minor changes that can affect compatibility with previous versions of MongoDB.

Compatibility Changes in MongoDB 3.0

  • Configuration file options changes due to inclusion of additional storage engines
  • Data files must correspond to the configured storage engine; if files in the dbPath directory were created by a storage engine other than the current one, an error is returned
  • Changes due to using the WiredTiger storage engine: oplog entries generated by versions of MongoDB earlier than 2.2.1 are overwritten
  • Replica set configuration validation
  • The w:majority semantics has been changed so that the w:majority value is satisfied when a majority of the voting members replicates a write operation
  • The local.slaves collection has been removed
  • The FATAL replica set state no longer exists
  • The mongodump, mongorestore, mongoexport, mongoimport, mongofiles, and mongooplog tools must connect to a running MongoDB instance
  • The MongoDB 2.4 user model has been removed
  • The localhost exception has been changed so that it allows to create only the first user on the admin database
  • The db.addUser() function has been removed; use db.createUser() and db.updateUser() instead
  • TLS/SSL changes
  • The mongo shell versions earlier than 3.0 are not compatible with 3.0 deployments of MongoDB
  • Index changes
  • Direct access to the system.indexes and system.namespaces collections has been deprecated
  • The following commands have been deprecated: closeAllDatabases, getoptime, text, indexStats, db.collection.getIndexStats(), and db.collection.indexStats()
  • The Date and Timestamp data types are no longer equivalent for comparison purposes
For details regarding compatibility changes in Mongodb 3.0, refer to the upstream release notes.

Compatibility Changes in MongoDB 3.2

  • The WiredTiger storage engine is now the default one
  • The JavaScript engine has been changed from V8 to SpiderMonkey
  • Creation of version 0 indexes is now disallowed
  • Aggregation compatibility changes
For detailed compatibility changes in MongoDB 3.2, see the upstream release notes.

5.2.2. Upgrading from the rh-mongodb26 to the rh-mongodb32 Software Collection

Note that once you have upgraded to MongoDB 3.2 and started using new features, you cannot downgrade to any earlier version.

Important

Before migrating from the rh-mongodb26 to the rh-mongodb32 Software Collection, back up all your data, including any MongoDB databases, which are by default stored in the /var/opt/rh/rh-mongodb26/lib/mongodb/ directory.
To upgrade to the rh-mongodb32 Software Collection, perform the following steps.
  1. Install the MongoDB servers and shells from the rh-mongodb30upg and rh-mongodb32 Software Collections: 
    ~]# yum install rh-mongodb30upg rh-mongodb30upg-mongodb rh-mongodb32 rh-mongodb32-mongodb
  2. Connect the mongo shell from the rh-mongodb26 Collection to your MongoDB 2.6 server (for example, running on localhost, port 27017). 
    ~]$ scl enable rh-mongodb26 'mongo --host localhost --port 27017 admin'
  3. In the mongo shell, check your data set for compatibility issues mentioned above and fix the ones that affect your application.
  4. Stop the MongoDB 2.6 server: 
    ~]# systemctl stop rh-mongodb26-mongod.service
  5. Copy your data to the new location: 
    ~]# cp -a /var/opt/rh/rh-mongodb26/lib/mongodb/* /var/opt/rh/rh-mongodb32/lib/mongodb
  6. Change the dbpath variable in the /etc/opt/rh/rh-mongodb30upg/mongod.conf file to /var/opt/rh/rh-mongodb32/lib/mongodb/.
  7. Start the MongoDB server from the rh-mongodb30upg Software Collection: 
    ~]# systemctl start rh-mongodb30upg-mongod.service
  8. Connect the mongo shell from the rh-mongodb32 Collection to your MongoDB 3.0 server (for example, running on localhost, port 27017). 
    ~]$ scl enable rh-mongodb30upg 'mongo --host localhost --port 27017 admin'
  9. In the mongo shell, check your data set for compatibility issues mentioned above and fix the ones that affect your application.
  10. Stop the MongoDB 3.0 server. 
    ~]# systemctl stop rh-mongodb30upg-mongod.service
  11. Configure the rh-mongodb32-mongod daemon in the /etc/opt/rh/rh-mongodb32/mongod.conf file.
  12. MongoDB 3.2 has the new default storage engine, WiredTiger, which introduces performance improvements. To be able to run the MongoDB server with old data, configure the rh-mongodb32-mongod daemon to use the old storage engine. Uncomment the engine property in the storage section in the /etc/opt/rh/rh-mongodb32/mongod.conf file and change its value to mmapv1.
  13. Start the MongoDB 3.2 server. 
    ~]# systemctl start rh-mongodb32-mongod.service
  14. If you want to use the WiredTiger storage engine, you have to perform additional migration steps described in the MongoDB documentation. 
    ~]# yum install rh-mongodb32-mongo-tools
~]$ scl enable rh-mongodb32 'mongodump --out ~/mongodb.dump'
~]# systemctl stop rh-mongodb32-mongod.service
~]# rm -rf /var/opt/rh/rh-mongodb32/lib/mongodb/*
    Change the engine property in the /etc/opt/rh/rh-mongodb32/mongod.conf to wiredTiger. 
    ~]# systemctl start rh-mongodb32-mongod.service
~]$ scl enable rh-mongodb32 'mongorestore ~/mongodb.dump'
For detailed information about upgrading, see the upstream MongoDB 3.0 and MongoDB 3.2 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.3. Migrating to MySQL 5.6

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. In addition to these basic versions, MySQL 5.5 has been available as a Software Collection for Red Hat Enterprise Linux 6 since Red Hat Software Collections 1.0 and for Red Hat Enterprise Linux 7 since Red Hat Software Collections 1.1.
The rh-mysql56 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, so it is possible to install the rh-mysql56 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.
Note that it is possible to upgrade to MySQL 5.6 only from MySQL 5.5. If you need to upgrade from an earlier version, upgrade to MySQL 5.5 first. Instructions how to upgrade to MySQL 5.5 are available in the Red Hat Software Collections 1.2 Release Notes.

5.3.1. Notable Differences Between MySQL 5.5 and MySQL 5.6

The rh-mysql56 Software Collection introduces the following notable changes:
  • The service has been renamed to rh-mysql56-mysqld in both Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7
  • The test database is no longer created by default
  • Configuration files for the rh-mysql56 Software Collection are the /etc/opt/rh/rh-mysql56/my.cnf file and in the /etc/opt/rh/rh-mysql56/my.cnf.d/ directory
  • Variable files including the database files for the rh-mysql56 Software Collection are located in the /var/opt/rh/rh-mysql56/lib/ directory
  • The log file for the MySQL daemon is /var/opt/rh/rh-mysql56/log/mysql/mysqld.log
  • The pid file for the daemon is /var/run/rh-mysql56-mysqld/mysqld.pid
Note that the rh-mysql56 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.
For detailed changes, refer to the MySQL documentation.

5.3.2. Upgrading to the rh-mysql56 Software Collection

Important

Prior to upgrading, back-up all your data, including any MySQL databases.
Upgrading can be performed either by using the mysqldump and mysqlimport utilities or using an in-place upgrade.
  • In the former scenario, the whole dump of all databases from one database is generated and mysql is run with the dump file as an input using the mysqlimport or LOAD DATA INFILE SQL command within the other database. At the same time, the appropriate daemons have to be running during both dumping and restoring. You can use the --all-databases option in the mysqldump call to include all databases in the dump. The --routines, --triggers, and --events options can also be used if needed.
  • During the in-place upgrade, the data files are copied from one database directory to another database directory. The daemons must not be running at the time of copying. Set appropriate permissions and SELinux context for the copied files.
After upgrading, start the server and run the mysql_upgrade command. Running mysql_upgrade is necessary to check and repair internal tables.
In case 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.
Service names and paths bellow depend on which version you are upgrading from.

Example 5.1. Dump and Restore Upgrade

  1. Create a backup from the mysql55 Software Collection: 
    ~]# service mysql55-mysqld start
Starting mysql55-mysqld:                                   [  OK  ]
~]# scl enable mysql55 -- mysqldump --all-databases --routines --events > dump.sql
~]# service mysql55-mysqld stop
Stopping mysql55-mysqld:                                   [  OK  ]
    For upgrading from the mariadb55 Software Collection in Red Hat Enterprise Linux 6, use mariadb55-mysqld as the service name.
    For upgrading from the mariadb55 Software Collection in Red Hat Enterprise Linux 7, use mariadb55-mariadb as the service name.
    For upgrading from MariaDB 5.5 from base Red Hat Enterprise Linux 7, use mariadb as the service name and do not use scl enable mysql55 -- when creating the dump.
  2. Import the dumped database into the rh-mysql56 Software Collection: 
    ~]# service rh-mysql56-mysqld start
Starting rh-mysql56-mysqld:                                [  OK  ]
~]# scl enable rh-mysql56 'mysql' < dump.sql
~]# scl enable rh-mysql56 'mysql_upgrade -u root -p'
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
Running 'mysqlcheck with default connection arguments
a.t1                                               OK
mysql.columns_priv                                 OK
<skipped tables list>
mysql.user                                         OK
Running 'mysql_fix_privilege_tables'...
OK

Example 5.2. In-place Upgrade from MySQL 5.5

If you are upgrading from the mysql55 Software Collection, perform the upgrade as shown in the following example: 
~]# service mysql55-mysqld stop
Stopping mysql55-mysqld                                    [  OK  ]
~]# service rh-mysql56-mysqld stop
Stopping rh-mysql56-mysqld:                                [  OK  ]
~]# rm -rf /var/opt/rh/rh-mysql56/lib/mysql/
~]# cp -r /opt/rh/mysql55/root/var/lib/mysql/ /var/opt/rh/rh-mysql56/lib/mysql/
~]# chown -R mysql:mysql /var/opt/rh/rh-mysql56/lib/mysql/
~]# restorecon -R /var/opt/rh/rh-mysql56/lib/mysql/
~]# service rh-mysql56-mysqld start
Starting rh-mysql56-mysqld:                                [  OK  ]
~]# scl enable rh-mysql56 'mysql_upgrade -u root -p'
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
Running 'mysqlcheck with default connection arguments
a.t1                                               OK
mysql.columns_priv                                 OK
<skipped tables list>
mysql.user                                         OK
Running 'mysql_fix_privilege_tables'...
OK
For upgrading from the mariadb55 Software Collection, use the /opt/rh/mariadb55/root/var/lib/mysql/ as a source when copying the data.
For upgrading from MariaDB 5.5 from base Red Hat Enterprise Linux 7, use the /var/lib/mysql/ as a source when copying the data.
For more details about migration to MySQL 5.6, refer to the MySQL documentation.

5.4. Migrating to PostgreSQL 9.5

Red Hat Software Collections 2.2 is distributed with PostgreSQL 9.5, which 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 Red Hat Software Collections 1, or PostgreSQL 9.4 from Red Hat Software Collections 2. 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.

5.4.1. Notable Differences Between PostgreSQL 9.4 and PostgreSQL 9.5

The most notable changes between PostgreSQL 9.4 and PostgreSQL 9.5 are desribed in the upstream release notes for versions 9.5, 9.5.1, and 9.5.2.
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-postgresql94, and rh-postgresql95 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.
Table 5.1. Diferences in the PostgreSQL paths
Contentpostgresqlpostgresql92rh-postgresql94rh-postgresql95
Executables/usr/bin//opt/rh/postgresql92/root/usr/bin//opt/rh/rh-postgresql94/root/usr/bin//opt/rh/rh-postgresql95/root/usr/bin/
Libraries/usr/lib64//opt/rh/postgresql92/root/usr/lib64//opt/rh/rh-postgresql94/root/usr/lib64//opt/rh/rh-postgresql95/root/usr/lib64/
Documentation/usr/share/doc/postgresql/html//opt/rh/postgresql92/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql94/root/usr/share/doc/postgresql/html//opt/rh/rh-postgresql95/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-postgresql94/root/usr/share/doc/postgresql-docs//opt/rh/rh-postgresql95/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-postgresql94/root/usr/share/doc/postgresql-contrib//opt/rh/rh-postgresql95/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-postgresql94/lib/pgsql/data//var/opt/rh/rh-postgresql95/lib/pgsql/data/
Backup area/var/lib/pgsql/backups//opt/rh/postgresql92/root/var/lib/pgsql/backups//var/opt/rh/rh-postgresql94/lib/pgsql/backups//var/opt/rh/rh-postgresql95/lib/pgsql/backups/
Templates/usr/share/pgsql//opt/rh/postgresql92/root/usr/share/pgsql//opt/rh/rh-postgresql94/root/usr/share/pgsql//opt/rh/rh-postgresql95/root/usr/share/pgsql/
Procedural Languages/usr/lib64/pgsql//opt/rh/postgresql92/root/usr/lib64/pgsql//opt/rh/rh-postgresql94/root/usr/lib64/pgsql//opt/rh/rh-postgresql95/root/usr/lib64/pgsql/
Development Headers/usr/include/pgsql//opt/rh/postgresql92/root/usr/include/pgsql//opt/rh/rh-postgresql94/root/usr/include/pgsql//opt/rh/rh-postgresql95/root/usr/include/pgsql/
Other shared data/usr/share/pgsql//opt/rh/postgresql92/root/usr/share/pgsql//opt/rh/rh-postgresql94/root/usr/share/pgsql//opt/rh/rh-postgresql95/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-postgresql94/root/usr/lib64/pgsql/test/regress/ (in the -test package)/opt/rh/rh-postgresql95/root/usr/lib64/pgsql/test/regress/ (in the -test package)
For detailed changes, see the upstream PostgreSQL 9.5 Release Notes. 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.

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

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-postgresql95 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.5, 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: 
    service postgresql stop
    To verify that the server is not running, type: 
    service postgresql status
  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-postgresql95/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql95/lib/pgsql/data/
    If you are running a fresh installation of PostgreSQL 9.5, 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-postgresql95/lib/pgsql/data{,-scl-backup}
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql95 -- postgresql-setup --upgrade
    Alternatively, you can use the /opt/rh/rh-postgresql95/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-postgresql95-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    service rh-postgresql95-postgresql start
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql95 ~/analyze_new_cluster.sh'
  6. Optionally, you can configure the PostgreSQL 9.5 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 9.5 server, type as root: 
    chkconfig rh-postgresql95-postgresql on
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql95/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: 
    service postgresql start
  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: 
    service postgresql stop
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql95-postgresql -- postgresql-setup --initdb
  5. Start the new server as root: 
    service rh-postgresql95-postgresql start
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql95 "psql -f ~/pgdump_file.sql postgres"'
  7. Optionally, you can configure the PostgreSQL 9.5 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 9.5 server, type as root: 
    chkconfig rh-postgresql95-postgresql on
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf configuration file. Otherwise only the postgres user will be allowed to access the database.

5.4.3. Migrating from the PostgreSQL 9.4 Software Collection to the PostgreSQL 9.5 Software Collection

To migrate your data from the rh-postgresql94 Software Collection to the rh-postgresql95 Collection included in Red Hat Software Collections 2.2, 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.4 to PostgreSQL 9.5, 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-postgresql94/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: 
    service rh-postgresql94-postgresql stop
    To verify that the server is not running, type: 
    service rh-postgresql94-postgresql status
  2. Verify that the old directory /var/opt/rh/rh-postgresql94/lib/pgsql/data/ exists: 
    file /var/opt/rh/rh-postgresql94/lib/pgsql/data/
    and back up your data.
  3. Verify that the new data directory /var/opt/rh/rh-postgresql95/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql95/lib/pgsql/data/
    If you are running a fresh installation of PostgreSQL 9.5, 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-postgresql95/lib/pgsql/data{,-scl-backup}
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql95 -- postgresql-setup --upgrade --upgrade-from=rh-postgresql94-postgresql
    Alternatively, you can use the /opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup --upgrade --upgrade-from=rh-postgresql94-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-postgresql95-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    service rh-postgresql95-postgresql start
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql95 ~/analyze_new_cluster.sh'
  6. Optionally, you can configure the PostgreSQL 9.5 server to start automatically at boot time. To disable the old PostgreSQL 9.4 server, type the following command as root: 
    chkconfig rh-postgresql94-postgreqsql off
    To enable the PostgreSQL 9.5 server, type as root: 
    chkconfig rh-postgresql95-postgresql on
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql95/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: 
    service rh-postgresql94-postgresql start
  2. Dump all data in the PostgreSQL database into a script file. As root, type: 
    su - postgres -c 'scl enable rh-postgresql94 "pg_dumpall > ~/pgdump_file.sql"'
  3. Stop the old server by running the following command as root: 
    service rh-postgresql94-postgresql stop
  4. Initialize the data directory for the new server as root: 
    scl enable rh-postgresql95-postgresql -- postgresql-setup --initdb
  5. Start the new server as root: 
    service rh-postgresql95-postgresql start
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql95 "psql -f ~/pgdump_file.sql postgres"'
  7. Optionally, you can configure the PostgreSQL 9.5 server to start automatically at boot time. To disable the old PostgreSQL 9.4 server, type the following command as root: 
    chkconfig rh-postgresql94-postgresql off
    To enable the PostgreSQL 9.5 server, type as root: 
    chkconfig rh-postgresql95-postgresql on
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql95/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.

5.5. Migrating to nginx 1.8

The root directory for the rh-nginx18 Software Collection is located in /opt/rh/rh-nginx18/root/. The error log is stored in /var/opt/rh/rh-nginx18/log/nginx by default, and the init script is called rh-nginx18-nginx.
Configuration files are now stored in the /etc/opt/rh/rh-nginx18/nginx/ directory. Configuration files in nginx 1.8 have the same format as in the previous versions and they are compatible among versions 1.4, 1.6, and 1.8.

Important

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

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.