MySQL Won’t Start Due to InnoDB Corruption - Database Recovery Walkthrough |Stellar Repair for MySQL

MySQL database recovery walkthrough for administrators facing InnoDB corruption when MySQL won’t start. This video demonstrates a realistic MySQL crash scenario where a corrupted .ibd file causes the MySQL service to shut down unexpectedly, leaving critical data inaccessible.

The tutorial begins with log analysis and attempts manual InnoDB Force Recovery (levels 1–6)—the standard DBA-recommended approach for MySQL crash recovery. You’ll see how innodb_force_recovery works, why recovery levels are increased, and why this method often fails or becomes unsafe in severe InnoDB corruption scenarios.

When manual recovery is unsuccessful, the video shows how to safely recover the entire MySQL database schema and 5,000+ records using Stellar Repair for MySQL, even when the MySQL service cannot start. The recovered data is verified for integrity and exported to formats such as MySQL, MariaDB, CSV, and SQL scripts.

This walkthrough is intended for MySQL administrators, DBAs, DevOps engineers, and backend developers who need a reliable and time-critical solution for recovering corrupted InnoDB tables and restoring production data.

Chapters /Timestamp
00:00 MySQL Crash Scenario Overview
00:17 What Happens When MySQL Won’t Start
00:53 Setting Up MySQL Environment (XAMPP)
01:16 Reviewing Database Tables and Data
01:57 Simulating InnoDB Table Corruption (.ibd)
03:13 MySQL Service Fails to Start
03:39 Checking MySQL Error Logs
04:11 What Is InnoDB Force Recovery
04:20 InnoDB Force Recovery Levels 1–6 Explained
05:23 Editing my.cnf for innodb_force_recovery
05:58 Testing Force Recovery Level 1
06:25 Escalating Force Recovery Levels
06:52 Risks of Higher Force Recovery Levels
07:10 Why InnoDB Force Recovery Fails
07:25 When Manual MySQL Recovery Is No Longer Safe
07:35 Using Stellar Repair for MySQL
07:40 Copying MySQL Data Directory
08:08 Scanning Corrupted MySQL Database
08:42 Recovering Tables, Schema, and Records
09:06 Verifying Recovered Data Integrity
09:33 Exporting Data (CSV, MySQL, SQL)
10:25 Final Thoughts for MySQL Admins

Important for DBAs
Incorrect use of innodb_force_recovery can permanently damage InnoDB tablespaces and result in irreversible data loss. This video explains both the risks and a safer recovery approach.

Related Article: https://www.stellarinfo.com/blog/mysql-innodb-force-recovery-not-working/
Tool Used: https://www.stellarinfo.com/mysql-repair.php

If your MySQL server won’t start, InnoDB tables are corrupted, or critical data is inaccessible, this walkthrough provides a practical, safe, and admin-focused MySQL database recovery solution.

---

Closed Caption:

Ever caught yourself in a scenario where
you're working on some data, you're
using MySQL, everything's going fine,
and then boom, out of nowhere, the MySQL
service stops working, you no longer
have access to your crucial data, and
you're pretty much stuck. So, in this
video, we're basically going to cover a
very realistic scenario where MySQL
service is going to just stop working
and not longer going to be able to start
it again. um we're going to try and
attempt to recover the data using some
manual recovery methods uh like the um
ionb recovery method um at different
levels and when that fails as well we're
going to use the stellar recovery tool
for MySQL just to demonstrate how easy
it can be to recover your schema as well
as the underlying data and get exports
at different levels when this kind of
things happen. So without further ado,
let's get right into it.
Okay. So, what I'm going to now show
you, I'm going to use basically ZAMP to
host this entire uh scenario. I'm going
to start the SQL service, the Apache
service just to show you everything's
running fine. And then we're going to
click on admin here. Uh give it a second
to load up and then I'll show you
exactly what I have set up. So what we
have here is a um right move data set
which is essentially uh a database
that's to do with property information.
Um and you have just some basic fields.
You have an ID field, a price field,
address field, and a created app field.
So as you can see everything's working
fine. I mean we can browse through the
data. You can look at how much there is
and whatnot. So there's around 5,000
rows in total. And this is a bunch of
simulated data. Now obviously in a
realistic scenario this video will be
very useful to people that are
constantly working on databases like
database administrators, data engineers,
data analysts or anyone who might run
into a corruption issue. So what we're
going to do now is um intentionally
corrupt the database um and then show
you exactly what that scenario would
look like. So, I've created a file
that's going to um that's a exact copy
of our properties table that we just
looked at. And then I'm going to go into
the the location where the um properties
data is currently stored. For me, it's
stored in the data folder within uh
MySQL. So, I'm going to go in there and
my database name is right move demo 2.
Now, obviously, you wouldn't have to
manually corrupt your database cuz
you've ended up in this situation
naturally because of either your server
crashing due to a power outage or some
kind of, you know, memory issue or a
disk issue. So, what I'm going to do is
replace the actual, you know, um, fully
functioning property file. Actually,
I'll just delete that one cuz that's the
fully functioning one. And before I do
that, actually, I should remind myself
to stop these services cuz otherwise I
won't be able to do anything. So what
I'm going to do is I'm going to delete
that uh IDB file for properties and then
the corrupted one I'm just going to
rename it and get rid of the corrupted
extension. So essentially this file has
some corruption in it and it's going to
simulate an a realistic uh scenario
where you're unable to access the data
and MySQL service is not going to start
either. Okay, so let's go back into
ZAMP. Um we're going to attempt to start
Apache. That's going to start fine. And
then now when we the interesting part is
let's try and start MySQL. And as you
can see it's kind of stuck. It's saying
attempted to start MySQL but nothing
really happens. Let's try again. And
then we we have this issue. It says shut
down unexpectedly. Could be due to a
blocked port missing dependency or
improper shutdown. If you wanted to, you
can click on the logs. We can look at
the error log. And if you scroll all the
way to the bottom, uh what we'll see
right here is it will say there was some
kind of operating system issue um that
it's unable to access certain files um
to try and fix the or to try and go
through the recovery that it was trying
to do on this specific table. Um now
obviously this isn't a permissions issue
because I've double checked and normally
you'll get the same kind of generic
error whenever this happens. Now some of
the suggestions it will give you is one
of the suggestions is to try and go into
this force recovery mode. Um essentially
all the and InnoDB force recovery mode
does is there's around six levels on
this. By default your configuration is
set to zero which means whenever you
start the MySQL service it's going to go
through a bunch of checks. Now when you
do inb force recovery equals 1 that
means skip like the basic safety checks.
If that works then it's just going to
start the SQL service fine and at that
point you can manually dump all the data
and then um like keep a backup of your
data. If that doesn't work, you have to
step up to two, three, four, five, and
level six all the way to six. um the the
more levels you jump up on the recovery
on the manual recovery, the more riskier
it gets cuz there's a higher chance of
the recovery itself corrupting your
table completely and then your data will
be even harder to uh harder to recover.
So, we're going to go through this
process to try and see if we can even
get the MySQL service starting cuz right
now we're pretty much stuck. It's not
starting at all. So it's saying we
should uh essentially go to the
configuration file and then set this to
greater than zero. So we're going to
start with one just a basic right. So in
mine is pretty easy. I can go to MySQL
go to the config my.in. It'll be my CNF
if I'm not wrong on Linux. And then if I
scroll all the way down um I've added
this already but because I've added a
hashtag that means it's commented out.
So it's not counted in in the
configuration file. So I will get rid of
this which means it's going to start
getting counted in or factored in. And
I'll set this to one. And then when I
save this essentially this configuration
is now updated. So we can go back into
ZAMP and then um click on trying to
start the service. So let's try to
start. Start again. Same thing. Let's
look at the logs. What's the log saying?
Let's go all the way to the bottom
again. And then as you can see we kind
of have the same issue happening here.
So again, this is from literally just
about a few seconds ago. Um, it's
complaining about the same thing and
it's asking to try and set the recovery
level to greater than zero. Now we're
going to go all the way up to six. So
let's try two. Let's try starting it
again. No luck. Let's try three. Oops.
Three. No, like I was saying, the more
higher you go, the riskier it gets cuz
it's skipping specific checks. So, we
got some movement there, but it still
wasn't able to recover fully. Start
again. Same thing again.
Start again.
Same thing. And then last one is up to
six. You can't go any higher than this
cuz you could, but it's not going to
make a difference. So, let's try again.
This is essentially the riskiest level.
We're willing to take that risk. Let's
try and start. And boom. It's still
pretty much hopeless. It's it's a
stressful situation. You've got a bunch
of important data. People are chasing
you. like what can you do at this point?
Now, this is where the um Stella
recovery tool for MySQL makes it super
easy to avoid all of these steps and
just try and recover your data, the
schema as well at the same time and
export it to a format that's reasonable
for you. So, what we're going to do is
I'm going to close this off and then in
order for us to be able to uh like put
this data into uh the Stella recovery
tool, we need to make a copy of your
data folder. So go ahead and find where
your data folder is. For me, it is right
here. I'm going to copy this data
folder. And it's essentially going to
include all of your databases on all of
your tables. So I'm going to copy that
and make a local copy onto my desktop.
So let's save somewhere else. I'm going
to drag it over. And that's it. If I
open it, you'll see the tables that I
had. And one of them is right move demo
demo 2, which is the data that's
corrupted. So let me close this off. And
then what I'm going to do is open the
recovery tool. The Stella recovery tool
is pretty straightforward. Uh very min
minimalistic design. So there's not much
cluttering uh your view and it's pretty
simple. Going to click on select
database and then click browse. From
there uh we have to find that data
folder that we just pasted on my desktop
and then just go to desktop, click on
data, click okay and then click okay
again. What this would do is scan for a
list of uh eligible databases that it
would be able to recover. So, I'm going
to only click on the dimmer 2 because I
don't want to waste any time. Click
repair and boom. Simple as that. Click
okay. Now, what we can even do is the
nice part is you can click you can see
the actual database that was recovered.
You can see the tables, the schema, you
can see the properties. You can click on
properties, view the schema, verify that
it's all correct. And then at the
bottom, you even get like a nice little
log of what it's done. Um, as you can
see, there's 5,000 records that are
present, which means it's recovered all
of the data and not just a partial fix,
which is quite a big win. And it only
took like a few seconds. So, in a
scenario where it's very very time
critical for you to try and recover the
data and get the database up and
running, this is a very good solution.
So, um, yeah, pretty much all the data
is intact. The data integrity is fine.
What you can then do is um click on the
save and then you're going to be able to
essentially save this in a format that
is uh reasonable for you. You can save
it in a CSV, you can save it in MySQL,
Maria DB, XLS, SQL script, etc. Well,
for this demo, I was just going to save
it as a CSV just to show you how that
looks like. And then click save. It's
processing. It's done the processing.
Uh, and then even opens up the folder
for you. So, you don't have to do much
on the up front. We'll go in there and
then if we click on this,
as you can see, well, the data is in the
format that it needs to be and it's in a
nice CSV. So, you can either now create
like a Python script that's going to
take all this data, dump it in the
database for you, or export it in a
different format like an SQL file which
is easier to import directly. Um, and
that's pretty much it. Um, at this
point, um, everything's working,
everyone's happy, and I'm hope you found
this video useful, and we'll be making
use of the recovery tool, um, that
Stella has for MySQL and make your life
easier in a situation where you're stuck
and unable to access your data. Thanks
for watching.