EmergencyEMERGENCY? Get 24/7 Help Now!

Recovery after DROP & CREATE

 | August 22, 2012 |  Posted In: MySQL

In a very popular data loss scenario a table is dropped and empty one is created with the same name. This is because  mysqldump in many cases generates the “DROP TABLE” instruction before the “CREATE TABLE”:

If there were no subsequent CREATE TABLE the recovery would be trivial. Index_id of the PRIMARY index of […]

Read More

Recover BLOB fields

 | July 1, 2010 |  Posted In: Insight for DBAs, MySQL

For a long time long types like BLOB, TEXT were not supported by Percona InnoDB Recovery Tool. The reason consists in a special way InnoDB stores BLOBs. An InnoDB table is stored in a clustered index called PRIMARY. It must exist even if a user hasn’t defined the primary index. The PRIMARY index pages are […]

Read More

Debugging problems with row based replication

 | May 6, 2010 |  Posted In: Insight for DBAs, MySQL

MySQL 5.1 introduces row based binary logging. In fact, the default binary logging format in GA versions of MySQL 5.1 is ‘MIXED’ STATEMENT*;   The binlog_format  variable can still be changed per sessions which means it is possible that some of your binary log entries will be written in a row-based fashion instead of the […]

Read More

Recovery after DROP [ TABLE | DATABASE ]

 | July 19, 2009 |  Posted In: Insight for DBAs

In your recovery practice we often face the problem when data lost by execution DROP TABLE or DROP DATABASE statement. In this case even our InnoDB Data Recovery tool can’t help, as table / directory with files was deleted (if you have innodb-file-per-table). And the same for MyISAM, all .MYD / .MYI / .frm – […]

Read More