Can we protect data on non-global zones if the File System iDataAgent is installed only on the global zone?
Yes. We can protect file system data on non-global zones if the File System iDataAgent is installed only on the global zone. However, in order to enable consistent backups of application specific data on the non-global zones, you will need to install the corresponding application specific iDataAgent on the non-global zone.
How do we protect MySQL data on a non-global zone?
In order to enable consistent backups of MySQL data on a non-global zone, you need to install the MySQL iDataAgent on the non-global zone.
How do we backup MySQL databases?
We use mysqldump utility to perform backups on MySQL databases. Various storage engines such as InnoDB, MyISAM etc in MySQL server store the tables in different ways.
By default, the mysqldump utility uses the –opt flag for databases that contain MyISAM tables. The –opt flag uses the –lock tables command that locks all of the tables to be dumped before dumping them for backup. In addition, -lock-tables uses the READ LOCAL lock, which permits concurrent inserts (inserts at the end of the table) by other sessions while dumping tables.
In the case of transactional tables such as InnoDB, the mysqldump utility uses the --single-transaction flag, which is a much better option than --lock-tables because it does not need to lock the tables at all.
Can I run multiple transaction log backups in parallel?
When multiple transaction log backups run in parallel on two or more subclients, each log file is backed up only once. Only one log backup job can run at a time. If multiple log backup jobs are initiated at the same time, they are run sequentially in a queue.
How do I attain consistent backup of databases that have MyISAM or MyISAM and InnoDB mix tables?
We have a way to accept user options to get consistent backup of databases that have MyISAM or MyISAM and InnoDB mix tables.
- --single-transaction is used by default with Mysqldump command by the software. --single-transaction is required to attain consistent backups of InnoDB tables without locking.
- For consistent backups of MyISAM engines or MyISAM and InnoDB mix tables, we should lock tables before taking dump.
- Now --single-transaction and --lock-all-tables are mutually exclusive, they cannot be used together. Hence we skip --single-transaction using “--skip-single-transaction” and then perform --lock-all-tables.
- Commands passed in command line will take precedence over the default options.
- You can use the --skip-single-transaction --lock-all-tables options in the sAdvancedBackupOptions setting under Options that can be supplied to the mysqldump utility to get a consistent backup.
On which operating systems do we support cluster configuration for MySQL iDataAgent?
We support MySQL cluster configuration only on Linux.
Do we support NDB cluster configuration for MySQL iDataAgent?
No, we do not support NDB cluster configuration for MySQL iDataAgent.
Can we get database consistency for an IntelliSnap backup of MySQL databases?
Both MySQL IntelliSnap backup and Enterprise backup acquire lock during a backup operation. The lock has different behavior based on the MySQL storage engine being used. In case of transactional engines such as InnoDB, the lock does not affect any inserts or update. These locks affect only non-transactional engines such as MyISAM. Lock period for MyISAM tables is only for few seconds, till the time the snapshot is taken.
While running a backup operation in a Galera cluster, why does the MySQL error log file shows that the MySQL node is getting desynchronized and resynchronized?
While running a backup operation, locks are acquired on databases that cause the MySQL node to desynchronize and resynchronize every time the lock is released.
For a block level backup operation, databases are locked only once for a fraction of a second.
While running a backup operation, in what cases do the backup jobs complete with one or more errors?
Backup jobs from MySQL iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following cases:
- If the subclient contains multiple databases, and some of the database backups encounter errors and other database backups run successfully.
- If the subclient contains multiple databases, and some databases in the subclient are corrupted or removed from the database server.
Restore jobs from MySQL iDataAgent will be displayed as "Completed w/ one or more errors" in the Job History in the following case:
- During Logs Restore, if applying log into a database fails, it marks such databases as non-recoverable and continues with other databases.
Last modified: 8/23/2018 12:28:17 PM