In some cases, backups of non-transactional tables such as MyISAM tables could contain additional uncommitted data. If autocommit is turned off, and both InnoDB tables and non-transactional tables are modified within the same transaction, data can be written to the non-transactional table before the binlog position is updated. The binlog position is updated when the transaction is committed, but the non-transactional data is written immediately. If the backup occurs while such a transaction is open, the backup data contains the updates made to the non-transactional table.

If the mysqlbackup process is interrupted, such as by a Unix kill -9 command, a FLUSH TABLES WITH READ LOCK operation might remain running. In this case, use the KILL QUERY command from the mysql command line to kill the FLUSH TABLES WITH READ LOCK statement. This issue is more likely to occur if the FLUSH TABLES operation is stalled by a long-running query or transaction. Refer to Chapter 7, mysqlbackup Command Reference for guidelines about backup timing and performance.

Do not run the DDL operations ALTER TABLE, TRUNCATE TABLE, OPTIMIZE TABLE, REPAIR TABLE, or RESTORE TABLE while a backup operation is going on. The resulting backup might be corrupted.

The only ALTER TABLE operations that can be safely run in parallel with a backup are those that do not influence the physical representation of records on disk, such as changing column names or default column values.