Chatta subito con l'assistenza
Chat con il supporto

NetVault Plug-in for MySQL 11.2 - User Guide

Introducing NetVault Backup Plug-in for MySQL Installing and removing the plug-in Configuring the plug-in Backing up data Restoring data Working with native MySQL replication Using the plug-in in a Failover Cluster environment Troubleshooting

Restoring data: an overview

This topic outlines the plug-in’s restore process and describes all the functionality available for use. In addition, Examples of restore scenarios for MySQL Standard/Community and Examples of restore scenarios for MySQL Enterprise Backup offer examples of the various types of restore. Quest recommends that you review these topics to ensure that you understand the functionality available and how it applies to the various types of restore.

Reviewing the available restore methods for MySQL Standard/Community

To perform a restore successfully, you must understand the types of restore that are available for use.

When the plug-in performs a Full or Individual Database/Table Copy Only backup, it uses MySQL’s mysqldump utility to stream the SQL statements that are used to create and populate the tables, directly to the backup media. When the plug-in restores one of these forms of backup, the SQL statements are read directly from the backup media, and run automatically.

When the plug-in performs Incremental or Differential Backups, MySQL’s Binary Log Index is used to determine which Binary Logs must be copied to the backup media. When these backups are restored, the Binary Logs are restored to a temporary directory, “NETVAULT_HOME/tmp/MySQL”. The mysqlbinlog utility is then used to generate SQL statements for each transaction that was recorded in the Binary Logs. These statements are then run automatically. This process is called “applying Binary Logs.”

During Incremental and Differential Restores, all transactions recorded in the Binary Logs can be applied, or they can be applied up to a particular time (PIT Recovery). PIT Recovery is useful when trying to recover up to the point directly preceding data corruption, such as a developer accidentally dropping a table or running an incorrect update.

PIT Recovery can be performed on the Binary Logs that are to be restored during an Incremental or Differential Restore. Time-based PIT Recovery is useful when the time that the data corruption occurred is known. For example, if a developer dropped a table at 6:00 A.M., PIT Recovery can be performed with a stop time of 5:55 A.M.

Time-based PIT Recovery is typically a one-step process: Restore the Binary Logs from the Incremental or Differential Backup by selecting the Restore and Apply Binary Logs option on the Options tab, and specifying the stop time to be just before the unwanted transaction.

When the actual time of the data corruption is unknown, or a more precise recovery is required, a position-based PIT Recovery should be used. For example, if a developer dropped a table from the database, but does not know the exact time when the table was dropped, a position-based PIT Recovery should be used.

Position-based PIT Recovery is a three-step process:

1
Restore the Binary Logs from the Incremental or Differential Backup to a temporary directory on the MySQL Server by selecting the Restore Binary Logs to Temporary Directory to Identify Time or Position option on the Options tab.
2
Use MySQL’s mysqlbinlog utility to identify the specific position of the unwanted transaction. For more information, see the Point-in-Time Recovery section of the MySQL Reference Guide.
3
Restore the same Incremental or Differential Backup again; however, select the Apply Binary Logs from Temporary Directory restore option, and specify the stop position that exists right before the unwanted transaction.

Restoring data in MySQL

A standard restore with Plug‑in for MySQL includes the steps outlined in the following topics.

Selecting data for a restore

1
2
On the Create Restore Job — Choose Saveset page, select Plug‑in for MySQL from the Plugin Type list.
When you select a saveset, the following details are displayed in the Saveset Information area: Job ID, job title, server name, client name, plug-in name, saveset date and time, retirement setting, Incremental Backup or not, Archive or not, saveset size, and snapshot-based backup or not.
5
Click Next.
6
On the Create Selection Set page, select the data that you want to restore.
Full or Individual Database/Table Copy Only Backups: The root node is listed as “All Databases” — because the actual database and table data was included in the backup.
IMPORTANT: Although the root node is entitled “All Databases,” it does not account for all the databases that currently exist for a target MySQL Instance. Selecting this option only restores all the data items that were selected for the backup job; that is, by selecting this node for a restore, you are not performing a restore of all the databases that currently exist in a MySQL Instance — only those databases included in the backup.
Incremental or Differential Backups: The root node is listed as “Binary Logs” — because the transactions (Binary Logs) that occurred since the previous backup was performed are included in this form of backup.
IMPORTANT: MySQL uses multiple file-formats to storage database information. Verify that you include the .frm files in the restore process to ensure that the restored database is functional.
Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione