Chapter 5. Migration

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

5.1. Migrating to MariaDB 10.0

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. In addition to these basic versions, MariaDB 5.5 has been available for Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 as a Software Collection since Red Hat Software Collections 1.0.
The rh-mariadb100 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-mariadb100 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 MariaDB 10.0 only from MariaDB 5.5 or MySQL 5.5. If you need to upgrade from an earlier version, upgrade to MariaDB 5.5 or MySQL 5.5 first. Instructions how to upgrade to MariaDB 5.5 or MySQL 5.5 are available in the Red Hat Software Collections 1.2 Release Notes.

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

MariaDB 10.0 is built on the MariaDB 5.5 series with backported features from MySQL 5.6 and with entirely new features unavailable elsewhere. The rh-mariadb100 Software Collection introduces the following notable changes:
  • The service has been renamed to rh-mariadb100-mariadb 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-mariadb100 Software Collection are the /etc/opt/rh/rh-mariadb100/my.cnf file and in the /etc/opt/rh/rh-mariadb100/my.cnf.d/ directory
  • Variable files including the database files for the rh-mariadb100 Software Collection are located in the /var/opt/rh/rh-mariadb100/lib/ directory
  • The log file for the MariaDB daemon is /var/opt/rh/rh-mariadb100/log/mariadb/mariadb.log
  • The pid file for the daemon is /var/run/rh-mariadb100-mariadb/mariadb.pid
Note that the rh-mariadb100 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.
For detailed changes, refer to the MariaDB documentation.
If you are going to upgrade from MySQL, refer to the articles about compatibility and features differences.

5.1.2. Upgrading to the rh-mariadb100 Software Collection

Important

Prior to upgrading, back-up all your data, including any MariaDB or 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 MariaDB.
    • If you are upgrading from MariaDB 5.5 from base Red Hat Enterprise Linux 7: 
      ~]# service mariadb start
Starting mariadb:                                          [  OK  ]
~]# mysqldump --all-databases --routines --events > dump.sql
~]# service mariadb stop
Stopping mariadb:                                          [  OK  ]
    • If you are upgrading from the mariadb55 Software Collection in Red Hat Enterprise Linux 6: 
      ~]# service mariadb55-mysqld start
Starting mariadb55-mysqld:                                 [  OK  ]
~]# scl enable mariadb55 -- mysqldump --all-databases --routines --events > dump.sql
~]# service mariadb55-mysqld stop
Stopping mariadb55-mysqld:                                 [  OK  ]
    • For upgrading from the mariadb55 Software Collection in Red Hat Enterprise Linux 7, use mariadb55-mariadb as the service name.
    • For upgrading from the mysql55 Software Collection, use mysql55-mysqld as the service name.
  2. Import the dumped database into the rh-mariadb100 Software Collection: 
    ~]# service rh-mariadb100-mariadb start
Starting rh-mariadb100-mariadb:                            [  OK  ]
~]# scl enable rh-mariadb100 'mysql' < dump.sql
~]# scl enable rh-mariadb100 '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 MariaDB 5.5

If you are upgrading from MariaDB 5.5 from base Red Hat Enterprise Linux 7, perform the upgrade as shown in the following example: 
~]# service mariadb stop
Stopping mariadb:                                          [  OK  ]
~]# service rh-mariadb100-mariadb stop
Stopping rh-mariadb100-mariadb:                            [  OK  ]
~]# rm -rf /var/opt/rh/rh-mariadb100/lib/mysql/
~]# cp -r /var/lib/mysql/ /var/opt/rh/rh-mariadb100/lib/
~]# chown -R mysql:mysql /var/opt/rh/rh-mariadb100/lib/mysql/
~]# restorecon -R /var/opt/rh/rh-mariadb100/lib/mysql/
~]# service rh-mariadb100-mariadb start
Starting rh-mariadb100-mariadb:                            [  OK  ]
~]# scl enable rh-mariadb100 '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 the mysql55 Software Collection, use the /opt/rh/mysql55/root/var/lib/mysql/ as a source when copying the data.
For further details, refer to the articles about upgrading from MariaDB 5.5 or upgrading from MySQL 5.5.

5.2. Migrating to MongoDB 2.6

MongoDB 2.4 has been available since Red Hat Software Collections 1.1 as the mongodb24 Software Collection. Red Hat Software Collections 2.0 is shipped with MongoDB 2.6 provided by the rh-mongodb26 Software Collection.

5.2.1. Notable Differences Between MongoDB 2.4 and MongoDB 2.6

General Changes

The rh-mongodb26 Software Collection introduces several general changes listed below.
  • Service files have been renamed:
    • The /etc/rc.d/init.d/mongodb24-mongodb service file for the MongoDB daemon has been renamed to /etc/rc.d/init.d/rh-mongodb26-mongod
    • The /etc/rc.d/init.d/mongodb24-mongodb-shard service file for the MongoDB sharding server has been renamed to /etc/rc.d/init.d/rh-mongodb26-mongos
  • Configuration and system configuration files have been renamed:
    • The mongod daemon uses the /etc/opt/rh/rh-mongodb26/mongod.conf and /etc/opt/rh/rh-mongodb26/sysconfig/mongod configuration files
    • The mongos sharding server uses the /etc/opt/rh/rh-mongodb26/mongos.conf and /etc/opt/rh/rh-mongodb26/sysconfig/mongos configuration files
  • The log files have been relocated:
    • The mongod daemon now writes log to the /var/opt/rh/rh-mongodb26/log/mongodb/mongod.log file
    • The mongos sharding server writes log to the /var/opt/rh/rh-mongodb26/log/mongodb/mongos.log file
  • The default mongos port number has been changed from 27019 to 27017
  • The rh-mongodb26-mongodb-test package, which contains the MongoDB test suite, has been added. For more information about usage, install this package and read the /opt/rh/rh-mongodb26/root/usr/share/mongodb-test/README file.
  • The rh-mongodb26 Software Collection supports neither mounting over NFS nor dynamical registering using the scl register command.

Compatibility Changes

MongoDB 2.6 includes various minor changes that can affect compatibility with previous versions of MongoDB. For a brief list of compatibility changes in MongoDB 2.6, refer to the Knowledgebase article on the Red Hat Customer Portal. For details on compatibility changes, see the MongoDB documentation.

Authentication Changes

MongoDB 2.6 authorization model introduces changes in the way MongoDB stores and manages user privilege information:
  • MongoDB 2.6 requires at least one user in the admin database with the userAdminAnyDatabase role. Make sure that this user exists before you upgrade.
  • You will not be able to create or modify users or create user-defined roles in MongoDB versions that use previous authorization models.
For details on authentication changes, see the MongoDB documentation.

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

Note that once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier than MongoDB 2.4. If you created text or 2dsphere indexes while running MongoDB 2.6, you can downgrade only to MongoDB 2.4.10 or later versions.

Important

Before migrating from the mongodb24 to the rh-mongodb26 Software Collection, back up all your data, including any MongoDB databases, which are by default stored in the /opt/rh/mongodb24/root/var/lib/mongodb/ directory.
To upgrade to the rh-mongodb26 Software Collection, perform the following steps as root.
  1. Install the MongoDB server from the rh-mongodb26 Software Collection: 
    yum install rh-mongodb26
  2. Stop the mongodb24 server in Red Hat Enterprise Linux 6: 
    service mongodb24-mongodb stop
    Use the systemctl stop mongodb24-mongodb.service command instead if you are using Red Hat Enterprise Linux 7.
  3. Copy your data into the new location: 
    cp -a /opt/rh/mongodb24/root/var/lib/mongodb/* /var/opt/rh/rh-mongodb26/lib/mongodb
  4. Change the dbpath variable in the /opt/rh/mongodb24/root/etc/mongodb.conf file to /var/opt/rh/rh-mongodb26/lib/mongodb/.
  5. Start the mongodb24 server in Red Hat Enterprise Linux 6: 
    service mongodb24-mongodb start
    Use the systemctl start mongodb24-mongodb.service command if instead you are using Red Hat Enterprise Linux 7.
  6. Install the mongo shell from the rh-mongodb26 Software Collection: 
    yum install rh-mongodb26-mongodb
  7. Connect the mongo shell from the rh-mongodb26 Software Collection to your mongodb24 server (for example, running on localhost, port 27017; you do not need root privileges for this step): 
    scl enable rh-mongodb26 'mongo --host localhost --port 27017 admin'
  8. In the mongo shell, run the db.upgradeCheckAllDBs() function to check your data set for compatibility: 
    db.upgradeCheckAllDBs()
    See the MongoDB documentation for more information about the db.upgradeCheckAllDBs() function.
  9. Resolve all issues identified by db.upgradeCheckAllDBs() and compatibility issues mentioned above that affect your application.
  10. Stop the mongodb24 server in Red Hat Enterprise Linux 6: 
    service mongodb24-mongodb stop
    Use the systemctl stop mongodb24-mongodb.service command instead if you are using Red Hat Enterprise Linux 7.
  11. Make the mongodb24 Software Collection runnable after the upgrade by changing the dbpath variable back to the previous value (/opt/rh/mongodb24/root/var/lib/mongodb/ by default) in the /opt/rh/mongodb24/root/etc/mongodb.conf file.
  12. Configure the rh-mongodb26-mongod daemon in the /etc/opt/rh/rh-mongodb26/mongod.conf configuration file.
  13. Start the MongoDB server from the rh-mongodb26 Collection in Red Hat Enterprise Linux 6: 
    service rh-mongodb26-mongod start
    Use the systemctl start rh-mongodb26-mongod.service instead if you are using Red Hat Enterprise Linux 7.
  14. Upgrade the authorization model as described in the MongoDB documentation. Note that it is recommended to run your MongoDB deployment for a day or two before you upgrade the user authorization model because downgrades are more difficult after the user authorization model has been upgraded. Before you upgrade the authorization model, you will not be able to create or modify users or to use user-defined roles.
For detailed information about upgrading, refer to the MongoDB documentation, or particularly about upgrading a Replica Set or a Sharded Cluster.

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.3. 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.4. 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/
~]# 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.4

Red Hat Software Collections 2.0 is distributed with PostgreSQL 9.4, which can be safely installed on the same machine in parallel with PostgreSQL 8.4 from Red Hat Enterprise Linux 6 or PostgreSQL 9.2 from Red Hat Enterprise Linux 7 or Red Hat Software Collections 1. 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.2 and PostgreSQL 9.4

The most notable changes between PostgreSQL 9.2 and PostgreSQL 9.4 are the following:
  • PostgreSQL 9.4 no longer includes native support for Kerberos authentication (for example, using the --with-krb5 option). As consequence, the krb_srvname option is not available anymore. The supported way to use Kerberos authentication is with Generic Security Services API (GSSAPI).
  • Since PostgreSQL 9.4, the replication_timeout configuration option has been split into the wal_receiver_timeout and wal_sender_timeout options.
  • The scl register rh-postgresql94 command is unsupported and the rh-postgresql94 Software Collection is not supported to run over NFS.
The following table provides an overview of different paths in a Red Hat Enterprise Linux system version of PostgreSQL (postgresql) and in the postgresql92 and rh-postgresql94 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-postgresql94
Executables/usr/bin//opt/rh/postgresql92/root/usr/bin//opt/rh/rh-postgresql94/root/usr/bin/
Libraries/usr/lib64//opt/rh/postgresql92/root/usr/lib64//opt/rh/rh-postgresql94/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/
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/
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/
Sourcenot installednot installednot installed
Data/var/lib/pgsql/data//opt/rh/postgresql92/root/var/lib/pgsql/data//var/opt/rh/rh-postgresql94/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/
Templates/usr/share/pgsql//opt/rh/postgresql92/root/usr/share/pgsql//opt/rh/rh-postgresql94/root/usr/share/pgsql/
Procedural Languages/usr/lib64/pgsql//opt/rh/postgresql92/root/usr/lib64/pgsql//opt/rh/rh-postgresql94/root/usr/lib64/pgsql/
Development Headers/usr/include/pgsql//opt/rh/postgresql92/root/usr/include/pgsql//opt/rh/rh-postgresql94/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/
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)
For detailed changes, see the PostgreSQL 9.3 Release Notes and the PostgreSQL 9.4 Release Notes. For changes between PostgreSQL 8.4 and PostgreSQL 9.2, refer to the Red Hat Software Collections 1.2 Release Notes.

5.4.2. Migrating from a Red Hat Enterprise Linux System Version of PostgreSQL to the PostgreSQL 9.4 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-postgresql94 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.4, 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-postgresql94/lib/pgsql/data/ does not exist: 
    file /var/opt/rh/rh-postgresql94/lib/pgsql/data/
    If you are running a fresh installation of PostgreSQL 9.4, 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-postgresql94/lib/pgsql/data{,-scl-backup}
  4. Upgrade the database data for the new server by running the following command as root: 
    scl enable rh-postgresql94 -- postgresql-setup --upgrade
    Alternatively, you can use the /opt/rh/rh-postgresql94/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-postgresql94-postgresql.log log file to find out if any problems occurred during the upgrade.
  5. Start the new server as root: 
    service rh-postgresql94-postgresql start
    It is also advised that you run the analyze_new_cluster.sh script as follows: 
    su - postgres -c 'scl enable rh-postgresql94 ~/analyze_new_cluster.sh'
  6. Optionally, you can configure the PostgreSQL 9.4 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.4 server, type as root: 
    chkconfig rh-postgresql94-postgresql on
  7. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql94/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-postgresql94-postgresql -- postgresql-setup --initdb
  5. Start the new server as root: 
    service rh-postgresql94-postgresql start
  6. Import data from the previously created SQL file: 
    su - postgres -c 'scl enable rh-postgresql94 "psql -f ~/pgdump_file.sql postgres"'
  7. Optionally, you can configure the PostgreSQL 9.4 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.4 server, type as root: 
    chkconfig rh-postgresql94-postgresql on
  8. If your configuration differs from the default one, make sure to update configuration files, especially the /var/opt/rh/rh-postgresql94/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.2 Software Collection to the PostgreSQL 9.4 Software Collection

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

5.5. Migrating to nginx 1.6

The nginx16 Software Collection uses a new prefix in accordance with the name of the collection and a different path to the root directory, which is now located in /opt/rh/nginx16/root/. The error log is now stored in /var/log/nginx16/error.log by default, and the initscript is called nginx16-nginx.
Configuration files in nginx 1.6 have the same format as in the previous version and they are compatible between version 1.4 and 1.6.

Important

Before upgrading from nginx 1.4 to nginx 1.6, back up all your data, including web pages and configuration files located in the /opt/rh/nginx14/root/ tree.
If you have made any specific changes, such as changing configuration files or setting up web applications, in the /opt/rh/nginx14/root/ tree, replicate those changes in the new /opt/rh/nginx16/root/ directory, too.
For the official nginx documentation, refer to http://nginx.org/en/docs/.