This chapter details the administration of various STA services. To configure these services for the first time, see the STA Installation and Configuration Guide.
This chapter includes the following sections:
The STA Services daemon, staservd, is a continuously running Linux service that manages and runs the STA Backup and STA Resource Monitor services. Both the STA Backup and the STA Resource Monitor services run as separate execution threads within the STA Services daemon.
The STA Services daemon starts when the STA server is booted (with the STA start all command), and terminates when the server is shut down. You can also start, stop, and check the status of the STA Services daemon with the following commands:
To start the STA Services daemon:
# STA start staservd
Starting staservd Service...
staservd service was successfully started
To stop the STA Services daemon:
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
To check the status of the STA Services daemon:
# STA status staservd
staservd service is running
For more information about the STA command, see Chapter 1, "Server Administration."
Note:
After installation of STA, the STA Services daemon starts the STA Backup and STA Resource Monitor services, but they are not activated until configured. To configure these services, see the STA Installation and Configuration Guide.The STA Backup Service is one of several services running within the STA Services daemon. It performs an automatic full backup of the STA database and key configuration directories, writing these files to a specified location on the STA server or in compressed form to a remote server. Oracle recommends that you configure a remote backup server.
Before proceeding, verify the STA Services Daemon is running. See "STA Services Daemon".
The STA Backup Service is configured using its administration utility, staservadm, located in /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. To configure the STA Backup service, see the STA Installation and Configuration Guide.
Once configured, the STA Backup service performs the following process once every 24 hours:
Initiates a high-speed dump (also referred to as a hot backup) of the following file types:
MySQL database dump file
MySQL binary log files
STA Services daemon and STA WebLogic configuration files
STA Services daemon and STA Backup service administration logs
Transfers the dump file to the designated backup host
Deletes the previous day's full dump files from the STA server
Writes a copy of the current day's dump files to the /sta_db_backup/local directory on the STA server.
Display the status of the current preference settings.
# ./staservadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Backup Service Settings: Configured [yes] File Transfer –S [SCP] Full Backup –T [11:00] Sleep Interval –i [350 sec] Backup Hostname –s [stabaksvr] Backup Username –u [stabck] Backup Password –p [*******] Backup Directory –d [/home/stabck/STAbackups] Database Username –U [stadba] Database Password –P [*********]
If the Configured field is [no], the Backup Service is running in an idle mode and is not performing any backups. You must supply the proper configuration settings; see the STA Installation and Configuration Guide for details.
Clear the current preference settings.
# ./staservadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Backup Service Settings: Configured [no] File Transfer –S [SCP] Full Backup –T [00:00] Sleep Interval –i [300 sec] Backup Hostname –s [] Backup Username –u [] Backup Password –p [] Backup Directory –d [] Database Username –U [] Database Password –P []
The backup service is no longer configured and returns to the idle state. You can now provide new settings; see the STA Installation and Configuration Guide for details.
To verify that files have been sent successfully to the target server:
Check the logs on the STA server.
Log on to the target backup server and list the contents of the backup directory.
Log on to the STA server as the system root user.
Change to the STA database backup log directory.
# cd /sta_logs/db/backups
Search the staservd.log.0 file for the following string: "INFO: done. Database dump completed." This file registers the activities of the Backup Services configuration utility.
# grep "INFO: done. Database dump completed" staservd.log.0
INFO: done. Database dump completed, file located at /dbbackup/local/20130721_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130722_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130723_133755.stafullbackup.sql INFO: done. Database dump completed, file located at /dbbackup/local/20130724_133755.stafullbackup.sql
Log on to the target backup server.
List the files in the database backups directory.
In this example, the directory /backups/tbivb01 was previously set up to receive the backup files from the STA server "tbivb01".
# ls –1 /backups/tbivb01
0.stadb-bin.000023.gz 0.stadb-bin.000024.gz 0.stadb-bin.000026.gz 0.stadb-bin.000027.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000025.gz 20130723_133755.stadb-bin.000026.gz 20130723_133755.stafullbackup.sql.gz
Verify that a copy of the most recent backup files has been saved locally on the STA server by listing the files in the /sta_db_backup/local directory. For example:
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
The listed files have the name format YYYYMMDD_HHMMSS.filename.zip.
The STA Resource Monitor service monitors and reports on STA server resources, including database tablespace and disk volume space, logging volume disk space, and physical memory usage.
You may set usage high watermarks (HWM) for each resource. A high watermark is a threshold at which an alert will be raised. When the threshold is reached or exceeded, an alert is recorded in the standard daily resource report and optionally emailed to one or more designated recipients.
For example, if you set the database tablespace HWM to 60%, when the STA Resource Monitor detects that the STA application has used 60 percent or more of the maximum allowable database tablespace, it turns on the tablespace alert and sends an email to the designated recipients. Additionally, if nag mode is turned on, the Resource Monitor continues to send an alert email each time it scans the system.
The STA Resource Monitor service is configured using its administration utility, staresmonadm, located in /Oracle_storage_home/StorageTek_Tape_Analytics/common/bin. To configure the STA Resource Monitor service, see the STA Installation and Configuration Guide.
Enter the following command to query the current state of the preference settings:
# ./staresmonadm –Q
If the Configured field says "no," then the Resource Monitor Service is running in an "idle" mode neither monitoring resources nor sending reports. You will need to configure the server; see the STA Installation and Configuration Guide for details.
Example output of a configured STA Resource Monitor Service:
# ./staresmonadm –Q
Contacting daemon...connected. Querying Preferences. Current STA Resource Monitor Service Settings: Configured [yes] Send Reports –T [13:00] Sleep Interval –i [600 sec] Alert Nagging –n [on] DB Username –U [sta_dba] DB Password –P [*********] DB Tablespace hwm –t [65%] DB Backup hwm (/dbbackup) –b [65%] DB Data hwm (/dbdata) –d [65%] Log Volume hwm (/var/log/tbi) –l [65%] Root Volume hwm (/) –z [70%] Tmp Volume hwm (/tmp) –x [80%] System Memory hwm –m [75%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [john.doe@company.com] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
Enter the following command to clear the current preference settings:
# ./staresmonadm –C
The Resource Monitor service is no longer configured and returns to the idle state. You can now provide new settings; see the STA Installation and Configuration Guide for details. For example:
# ./staresmonadm –C
Contacting daemon...connected. Clearing Preferences. Done. Current STA Resource Monitor Service Settings: Configured [no] Send Reports –T [00:00] Sleep Interval –i [300 sec] Alert Nagging –n [off] DB Username –U [] DB Password –P [] DB Tablespace hwm –t [–1%] DB Backup hwm (/dbbackup) –b [–1%] DB Data hwm (/dbdata) –d [–1%] Log Volume hwm (/var/log/tbi) –l [–1%] Root Volume hwm (/) –z [–1%] Tmp Volume hwm (/tmp) –x [–1%] System Memory hwm –m [–1%] Email 'From:' –f [StaResMon@localhost] Email 'To:' –r [] Email 'Subject:' –s [STA Resource Monitor Report] Output File –o [/var/log/tbi/db/staresmon.csv]
Resource Monitor reports are configured using the STA Resource Monitor service administration utility, staresmonadm. To configure the STA Resource Monitor service, see the STA Installation and Configuration Guide.
The Resource Monitor can produce two different reports:
A Resource Monitor Standard Report is sent once a day at approximately the time specified by the staresmonadm –T option. If you do not set a time, the report is sent at the first scan after midnight. The report is sent to the email recipients you specified when you configured this service.
The report provides data for the following server resources. If any of these resources exceeds a high watermark threshold, an alert appears in the report.
Database tablespace and volume
Logging, backup, and root volume
Temporary directory
System memory usage
Note:
Reported values rely on mount points. If multiple monitored items share the same mount point, the reported values for these items will be identical.Example 2-1 Example Standard Report (truncated)
STA RESOURCE MONITOR STANDARD REPORT System: tbivb03 Scanned: 2013-10-24 11:30:14 Database Tablespace HWM : 60.00% Used : <0.1% MB Used : 13 MB Free : 75763 MB Total : 75776 Location : /dbdata/mysql Database Volume HWM : 60.00% Used : 6.80% MB Used : 6855 MB Free : 93939 MB Total : 100794 Directory : /dbdata/mysql ...
A Resource Depletion Alert Report is sent after every scan if the staresmonadm alert nag mode (–n) option is set to "on". If nag mode is off, alerts are shown only in the Standard Report.
The interval between each scan is determined by the Sleep Interval (–i) attribute, and the report is sent to the email recipients you specified when you configured this service. Recommendations are provided within the report to help resolve the noted issues.
Example 2-2 Example Resource Depletion Alert Report
STA RESOURCE DEPLETION REPORT
System: server01
Scanned: 2013-10-24 11:34:47
************************************************************
* A L E R T S *
************************************************************
==================================================
ALERT – Low System Physical Memory
==================================================
Physical memory usage has exceeded threshold value!
HWM [1.00%]
Used [48.24%] (!)
MB Used [7757]
MB Free [8324]
MB Total [16080]
Hostname [server01]
Recommendations:
1) Shutdown unneeded processes.
2) Under Linux, try releasing unused caches using commands:
# free –m
# sync
# /sbin/sysctl –q vm.drop_caches=3
# free –m
3) Install additional memory.
The STA Services are comprised of executable scripts, Java jar files containing server and client applications, configuration files, dump file, logging files, and a cumulative data file. This section describes their purposes and locations.
The STA Services daemon startup and shutdown script, staservd, and system run-level symbolic links are located in the following directories. This script and its associated symbolic links are created by the STA installer.
/etc/init.d/staservd—Main startup and shutdown script
/etc/rc0.d/K04staservd—Symbolic link for system shutdown
/etc/rc1.d/K04staservd—Symbolic link for system shutdown
/etc/rc2.d/S96staservd—Symbolic link for system startup
/etc/rc3.d/S96staservd—Symbolic link for system startup
/etc/rc4.d/S96staservd—Symbolic link for system startup
/etc/rc5.d/S96staservd—Symbolic link for system startup
/etc/rc6.d/K04staservd—Symbolic link for system shutdown
The STA Backup Service administration utility, staservadm, is a Perl script that calls a Java client application named ServerAdm that is contained in the oracle.tbi.serveradm.jar file. For more information, see "STA Backup Service".
The STA Resources Monitor administration utility, staresmonadm, is a Perl script that calls a Java client application named StaResMonAdm that is contained in the oracle.tbi.resmonadm.jar file. StaResMonAdm is an RMI client that communicates with the STA Services daemon to set and reset runtime preferences. For more information, see "STA Resource Monitor Service".
Table 2-1 lists the executable programs and their locations.
Table 2-1 Executable Program Locations
| Program | Location |
|---|---|
|
STA Services program jar file |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
STA Backup Services Administration Utility Java application jar file |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
STA Backup Service Administration Utility user script file, staservadm |
$STAHOME/common/bin/staservadm |
|
STA ResMon Administration Utility Java application jar file |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
STA ResMon Administration Utility Java user script file, staresmonadm |
$STAHOME/common/bin/staresmonadm |
Where:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
The STA database backup includes the following types of files:
These log the activities of the STA Services Daemon Server, STAServer, and its Backup services configuration utility, ServerAdm. Admin logs are collections of up to 10 log files, each up to 1.0 MB in size. The log file names are of the format *.log.N, where N is the number of the log (staservd.log.0, staservadm.log.0, staservd.log.1, and so forth).
The logs are rotated such that log file #1 will be reused when staservd.log.9 has been filled up. The active log file is always #0 (staservd.log.0). When log #0 fills up, it is renamed to log #1 and a new log #0 is started. By default the STAServer and ServerAdm logs are located in the following directory:
/STA_logs/db/backups
The default location for STA_logs is /var/log/tbi.
The log location and internal format (either simple ASCII text or XML markup) are controlled by the logging properties files staservd.log.props and staservadm.log.props, located at:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
Where:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
The MySQL database dump file is a snapshot-in-time of the database schema and data contents. STA Backup service performs these actions:
Initiates a high-speed dump (sometimes called a hot backup) once every 24 hours of the file types discussed in this section.
Transfers the latest dump file to the designated backup host.
Deletes the previous day's full dump files from the local backup directory.
Writes a copy of the current days' dump file to the local backup directory.
The STA Backup Service by default will place its local dump files and incremental binlog files into the /sta_db_backup/local directory with format YYYYMMDD_HHMMSS.filename.sql.
The term incremental dumps refers to the MySQL binary logs (binlogs) that record all transactions resulting in a change to a database. The STA Backup Service treats binlogs as incremental backups following the main database dump.
STA incremental dumps are comprised of all the binary logs that are produced since the last full dump. By replaying the binlogs, you can restore a database to its state up the last transaction recorded in the log. A restore consists of loading the latest dump file, and then replaying, in order, all the MySQL binlogs that were generated following the latest database dump.
Backing up the binlogs consists of making a list of all the binlogs created since the most recent full dump and then transmitting each of those logs (except the current one because it is still open) to the backup server.
The backup binary log naming format is YYYYMMDD_HHMMSS.stadb–bin.log_sequence_number.
The MySQL binary log location is defined in the MySQL settings file /etc/my.cnf. That is currently set to:
/STA_logs/db
Local copies of the backup binlog files are located at:
/sta_db_backup/local
All but the most recent binlog successfully transferred to the backup server are purged using the MySQL command PURGE BINARY LOGS BEFORE NOW(). The current binlog and the current day's full backup file thus remain on the server.
Caution:
Never manually delete the binlog files.In addition to files necessary to recover the STA application database, the STA Backup Service also backs up STA WebLogic configuration files as well as its own STA Services daemon configuration files. The backup is a recursive backup of all the files and directories in their respective configuration directories.
Configuration file backups are performed once every 24 hours when the full STA database dump is performed. The backup file names format is YYYYMMDD_HHMMSS.filename.zip.gz.
The source and target locations of these backups are shown in Table 2-2:
Table 2-2 Backup Source/Target Locations
| Source Location | Local Copy | Remote Copy |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/YYYYMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/YYYYMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.fmconfig.zip.gz |
Where:
$STAHOME = /Oracle_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = Backup server IP address or name
$RDIR = Directory on backup server
There are two kinds of files involved in the monitoring operations:
These log the activities of the STA Services daemon and the Resource Monitor Administration utility, staresmonadm. These logs are collections of up to 10 log files, each up to 1.0 MB in size. The log file names are of the format *.log.N, where N is the number of the log (staservd.log.0, staservadm.log.0, staservd.log.1, and so forth).
The logs are rotated such that log file #1 will be reused when staservd.log.9 has been filled up. The active log file is always #0 (staservd.log.0). When log #0 fills up, it is renamed to log #1 and a new log #0 is started. By default, the STA Services, STA ResMon, and STA ResMonAdm logs are all located at:
/STA_logs/db/backups
The log location and internal format (either simple ASCII text or XML markup) are controlled by the logging properties files staservd.log.props, and staresmonadm.log.props, located at:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
Where:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Each time ResMon scans the system, it writes the gathered values out to a comma-separated-value (CSV) file located, by default, at:
/STA_logs/db/staresmon.csv
Programs such as Excel and MySQL can load this data file and perform various analytic and graphing functions with time-based values (for example, analysis of resource depletion trends).
Note:
The ResMon CSV file is neither purged, rolled, nor backed up by the STA Backup Service.Each record in staresmon.csv represents a scan of the system. The format of the 21 column record is shown in Table 2-3.
Table 2-3 Resource Monitor CSV File Format
| Col | Header | Description | Format |
|---|---|---|---|
|
1 |
TIMESTAMP |
Date and time of the scan |
"YYYY–MM–DD HH:MM:SS" |
|
2 |
TS_MB_MAX |
Maximum tablespace |
123 |
|
3 |
TS_MB_USED |
Total database space used |
123 |
|
4 |
TS_MB_AVAIL |
Database space remaining |
123 |
|
5 |
TS_PCT_USED |
Database tablespace used as a percentage of the max |
12.34% |
|
6 |
TS_PCT_HWM |
Database tablespace high water mark as a percentage of the max |
12.34% |
|
7 |
DBVOL_MB_MAX |
Maximum available space on the volume containing the database |
123 |
|
8 |
DBVOL_MB_USED |
Total database disk volume space used |
123 |
|
9 |
DBVOL_MB_AVAIL |
Database volume disk space remaining |
123 |
|
10 |
DBVOL_PCT_USED |
Database volume disk space used as a percentage of the max |
12.34% |
|
11 |
DBVOL_PCT_HWM |
Database volume high water mark as a percentage of the max |
12.34% |
|
12 |
LOGVOL_MB_MAX |
Maximum available space on the volume containing the logs |
123 |
|
13 |
LOGVOL_MB_USED |
Total logging disk volume space used |
123 |
|
14 |
LOGVOL_MB_AVAIL |
Logging volume disk space remaining |
123 |
|
15 |
LOGVOL_PCT_USED |
Logging volume disk space used as a percentage of the max |
12.34% |
|
16 |
LOGVOL_PCT_HWM |
Logging volume high water mark as a percentage of the max |
12.34% |
|
17 |
MEM_MB_MAX |
Maximum installed physical RAM |
123 |
|
18 |
MEM_MB_USED |
Total physical memory used |
123 |
|
19 |
MEM_MB_AVAIL |
Physical memory space remaining |
123 |
|
20 |
MEM_PCT_USED |
Physical memory space used as a percentage of the max |
12.34% |
|
21 |
MEM_PCT_HWM |
Physical memory high water mark as a percentage of the max |
12.34% |
Logging for the STA Services daemon, the Backup Service, Backup Service Administration Utility, and STA Resource Monitor Utility are controlled by the following logging configuration files:
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
Where $STA_HOME is the STA home location specified during STA installation; see the STA Installation and Configuration Guide for details.
The logging file contents and format are controlled by the Java Log Manage properties in these files. Table 2-4 summarizes these properties. For additional details, see the Oracle Java SE documentation at the following site:
http://docs.oracle.com/en/java/
Table 2-4 Java Logging Properties
| Property | Description | STA Setting |
|---|---|---|
|
java.util.logging.FileHandler.append |
Specifies whether the File Handler should append to existing files. Defaults to false. |
true |
|
java.util.logging.FileHandler.count |
Specifies the number of output files to cycle through. Defaults to 1. |
10 |
|
java.util.logging.FileHandler.formatter |
Specifies the Formatter class name. Defaults to java.util.logging.XMLFormatter. |
Java.util.logging.SimpleFormatter for human readability. The java.util.logging.XMLFormatter is commented out and available |
|
java.util.logging.FileHandler.level |
Specifies the default level for the Handler. Defaults to Level. ALL. |
CONFIG |
|
java.util.logging.FileHandler.limit |
Specifies the approximate maximum number of bytes to write to any one file. An entry of zero indicates no limit. Defaults to no limit. |
500000 (.5 MB) |
|
java.util.logging.FileHandler.pattern |
Specifies the output file name pattern. Defaults to "%h/java%u.log". |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g Where STA_logs is the logs location established during Linux installation; see the STA Installation and Configuration Guide for details. |
Log levels are controlled by the STA logging properties in these files. Table 2-5 summarizes the properties.
Table 2-5 STA Services Logging Properties
| Property | Description | STA Setting |
|---|---|---|
|
oracle.tbi.server.level |
Specifies the log level for the server. |
CONFIG |
|
oracle.tbi.serveradm.level |
Specifies the log level for the server administration functions. |
CONFIG |
|
oracle.tbi.resmonadm.level |
Specifies the log level for the resource monitor administration functions. |
CONFIG |
The STA database restoration procedure consists of loading the most recent full database dump and then replaying all the binary logs immediately following that dump.
There are distinct sets of backup files on the backup server directory. For example:
# cd /data/stabackups
# ls –1
20130721_133755.conf.zip.gz 20130721_133755.fmwconfig.zip.gz 20130721_133755.stadb-bin.000024.gz 20130721_133755.stafullbackup.sql.gz 20130722_133755.conf.zip.gz 20130722_133755.fmwconfig.zip.gz 20130722_133755.stadb-bin.000024.gz 20130722_133755.stafullbackup.sql.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000021.gz 20130723_133755.stadb-bin.000022.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.stadb-bin.000024.gz 20130723_133755.stafullbackup.sql.gz
The file name time stamp format is YYYYMMDD_HHMMSS. All the binary logs having the same date tag will be replayed into the database after the full dump is loaded.
The following administration tasks are discussed here:
Use this procedure to copy backup files to the STA server.
Copy the whole set of one day's files back to the STA server.
Oracle recommends copying everything to the /tmp directory. For example, assuming that STA is installed on the server sta.server.com and you are currently logged onto the backup server.
# scp 20130723*.* sta.server.com:/tmp/.
Password:
Log in to the STA server as root.
Unzip the *.gz files. For example:
# cd /tmp
# gunzip 20130723*.*.gz
Use this procedure to restore the configuration directory files.
Stop all STA processes. Then, restart only the MySQL server.
# STA stop all
# STA start mysql
Unzip the STAServer and STA Services Daemon configuration directories.
The zip files are created with the full directory paths to allow you to restore or overwrite existing files. The unzip command allows you to re-crown the root of the restore path with the –d option. Additional options allow more control, such as selective replace.
For a clean restoration, you should completely replace the existing configuration directory; however, back up the original first. For example:
# cd $WLSHOME
# zip –vr fmwconfig.orig.zip fmwconfig
# rm –rf fmwconfig
# cd /tmp
# unzip –X –d/ 20130723_133755.fmwconfig.zip
# cd $STAHOME/common
# zip –vr conf.orig.zip conf
# rm –rf conf
# cd /tmp
# unzip –X –d/ 20130723_133755.conf.zip
Where:
$WLSHOME =/Oracle_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
Perform the following commands as the MySQL root user.
To reload the database:
Clean out any residual stadb database if it exists. For example:
# mysql –uroot –p –e 'drop database stadb;'
Password:
Load the latest full dump. This creates the schema and installs all the data. For example:
# mysql –uroot –p –e 'source 20130723_133755.stafullbackup.sql;'
Password:
To replay the binlogs:
Run each of the incremental dumps (binlogs) from youngest to oldest.
If you have more than one binary log to execute on the MySQL server, the safest method is to process them all using a single connection to the server and a single MySQL process to execute the contents of all of 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
Another approach is to concatenate all the logs to a single file and then process the file:
# 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'
Note:
If you do not supply a password on the command line, MySQL prompts you for it before proceeding.Processing binary logs as shown in the example below may create multiple connections to the server. Multiple connections cause problems if the first log file contains a CREATE TEMPORARY TABLE statement, and the second log contains a statement that uses that temporary table. When the first MySQL process terminates, the server drops the temporary table. When the second MySQL process attempts to use that table, the server reports "unknown table."
# mysqlbinlog binlog.000001 |mysql –u root –p #<=== DANGER!!
# mysqlbinlog binlog.000002 |mysql –u root –p #<=== DANGER!!
As the Linux system root user, enter the following command:
# STA start all
Another restoration method is point-in-time, in which binary logs can be replayed from a specific start point to a specific end point in time.
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. After restoring the database from the full dump done the day before, and before restarting all the STA services, you can replay the most recent binary log from its initial log entry number "176" through entry number "6817916" with the commands shown in this procedure.
Use this procedure to restore the STA database from a range of log numbers.
Make sure all the STA processes are shut down and only the MySQL server is running:
# STA stop all
# STA start mysql
As the MySQL root user, extract the valid operations. For example:
# mysqlbinlog ––start–position=176 ––stop–position=6817916
/var/log/tbi/db/stadb–bin.000007 > ./recover.sql
Apply them to the database. For example:
# mysql –uroot –p –e 'source ./recover.sql'
Password:
As the Linux system root user, restart the STA application and STA Services Daemon:
# STA start all
For more information on point-in-time or incremental recovery operations refer to the MySQL documentation at the following site: