Restore Troubleshooting - MySQL iDataAgent
MSQL0002: Issue restoring MySQL databases when tables are defined using InnoDB engine
Restore operation fails with the following error message in MySQLRestore.log file under Log_Files folder.
err = ERROR 1005 (HY000) at line 33: Can't create table './DBNAME/TABLE.frm' (errno: 121)
If a database is deleted or lost due to the directory deletion, and that database contained tables that used the InnoDB engine, a restore from the CommCell Console fails.
Delete the database directory that was created due to the failed restore. Run the commands to create and drop an empty database before running the restore. This causes the MySQL engine to remove the table entries from the InnoDB data dictionary before the restore takes place, thus preventing the errors.
To resolve this issue:
- Delete the database directory that was created as a result of the failed restore.
- Create an empty database by running the following command.
mysql> create database mysql> create database <dbname>;
- Drop the empty database by running the following command.
mysql> drop database mysql> drop database <dbname>;
where <dbname> is the name of the database being restored.
- Run the restore.
MSQL0006: MySQL database restore operation appears hung in the Job Controller window
One of the following could be a reason for the restore operation to hang.
- Memory is full in the datadir on the destination server resulting in no space for the restore operation.
- The query running as part of a dump is too long and might take long time to finish. It could also hang in the process.
- There are network issues resulting in restore operation to hang.
- The data being restored is huge so it might take a long time for the restore to finish. The restore operation might be running but it appears as hanging.
To resolve this issue.
- From the application level, check if the MySQL server log memory is full.
- Run SHOW PROCESSLIST query on the database server to view the running activities.
- Log files are saved only if bin_log is enabled, so first make sure that it is enabled. Then monitor the transaction log file status to see if it is growing.
- If bin_log is not enabled, then monitor the datadir on the destination server to see if the file size is increasing. The file size should grow if the restore operation is running.
MSQL0008: Issue restoring MySQL system databases
When you restore a backup copy of the system databases, you are not able to see changes in the restored files after the restore operation is complete.
You can find the following error message in MySQLRestore.log file under Log_Files folder.
err = ERROR 1580 (HY000) at line 1: You cannot 'DROP' a log table if logging is enabled ret = 1
If general logging and slow query logging are enabled in the MySQL Server, the MySQL system databases are not restored.
To resolve this issue:
- In the MySQL configuration file, disable general logging and slow query logging by setting their value as 0, as shown in the following example:
# General and Slow logging Section
- Restart the MySQL Server.
- Run the restore.
Restore jobs from MySQL iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following cases:
- During Logs Restore, if applying log into a database fails, it marks such databases as non-recoverable and continues with other databases.
In a disaster recovery scenario, use the following procedure to recover data associated with the following entities:
- Deleted storage policy
- Deleted client, agent, backup set or instance
Before You Begin
This procedure can be performed when the following are available:
- You have a Disaster Recovery Backup that contains information on the entity that you are trying to restore. For example, if you wish to recover a storage policy (and the data associated with the storage policy) that was accidentally deleted, you must have a copy of the disaster recovery backup that was performed before deleting the storage policy.
- Media containing the data you wish to recover is available and not overwritten.
- If a CommCell Migration license was available in the CommServe when the disaster recovery backup was performed, no additional licenses are required. If not, obtain the following licenses:
- IP Address Change license
- CommCell Migration license
See License Administration for more details.
- A standby computer, which is used temporarily to build a CommServe.
Recovering Deleted Data
- Locate the latest Disaster Recovery Backup that contains the information on the entity (storage policy, client, agent, backup set or instance) you are trying to restore.
- Check the Phase 1 destination for the DR Set or use Restore by Jobs for CommServe DR Data to restore the data.
- If the job was pruned and you know the media containing the Disaster Recovery Backup, you can move the media in the Overwrite Protect Media Pool. See Accessing Aged Data for more information. You can then restore the appropriate DR Set associated with the job as described in Restore by Jobs for CommServe DR Data.
- If the job is pruned and you do not know the media containing the Disaster Recovery Backup, you can do one of the following:
- If you regularly run and have copies of the Data on Media and Aging Forecast report, you can check them to see if the appropriate media is available.
- If you do not have an appropriate report, and know the media that contains the DR Backup, catalog the media using Media Explorer. Once the cataloging process is completed, details of the data available in the media are displayed.
- On a standby computer, install the CommServe software. For more information on installing the CommServe, see Install the CommServe.
- Restore the CommServe database using the CommServe Disaster Recovery Tool from the Disaster Recovery Backup described in Step 1. (See CommServe Disaster Recovery Tool for step-by-step instructions.)
- Verify and ensure that the NetApp Client Event Manager NetApp Communications Service (EvMgrS) is running.
- If you did not have a CommCell Migration license available in the CommServe when the disaster recovery backup was performed, apply the IP Address Change license and the CommCell Migration license on the standby CommServe. See Activate Licenses for step-by-step instructions.
- Export the data associated with the affected clients from the standby CommServe as described in Export Data from the Source CommCell.
When you start the Command Line Interface to capture data, use the name of the standby CommServe in the -commcell argument.
- Import the exported data to the main CommServe as described in Import Data on the Destination CommCell.
This brings back the entity in the CommServe database and the entity is visible in the CommCell Browser. (Press F5 to refresh the CommCell Browser if the entity is not displayed after a successful merge.)
- You can now browse and restore the data from the appropriate entity.
As a precaution, mark media (tape media) associated with the source CommCell as READ ONLY before performing a data recovery operation in the destination CommCell.