# Problem while starting instance with compressed innodb tables

**URL:** <https://forums.percona.com/t/problem-while-starting-instance-with-compressed-innodb-tables/2001>\
**Category:** Other MySQL® Questions\
**Created:** [February 22, 2013, 8:17am UTC](https://forums.percona.com/t/problem-while-starting-instance-with-compressed-innodb-tables/2001 "2013-02-22T08:17:08Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Boemm](https://avatars.discourse-cdn.com/v4/letter/b/e68b1a/32.png) [@Boemm](https://forums.percona.com/u/Boemm)\
**Post date:** [February 22, 2013, 8:17am UTC](https://forums.percona.com/t/problem-while-starting-instance-with-compressed-innodb-tables/2001/1 "2013-02-22T08:17:08Z")

</div>

Hi,

I just noticed a problem with our instances using compressed innodb tables (rows).  
I altered several tables to use innodb compression with a KEY\_BLOCK\_SIZE of 8k.

Now I restarted one of those instance and got a strange behavior while starting the instance.  
It seems that for each compressed table is some work (taking several minutes and producing high write access), so that the server startup takes ~35 minutes on this machine.  
This is absolutely non acceptable as you will agree … so whats going wrong there?

The whole log output is like this:

130221 18:16:45 mysqld\_safe mysqld from pid file /local/mysql/prerelease\_eu/mysqld.pid ended130221 18:17:02 mysqld\_safe Starting mysqld daemon with databases from /local/mysql/prerelease\_eu/data130221 18:17:02 [Note] Plugin ‘FEDERATED’ is disabled.130221 18:17:04 InnoDB: The InnoDB memory heap is disabled130221 18:17:04 InnoDB: Mutexes and rw\_locks use GCC atomic builtins130221 18:17:04 InnoDB: Compressed tables use zlib 1.2.3130221 18:17:04 InnoDB: Using Linux native AIO130221 18:17:04 InnoDB: Initializing buffer pool, size = 6.0G130221 18:17:05 InnoDB: Completed initialization of buffer pool130221 18:17:05 InnoDB: highest supported file format is Barracuda.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.InnoDB: It is compressed .ibd file. need to convert additionaly on buffer pool.InnoDB: pages needs split are …done.InnoDB: waiting the flush batch of the additional conversion.InnoDB: done.130221 18:52:36 InnoDB: Restoring buffer pool pages from ib\_lru\_dump130221 18:52:36 InnoDB: Waiting for the background threads to start130221 18:52:37 Percona XtraDB 1.1.8-rel29.4 started; log sequence number 7252282608140130221 18:52:37 [Note] Event Scheduler: Loaded 0 events130221 18:52:37 [Note] /usr/sbin/mysqld: ready for connections.Version: ‘5.5.29-29.4-log’ socket: ‘/local/mysql/prerelease\_eu/mysql.sock’ port: 3306 Percona Server (GPL), Release 29.4130221 18:52:37 [Note] Event Scheduler: scheduler thread started with id 1130221 18:52:46 InnoDB: Completed reading buffer pool pages (requested: 654261, read: 1173)

Of course I cann add parts of the configuration if this is needed, but at first: Is this a known bug or moreover a known limitation of using compressed tables or are there some parameters which could be configured to avoid this start up problem?

Thanks in advantage for your hints and help!

---

<div class="post-metadata">

**Author:** ![Boemm](https://avatars.discourse-cdn.com/v4/letter/b/e68b1a/32.png) [@Boemm](https://forums.percona.com/u/Boemm)\
**Post date:** [February 22, 2013, 10:57am UTC](https://forums.percona.com/t/problem-while-starting-instance-with-compressed-innodb-tables/2001/2 "2013-02-22T10:57:23Z")

</div>

Ok, a entry in launchpad system brought the solution.  
I configured innodb\_import\_table\_from\_xtrabackup=1 on all our instances which causes the behavior on server start up.  
Disabling this option also solves the above problem.
