# Option for disabling fast shutdown during xtrabackup prepare

**URL:** <https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817>\
**Category:** Percona XtraBackup\
**Created:** [April 24, 2024, 6:11am UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817 "2024-04-24T06:11:31Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rishabh\_Gupta](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rishabh_gupta/32/10929_2.png) [@Rishabh\_Gupta](https://forums.percona.com/u/Rishabh_Gupta)\
**Post date:** [April 24, 2024, 6:11am UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/1 "2024-04-24T06:11:31Z")

</div>

Hi @Community,

I am looking if there is option to do the slow shutdown of innodb during xtrabackup prepare step.  
Currently from xtrabackup --prepare logs, I see that the fast shutdown is performed.

Sample line from the prepare logs:  
xtrabackup: starting shutdown with innodb\_fast\_shutdown = 1

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [April 24, 2024, 5:21pm UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/2 "2024-04-24T17:21:09Z")

</div>

Hello @Rishabh_Gupta,  
Can you give us more context here? Why do you want to disable this?

---

<div class="post-metadata">

**Author:** ![Rishabh\_Gupta](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rishabh_gupta/32/10929_2.png) [@Rishabh\_Gupta](https://forums.percona.com/u/Rishabh_Gupta)\
**Post date:** [April 25, 2024, 4:24am UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/3 "2024-04-25T04:24:11Z")

</div>

Hi @matthewb,

I am trying to root cause an issue in which secondary index are corrupted on restore.  
As we have lot of secondary indexes and frequent updates, we have change buffer enabled.

While restoring I haven’t copied the ib\_buffer\_pool and undo, redo logs as I am assuming that percona created backups are consistent and doesn’t require crash recovery. So innodb will recreate them on restore.

I noticed that during the prepare step we do the fast shutdown of innodb. So, trying to do the slow shutdown and see if there is still secondary index corruption occurs.

**xtrabackup version:**  
2.4.29

**source mysql version:**  
5.7.44

**commands used:**  
xtrabackup --backup --host=$MYSQL\_CONTAINER\_IP --user=root --password=$MYSQL\_ROOT\_PASSWORD --target-dir=/xtrabackup\_data

xtrabackup --prepare --target-dir=/xtrabackup\_data

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [April 25, 2024, 2:07pm UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/4 "2024-04-25T14:07:30Z")

</div>

> [@Rishabh\_Gupta](#):
>
> as I am assuming that percona created backups are consistent and doesn’t require crash recovery.

PXB does perform crash recovery during the `--prepare` stage. When this is completed, your backup is now in a consistent state.

If you are having index corruption (extremely rare for innodb), I would check _before_ you take the backup. You can run CHECK TABLE, ANALYZE TABLE, and even OPTIMIZE TABLE (will lock and rebuild the table).

---

<div class="post-metadata">

**Author:** ![Rishabh\_Gupta](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rishabh_gupta/32/10929_2.png) [@Rishabh\_Gupta](https://forums.percona.com/u/Rishabh_Gupta)\
**Post date:** [April 26, 2024, 5:19am UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/5 "2024-04-26T05:19:08Z")

</div>

Yeah, I checked the indexes in source server, and they are no corruption found.  
The issue is happening in most of the secondary indexes after restoring.

That’s why I am looking for some option to try performing the slow shutdown during prepare step and then see if the issue occurs again.

Is it possible currently in PXB?

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [April 26, 2024, 6:00pm UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/6 "2024-04-26T18:00:42Z")

</div>

> [@Rishabh\_Gupta](#):
>
> I am trying to root cause an issue in which secondary index are corrupted on restore

After you restore, where do you see corruption? Does mysql crash with errors?

You might try adding this to /etc/my.cnf  
[xtrabackup]  
innodb\_fast\_shutdown=0

but I don’t know if that works.

---

<div class="post-metadata">

**Author:** ![Rishabh\_Gupta](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rishabh_gupta/32/10929_2.png) [@Rishabh\_Gupta](https://forums.percona.com/u/Rishabh_Gupta)\
**Post date:** [May 1, 2024, 6:07am UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/7 "2024-05-01T06:07:20Z")

</div>

No mysql didnt crash. The server is started but

But when I run the CHECK TABLE command I am getting error. This indicates the secondary index is corrupted after restore.

| testdb12.table3 | check | Warning | InnoDB: Index ‘table3\_sec\_index\_2’ contains 62024789 entries, should be 62026461. |  
| testdb12.table3 | check | error | Corrupt

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [May 1, 2024, 2:04pm UTC](https://forums.percona.com/t/option-for-disabling-fast-shutdown-during-xtrabackup-prepare/29817/8 "2024-05-01T14:04:49Z")

</div>

Use `innodb_force_recovery` [https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html](https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html) in order to make MySQL start up. Then use mysqldump to dump just that table. Drop it. Shut down mysql and remove force\_recovery. Start mysql. Import the table.
