Views:

Summary



This article provides information on how to configure DPX Block backup for protecting MySQL implementation instances. Note that the description here illustrates a protection method that relies on a vendor supplied binary. Catalogic Software, Inc. does not directly support application interfaces to coordinate application-consistent backup of MySQL. The methodology described here uses a vendor supplied binary and only describes how this binary can be automated in a backup job to quiesce and back up data. For more information relating to backup, transaction logs, data recovery, or MySQL best practices, review the documentation available at MySQL.

Resolution



DPX uses several methods to quiesce applications by using pre/post-scripts for snapshots. The pre/post-script facility automates a script triggered to occur right before VSS or LVM snapshot, right after VSS or LVM snapshot, or right after data transfer is complete. For application interfaces that DPX does not directly support, it is common to use pre/post snapshot scripts which will quiesce the application, perform the VSS/LVM snapshot, and then resume the application back to normal activity. In many cases, this pre/post snapshot facility is used to stop the application, snapshot the data in "cold backup" mode, and then bring the application up again. In the case of MySQL, a script can be used to freeze the database files (with new activity being sent to transaction logs), perform the VSS/LVM snapshot, and then unfreeze the database files to resume normal activity. In either case, once the VSS/LVM snapshot is complete, the DPX is free to transfer that data while the application continues to serve data.

For a complete and general description of how pre/post snapshot scripting works, see "Implementing Pre-Script and Post-Script for Snapshots Operations" in the DPX User's Guide.

You need to do the following:

  1. Install the DPX client to your MySQL host.
  2. Create a script containing necessary actions to freeze the DB (for example MySQLfreeze.bat/MySQLfreeze.sh), and save this to the DPX 'sched\scripts' directory.
  3. Create a a script containing the necessary actions the thaw the DB (for example MySQLthaw.bat/MySQLthaw.sh), and save this to the DPX 'sched\scripts' directory.
  4. Following "Implementing Pre-Script and Post-Script for Snapshots Operations" in the DPX User's Guide, create the required scrinfo.txt and save this script to the DPX 'bin' directory.

If your DPX block backup job name is MySQLprotect, an example scrinfo.txt file might look like:

# MYSQL freeze thaw script cmd=MySQLfreeze.bat/MySQLfreeze.sh<>type=presnap<>jobname=MySQLprotect<>abort_on_fail=1

cmd=MySQLthaw.bat/MySQLthaw.sh<>type=postsnap<>jobname=maxdpbrotect

As with any scripting or programming effort, it is strongly suggested to check and print accurate status messages for job log auditing and job control. Note that if an error status is not checked and handled properly, it is possible that the expected result from the vendor supplied binary is not achieved and the backup will continue with live data that is not in a quiesced application-consistent state which later results in difficulty and failure at restore time. It is strongly suggested to use the DPX ’bexit’ binary to pass any failure status to the job for error processing. With the scrinfo.txt example above, the job will fail if the user supplied script returns an error status. Backup job failure in this case is preferred as the failure will be visible to the data protection engineer who can alert the application owner for corrective action. For more information on the use of 'bexit' for error code passing on Windows platforms, see the "Pre-Scripts and Post-Scripts" section in the DPX Reference Guide. Using pre/post snapshot scripting along with MYSQL script should result in a very brief period of time where the database files are frozen (read-only). According to the MySQL documentation, the MySQL database engine should remain active during this time and send any new commits to transaction logs, which will be flushed after the database files are unfrozen. For additional details on placement of database files, transaction logs, and MySQL best practices for backup and recovery, consult SAP documentation and/or technical support.