To resolve certain STA application issues, you may need to restore the database to the last incremental backup.
To restore the database, you will load the most recent full database dump and then apply the incremental backups created since the dump. Depending on the size of your database and the number of incremental backups, this may be a lengthy process.
To restore the STA database, perform these tasks in order:
Depending on which incremental backups need to be restored, use the following:
For additional information about restoring a MySQL database, see the MySQL documentation at: http://docs.oracle.com/en/database/
You may need to install and configure a replacement STA server if the STA server experienced a catastrophic failure.
See the STA Installation and Configuration Guide to perform the following:
Install Linux on the replacement server. The replacement server must run the same version of Linux and STA as the original STA server.
Install STA on the replacement server.
Add the replacement server as an SNMP trap recipient on all libraries monitored by STA.
Copy the files for the most recent backup from the backup server to the STA server. This includes the most recent full database dump file and all incremental backups created since then.
On the backup server, copy the backup files to the STA server.
Open a terminal session on the backup server, and log in as the Oracle user. If you are only doing local backups, this is the STA server.
Copy the complete set of one day's backup files to the STA server. Oracle recommends copying the files to the /tmp directory. For example:
$ scp *20200123* staserver.mycompany.com:/tmp/.
where:
*20200123* indicates to copy all files with this date stamp.
staserver.mycompany.com is the name of the STA server.
/tmp is the target directory.
On the STA server, verify and decompress the files.
Open a terminal session on the STA server, and log in as the Oracle user.
Change to the target directory and verify the compressed files were successfully copied.
$ cd /tmp $ ls -l *20200123*
Decompressed files.
$ unzip *20200123*.gz $ ls -l *20200123*
To ensure a clean restore, remove any existing directories after first saving a copy, and then completely replace the directories.
The zip files created by the backup have the full directory paths to allow you to restore or overwrite existing files.
On the STA server, open a terminal session. Log in as the Oracle user.
Stop all STA processes:
$ STA stop all
Restart the MySQL server:
$ STA start mysql
As a safeguard, save the existing STA services and database server configuration directories to zip files. For example:
$ cd /Oracle/StorageTek_Tape_Analytics/common $ zip –vr conf.orig.zip conf $ cd /Oracle/Middleware/user_projects/domains/TBI/config $ zip –vr fmwconfig.orig.zip fmwconfig
Delete the existing configuration directories.
$ rm –rf /Oracle/StorageTek_Tape_Analytics/common/conf $ rm -rf /Oracle/Middleware/user_projects/domains/TBI/config/fmwconfig
Unzip the STA services and database server configuration directories from the backup. For example:
$ cd /tmp $ unzip -X -d / 20160123_170250.conf.zip ... $ $ unzip -X -d / 20160123_170250.fmwconfig.zip $
where:
-X indicates to restore user and group ownership.
-d / indicates to restore the files to the root directory (/). Since the backup zip files were created using the full directory paths for each file, this restores the files to their original locations.
Verify the configuration directories have been restored. For example:
$ ls -l /Oracle/StorageTek_Tape_Analytics/common $ ls -l /Oracle/Middleware/user_projects/domains/TBI/config
Reload the STA database from the last full database dump.
On the STA server, open a terminal session. Log in as the Oracle user.
Ensure there is no residual STA database left on the server. The STA database has the name stadb. For example:
$ mysql –u root –p –e 'drop database stadb;'
Password:
where:
-u root indicates to execute the command as the MySQL root user
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'drop database stadb'—Removes the database named stadb, which is the STA database.
Load the latest full database backup. For example:
$ mysql –u root –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
where:
-u root specifies the MySQL root username.
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'source 20130723_133755.stafullbackup.sql;'— Executes the specified database dump file; the dump file creates the schema and installs all the data.
Continue to either of the following:
Perform a Partial Restore From a Range of Incremental Backups. Use this if you suspect a database operation may have corrupted the database and you only want to restore operations up to, but not including, that one.
Restore all incremental backups (binary logs) since the last full backup. Make sure you restor the incremental backups in the proper order.
Open a terminal session on the STA server, and log in as the Oracle user.
Caution:
Do not use multiple connections to the MySQL server.Following is an example of how not to process the binary logs, as this method may create multiple connections to the server.
$ mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!! $ mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
Run the binary logs in chronological order, from oldest to newest. If you have more than one binary log to execute, you must process them all using a single connection to the MySQL server.
Use one of the following methods:
The safest method is to use a single connection to the server and a single MySQL process to execute the contents of all the binary logs. For example:
$ mysqlbinlog 20130723_133755.sta-binlog.000021 \ > 20130723_133755.sta-binlog.000022 \ > 20130723_133755.sta-binlog.000023 \ > 20130723_133755.sta-binlog.000024 |mysql –u root –p Password:
Another safe method is to concatenate all applicable binary logs to a single file and then process that file. For example:
$ mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql $ mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql $ mysql –u root –p –e 'source /tmp/recoversta.sql' Password:
Partially restore the STA database from a range of incremental backups. This restores the database from the last full dump and then applies just the incremental backups that fall within the start and end points specified.
On the STA server, open a terminal session. Log in as the Oracle user.
Stop all STA processes:
$ STA stop all
Restart the MySQL server:
$ STA start mysql
Extract the valid operations from the binary logs. For example:
$ mysqlbinlog ––start–position=176 ––stop–position=6817916 /var/log/tbi/db/stadb–bin.000007 > ./recover.sql
Password:
where:
--start-position is the first log entry you want to extract.
--stop-position is the last log entry you want to extract. In this example, entries 176 to 6817916 are extracted.
/var/log/tbi/db/stadb-bin.00007 is the binary log file you want to extract from.
./recover.sql is the file you want to write the entries to.
Apply the selected operations to the database. For example:
$ mysql –u root –p –e 'source ./recover.sql'
Password:
where:
-u root specifies the STA database root username.
-p indicates to prompt for the user password.
-e indicates to execute the following MySQL statement and then quit the mysql command. The statement must be enclosed in quotes.
'source ./recover.sql'—Applies the entries in the specified file to the database.
Restart STA and all associated processes. See Restart the STA Application.
Incremental backups (binary logs) are labeled with unique sequential numbers. Therefore, if you identify a corrupt entry you can restore all logs before the erroneous entry.
Log positions are labeled in the binary log as log_pos followed by a unique number. For example, after examining the contents of a binary log, you discover that an erroneous operation resulted in dropping several tables immediately following log entry #6817916. Therefore, you want to restore the database only up to the last good entry (#6817916), excluding the erroneous operation and all that follow.
You would want to restore the database from the full dump done the day before, and then replay the most recent binary log from its initial log entry number "176" through entry number "6817916".