Showing entries 1 to 10 of 12
2 Older Entries »
Displaying posts with tag: MySQL Data Recovery (reset)
Recovery After DROP TABLE, With innodb_file_per_table ON

Author Andriy Lysyuk.


In the previous post, we described a situation when the UnDrop For InnoDB toolkit can be used to recover an accidentally dropped table with innodb_file_per_table=OFF.
In this post, we’ll show how to recover MySQL tables or databases if innodb_file_per_table is ON. This option tells InnoDB to store each table with a user in a separate data file.

For the recovery test, we’ll use the same sakila database that we used in the previous post.

root@test:/var/lib/mysql/sakila# ls …
[Read more]
Recovery After DROP TABLE, With innodb_file_per_table OFF

Author Andriy Lysyuk.


Unfortunately, human mistakes are inevitable. That’s how life is. Wrong DROP DATABASE or DROP TABLE may destroy critical data on the MySQL server. Obviously, backups would help, however they’re not always available. This situation is frightening but not hopeless. In many cases it’s possible to recover almost all the data that was in the database or table.
Let’s look at how we can do it. The recovery plan depends on whether InnoDB kept all data in a single ibdata1 or each table had its own tablespace. In this post we will consider the case when innodb_file_per_table=OFF. This option assumes that all tables are stored in a common file, usually located at /var/lib/mysql/ibdata1.

One Wrong Move, And The Table’s Gone

For our scenario, we use …

[Read more]
Recover Table Structure From InnoDB Dictionary

When a table gets dropped, MySQL removes the respective .frm file. This post explains how to recover the table structure if the table was dropped.

You need the table structure to recover a dropped table from the InnoDB tablespace. The B+tree structure of the InnoDB index doesn’t contain any information about field types. MySQL needs to know that in order to access records of the InnoDB table. Normally, MySQL gets the table structure from the .frm file. But when MySQL drops a table the respective frm file removed too.

Fortunately, there’s one more place where MySQL keeps the table structure. It’s the InnoDB dictionary.

The InnoDB dictionary is a set of tables where InnoDB keeps information about the tables. I reviewed them in detail in a separate InnoDB Dictionary post earlier. After the DROP, InnoDB deletes records related to the dropped table from …

[Read more]
Recovering A Corrupt MySQL Database

Author Andriy Lysyuk.

The unDROP for InnoDB tool can be used to recover corrupt MySQL databases. In this post, we will show how to repair a MySQL database if its files got corrupted and even innodb_force_recovery=6 doesn’t help.

The corruption of InnoDB tablespace may be caused by many reasons. A dying hard drive can write garbage, thus, page checksum will be wrong. InnoDB then reports to the error log:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 4.

MySQL is well known for its poor start-up script. A simple upgrade procedure may end up with two mysqld processes writing to the same tablespace. That leads to corruption too. Sometimes, power reset corrupts not only the InnoDB files, but the whole file system becomes unusable …

[Read more]
InnoDB Dictionary

Why Does InnoDB Need A Dictionary

An InnoDB dictionary is a set of internal tables InnoDB uses to maintain various information about user tables. It serves as API between a human and the database. While the humans refer to tables by their names, InnoDB works with integer identifiers. The dictionary stores correspondence between table name and index_id.

The dictionary tables are normal InnoDB tables, but they’re not visible to a user. However, some versions of MySQL provide read-only access to the dictionary in information_schema database.

The dictionary is stored in ibdata1. Root page of SYS_TABLES, for example, has id 8, so it’s the eighth page from the beginning of ibdata1.

The dictionary pages are in REDUNDANT format even if you use MySQL 5.6. I hope to write more about record formats in future posts. For now, it’s enough to mention that REDUNDANT is the oldest record format. It was available since 4.0 …

[Read more]
Live MySQL Slave Rebuild with Percona Toolkit

Recently, we had an edge case where a MySQL slave went out-of-sync but it couldn’t be rebuilt from scratch. The slave was acting as a master server to some applications and it had data was being written to it. It was a design error, and this is not recommended, but it happened. So how do you synchronize the data in this circumstance? This blog post describes the steps taken to recover from this situation. The tools used to recover the slave were pt-slave-restartpt-table-checksum, pt-table-sync and mysqldiff.


To illustrate this …

[Read more]
TwinDB talks on Percona Live 2016

Percona Live is a Christmas in MySQL world. It’s time when all friends and family gather over a glass of beer. Everyone is talking about achievements of the last year and make New Year resolutions for a next one.

There will be two talks from TwinDB this year. One is about data recovery and one – about backups.

The data recovery talk is a kind of traditional talk. I will briefly cover InnoDB files format so you know where to look for data. I will show how to recover data from two most popular accidents: InnoDB tablespace corruption and DROP TABLE or DROP DATABASE. Data recovery is impossible without table structure recovery. I will show how to get the structure from an .frm file or from InnoDB dictionary (think of DROP TABLE when the .frm file is gone). We made a drastic improvement in user …

[Read more]
Data loss after MySQL restart

Not so long ago I had a customer who experienced data loss after MySQL restart. It was really puzzling. MySQL was up & running for many months, but after the customer restarted MySQL server all tables have gone. The tables were still visible in SHOW TABLES output, but they were not readable:

mysql> show tables like 'actor';
| Tables_in_sakila (actor) |
| actor                    |
1 row in set (0.00 sec)

mysql> select * from actor;
ERROR 1146 (42S02): Table '' doesn't exist

To understand what’s happened let make some experiments (WARNING: Don’t do it on production or with valuable data).

Let’s take a healthy MySQL instance with installed sakila database.

While MySQL …

[Read more]
Recover corrupted or crashed MySQL database online

Earlier before we blogged about ways to recover corrupt MySQL database with TwinDB Data Recovery Toolkit. However learning curve of the toolkit is rather steep. It takes time to get familiar with InnoDB internals and the tool. And let’s be honest nobody gets prepared for data loss – people who prepare for disaster recovery take and verify backups. So when an accident happens precious time has to be spent on learning and scripting.

At TwinDB we automate everything. With data recovery automation is not straightforward, but we did it. In the post I will show how to recover corrupted MySQL database in the fastest possible way.

MySQL Data Recovery Portal

MySQL Data Recovery Portal is a web interface to TwinDB …

[Read more]
How to recover table structure from FRM files online

Recently we announced MySQL Data Recovery Portal. Here we automated some data recovery routines and published web interface to them.

First, it was a tool to estimate recovery chances from corrupted InnoDB tablespaces.

Now it’s even more exciting and useful feature – recovery table structure from FRM files online.

There are several methods to recover MySQL table structure from FRM files.

On MySQL Data Recovery Portal we utilize a combination of them.

Fake table method

The idea is to create a dummy InnoDB table, replace its .frm file with .frm file we want to recover and run SHOW CREATE TABLE.

Let’s say we have actor.frm and we want to get structure of table actor.

Algorithm is following:

Create a dummy table with the same name, actor. The …

[Read more]
Showing entries 1 to 10 of 12
2 Older Entries »