Upgrade Installation of the Postgres 8.4.8 Scenarios related to failures in restore/backup operations during upgrade installation of the Postgres 8.4.
Table of Contents Failure scenarios related to the database backup and restore operation in upgrade installation of postgres 8.4.8 .............................................................................................................................................. 3 Failures during the database backup operation .........................................................................3 Failures during the database backup due to missing binaries and data availability......................
Failure scenarios related to the database backup and restore operation in upgrade installation of postgres 8.4.8 Failures during the database backup operation The upgrade installation of the products such as SFM supporting postgres 8.4.8 may sometimes involve situations where the products are upgraded from the version containing postgres 7.4.2 to the corresponding higher version having postgres 8.4.8 version.
database (7.4.2) will be saved in the .tar format. The installation is expected to continue with the remaining steps once the NOTE and the user data backup is taken successfully. The location of the database backup is given below: /pgsql..tar See the Annexure for the DB_DATA_PATH details. In order to have the data recovery in place, the database backup should be performed manually by using the following steps: 1. Port the database backup file (/pgsql.
For PA /usr/bin/cp -f /opt/sfmdb/pgsql/share/pg_hba.conf.sample /var/opt/sfmdb/pgsql/pg_hba.conf /usr/bin/su - sfmdb -c ‘/opt/sfmdb/pgsql/bin/pg_ctl reload -D /var/opt/sfmdb/pgsql’ >>/tmp/restore.txt 7. Use the following command to take the database backup: /pg_dumpall -c -U sfmdb> /db_backup.sql 8. Move the database back to the authenticated mode and reload the db. For IA /usr/bin/cp -f /opt/psb/db/pgsql/share/pg_hba.conf.sample.md5 /var/opt/psb/db/pgsql/pg_hba.
The database backup will now be available in the file db_backup.sql. This database backup file can be used later (after completing installation) for restoring the database contents. NOTE: Refer to the Annexure to find the absolute locations of the database binaries and data contents.
Failure during the database backup due to unknown scenarios Sometimes the steps involved in the database backup may fail due to some unknown scenarios like error connecting to postmaster etc. Such a scenario leading to the unsuccessful automatic backup process is reported to the end user by using the following ERROR message.
For IA /usr/bin/cp -f /opt/psb/db/pgsql/share/pg_hba.conf.sample.md5 /var/opt/psb/db/pgsql/pg_hba.conf /usr/bin/su - sfmdb -c '/opt/psb/db/pgsql/bin/pg_ctl reload -D /var/opt/psb/db/pgsql' >>/tmp/restore.txt For PA /usr/bin/cp -f /opt/sfmdb/pgsql/share/pg_hba.conf.sample.md5 /var/opt/sfmdb/pgsql/pg_hba.conf /usr/bin/su - sfmdb -c ‘/opt/sfmdb/pgsql/bin/pg_ctl reload -D /var/opt/sfmdb/pgsql’ >>/tmp/restore.txt 5.
Failures during the database restore operation As like the database backup operation, sometimes the database restore operation may also fail due to some reasons like connection problems etc. The successful upgrade installation with a failed restore operation may result in unsuccessful migration of any user specific data from the previous versions of postgres. However, the case of restore failure does not mean the loss of end-user data.
/usr/bin/cp -f /opt/psb/db/pgsql/share/pg_hba.conf.sample /var/opt/psb/db/pgsql/pg_hba.conf /usr/bin/su - sfmdb -c '/opt/psb/db/pgsql/bin/pg_ctl reload -D /var/opt/psb/db/pgsql' >>/tmp/restore.txt For PA /usr/bin/cp -f /opt/sfmdb/pgsql/share/pg_hba.conf.sample /var/opt/sfmdb/pgsql/pg_hba.conf /usr/bin/su - sfmdb -c '/opt/sfmdb/pgsql/bin/pg_ctl reload -D /var/opt/sfmdb/pgsql' >>/tmp/restore.txt Use the following command to restore the data. /psql –p10864 -Usfmdb -f/db_backup.sql.
6. Reconfigure the product SFM(for PA) and PSB(for IA) to complete the database restoration.
DRD Session- Perform backup on booted system and sync to the clone for IA Assumption The booted disk and cloned disk are always kept in sync with respect to data. If they are not in sync, use ‘drd sync’ command. Steps to be followed 1. Create metafile at /var/opt/psb/db/restore_pid_data # echo “123” > /var/opt/psb/db/restore_pid_data # ll /var/opt/psb/db/restore_pid_data -rw-rw-rw- 1 root 2.
5. Upon data validation, remove the files /var/opt/psb/db/db_backup.sql.123 and /var/opt/psb/db/restore_pid_data NOTE: When Clone disk is booted, products would get configured and backed up data shall be restored. DRD Session- Perform backup on booted system and sync to the clone for PA Assumption Booted disk and cloned disk are always kept in sync with respect to data. If they are not in sync, use ‘drd sync’ command. Steps to be followed 1.
/var/opt/sfmdb/db_backup.sql.123 /var/opt/sfmdb/restore_pid_data … # /opt/drd/bin/drd sync 4. Perform upgrade of diagnostic products and boot the clone disk. 5. Upon data validation, remove the files /var/opt/sfmdb/db_backup.sql.123 and /var/opt/sfmdb/restore_pid_data NOTE: When Clone disk is booted, products would get configured and backed up data shall be restored.
Annexure Abbreviations 1. DB_DATA_PATH 2. DB_PATH 3. INSTALL_LOG 4. Platform Absolute path/Description Type PA IA PA IA PA IA /var/opt/sfmdb/ /var/opt/psb/db/ /opt/sfmdb/pgsql/bin /opt/psb/db/pgsql/bin /var/opt/sfm/log/install.log /var/opt/psb/log/install.log Represent the session id of the current swinstall operation.