Bug #73521 Installation failure because ibdata1 of a different size
Submitted: 10 Aug 2014 10:25 Modified: 12 Sep 2014 3:39
Reporter: Daniël van Eeden (OCA) Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Package Repos Severity:S3 (Non-critical)
Version:5.6 OS:Linux (Ubuntu 14.04.1 (trusty))
Assigned to: Akhil Mohan CPU Architecture:Any

[10 Aug 2014 10:25] Daniël van Eeden
Description:
I tried to install mysql-community-server 5.6.20-1ubuntu14.04 on Ubuntu 14.04.1.

====================================================================
$ sudo apt-get install mysql-community-server 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  mysql-community-server
0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 13.8 MB of archives.
After this operation, 89.0 MB of additional disk space will be used.
Get:1 http://repo.mysql.com/apt/ubuntu/ trusty/mysql-5.6 mysql-community-server amd64 5.6.20-1ubuntu14.04 [13.8 MB]
Fetched 13.8 MB in 3s (4,261 kB/s)                 
Preconfiguring packages ...
Selecting previously unselected package mysql-community-server.
(Reading database ... 461119 files and directories currently installed.)
Preparing to unpack .../mysql-community-server_5.6.20-1ubuntu14.04_amd64.deb ...
Unpacking mysql-community-server (5.6.20-1ubuntu14.04) ...
Processing triggers for man-db (2.6.7.1-1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up mysql-community-server (5.6.20-1ubuntu14.04) ...
2014-08-10 12:05:13 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
2014-08-10 12:05:13 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
dpkg: error processing package mysql-community-server (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for ureadahead (0.100.0-16) ...
Errors were encountered while processing:
 mysql-community-server
E: Sub-process /usr/bin/dpkg returned an error code (1)
====================================================================

From the errorlog:
====================================================================
2014-08-10 12:05:14 21208 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
2014-08-10 12:05:14 21208 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2014-08-10 12:05:14 21208 [ERROR] Plugin 'InnoDB' init function returned error.
2014-08-10 12:05:14 21208 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2014-08-10 12:05:14 21208 [ERROR] Unknown/unsupported storage engine: InnoDB
2014-08-10 12:05:14 21208 [ERROR] Aborting
====================================================================

I couldn't find any innodb settings in /etc/mysql/my.cnf or /etc/mysql/my.cnf.dpkg-dist

As /var/lib/mysql/debian-5.1.flag exists the datadir probably belongs to a 5.1 instance.

I did not have a working/running mysql-server before I installed mysql-community-server. I probably had a working server in the past. I did use mysql-common etc. so that might have changed the config file(s) 

How to repeat:
Try to install mysql-community-server from the repo with an old 5.1 datadir.

Suggested fix:
Ask if /var/lib/mysql should be wiped during the installation
Or generate/validate/correct innodb_data_file_path during installation
[10 Aug 2014 10:27] Daniël van Eeden
$ find /etc/my* -ls
2098856    4 drwxr-xr-x   3 root     root         4096 Jul 31 21:05 /etc/mysql
2099919    4 drwxr-xr-x   2 root     root         4096 Apr 24 07:30 /etc/mysql/conf.d
2102211    0 -rw-r--r--   1 root     root            0 Feb 20 04:36 /etc/mysql/conf.d/.keepme
2097755    4 -rw-r--r--   1 root     root         3625 Aug 23  2011 /etc/mysql/my.cnf
2098028    4 -rw-r--r--   1 root     root         1820 May 23 15:45 /etc/mysql/my.cnf.dpkg-dist
2100092    4 -rw-------   1 root     root          333 Apr 15  2011 /etc/mysql/debian.cnf
[10 Aug 2014 10:30] Daniël van Eeden
$ dpkg -S /etc/mysql/my.cnf
mysql-common: /etc/mysql/my.cnf

$ egrep -v '^($|#)' /etc/mysql/my.cnf
[mysqld1]
tmpdir=/tmp/mysqld1/tmp
datadir=/tmp/mysld1/data
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0
[mysqld]
user		= mysql
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
skip-external-locking
bind-address		= 127.0.0.1
key_buffer		= 16M
max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 8
myisam-recover         = BACKUP
query_cache_limit	= 1M
query_cache_size        = 16M
log_error                = /var/log/mysql/error.log
expire_logs_days	= 10
max_binlog_size         = 100M
[mysqldump]
quick
quote-names
max_allowed_packet	= 16M
[mysql]
[isamchk]
key_buffer		= 16M
!includedir /etc/mysql/conf.d/

$ egrep -v '^($|#)' /etc/mysql/my.cnf.dpkg-dist 
[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock
[mysqld_safe]
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
nice		= 0
[mysqld]
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
lc-messages-dir	= /usr/share/mysql
explicit_defaults_for_timestamp
bind-address	= 127.0.0.1
log-error	= /var/log/mysql/error.log
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
symbolic-links=0
!includedir /etc/mysql/conf.d/
[10 Aug 2014 10:31] Daniël van Eeden
$ sudo ls -l /var/lib/mysql/
total 20492
-rw-rw---- 1 mysql mysql     1855 Apr 15  2011 daniel-thinkpad.log
-rw-r--r-- 1 root  root         0 Apr 15  2011 debian-5.1.flag
-rw-rw---- 1 mysql mysql 10485760 Apr 17  2011 ibdata1
-rw-rw---- 1 mysql mysql  5242880 Apr 17  2011 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Apr 15  2011 ib_logfile1
drwx------ 2 mysql root      4096 Apr 15  2011 mysql
-rw-rw---- 1 root  root         6 Apr 15  2011 mysql_upgrade_info
[10 Aug 2014 10:32] Daniël van Eeden
$ sudo cat /var/lib/mysql/mysql_upgrade_info; echo
5.1.49
[11 Aug 2014 8:01] Akhil Mohan
Hi Daniël,

Appreciate your effort in using our newly released APT repos and sending us such detailed information with server logs. It really makes it easy to understand your system setup and related problems.

At this moment, it is not possible for 5.6 server to correctly upgrade 5.1 data dir. Moreover, the native Ubuntu repos and MySQL APT repos do not provide 5.1 server on Ubuntu 14.04 reducing the required motivation to support an upgrade scenario from 5.1 data dir.

If you can give us an idea on how you got 5.1 installed on Ubuntu 14.04 through an authentic software source then we can add that to our future scope of enhancements.

For now, in case you have 5.1 server running then to upgrade you have two options:

1) Perform an an intermediate upgrade to 5.5 first from native Ubuntu repo then install 5.6 through MySQL APT repos.

2) Take data backup using mysqldump and then remove the 5.1 installation completely including the data dir. Now, you can install 5.6 from MySQL APT Repos and then import your data.

Unfortunately, both the options have manual steps so please choose the one that best suits your requirements.

Let us know in case you have further doubts related to this upgrade scenario.

Regards,
Akhil
[11 Aug 2014 9:36] Daniël van Eeden
> If you can give us an idea on how you got 5.1 installed on Ubuntu 14.04 through 
> an authentic software source then we can add that to our future scope of 
> enhancements.

This is what probably happened:
1. I installed MySQL 5.1 on Ubuntu 10.04 LTS
2. Then I removed MySQL 5.1 without removing the datadir
3. Then I upgraded from 10.04 LTS to 12.04 LTS
4. Then I upgraded from 12.04 LTS to 14.04 LTS
5. Then I tried to install mysql-comminity-server
[11 Aug 2014 11:29] Akhil Mohan
Hi Daniël,

Thanks for getting back to us. In this case, since you have the data dir without any MySQL package that owns it then a warning message should appear asking to take backup of 'existing and unowned' data dir.

In any case, since we do not recommend to officially upgrade from 5.1 to 5.6 directly, so assumption is that users would upgrade from 5.5+. This is the reason why the package failed trying to upgrade 5.1 data dir but that should not happen before giving a warning in your particular case.

Regards,
Akhil
[17 Oct 2014 14:56] Stein Somers
I have the same error on a CentOS 6 box, which according to my knowledge corresponds to RHEL 6. It was installed a few months ago with minimal tweaks, and "yum update"d, which meant it had version 5.1.73-3.el6_5. http://dba.stackexchange.com/questions/57413/what-is-the-last-mysql-version-supported-in-r... confirms that 5.1 is the standard there.

After playing around with the server with that standard configuration, I wanted Connector/Python and was lead to http://dev.mysql.com/downloads/repo/yum/ and slavishly picked up the package for RHEL 6. It seems to me this is pretty likely to happen.