Bug 520534

Summary:	app-office/akonadi-server mysql backend nonfunctional after upgrade to dev-db/mysql-5.5.39
Product:	Gentoo Linux	Reporter:	Andreas K. Hüttel <dilfridge>
Component:	[OLD] KDE	Assignee:	Gentoo KDE team <kde>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://launchpad.net/bugs/1083747
Whiteboard:
Package list:		Runtime testing required:	---

Description Andreas K. Hüttel archtester

2014-08-22 12:21:49 UTC

app-office/akonadi-server mysql backend nonfunctional after upgrade to dev-db/mysql-5.5.39

Yes emerge @preserved-rebuild ran and worked fine.

Here's the mysql.err log:

140822 14:10:29 InnoDB: The InnoDB memory heap is disabled
140822 14:10:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140822 14:10:29 InnoDB: Compressed tables use zlib 1.2.8
140822 14:10:29 InnoDB: Using Linux native AIO
140822 14:10:29 InnoDB: Initializing buffer pool, size = 80.0M
140822 14:10:29 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140822 14:10:29 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
[...]
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
140822 14:12:09 InnoDB: Unable to open the first data file
InnoDB: Error in opening ./ibdata1
140822 14:12:09 InnoDB: Operating system error number 11 in a file operation.
InnoDB: Error number 11 means 'Resource temporarily unavailable'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
140822 14:12:09 InnoDB: Could not open or create data files.
140822 14:12:09 InnoDB: If you tried to add new data files, and it failed here,
140822 14:12:09 InnoDB: you should now edit innodb_data_file_path in my.cnf back
140822 14:12:09 InnoDB: to what it was, and remove the new ibdata files InnoDB created
140822 14:12:09 InnoDB: in this failed attempt. InnoDB only wrote those files full of
140822 14:12:09 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
140822 14:12:09 InnoDB: remove old data files which contain your precious data!
140822 14:12:09 [ERROR] Plugin 'InnoDB' init function returned error.
140822 14:12:09 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140822 14:12:09 [ERROR] Unknown/unsupported storage engine: innodb
140822 14:12:09 [ERROR] Aborting

140822 14:12:09 [Note] /usr/sbin/mysqld: Shutdown complete

I tried running

/usr/sbin/mysqld --defaults-file=/home/huettel/.local/share/akonadi/mysql.conf --datadir=/home/huettel/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-huettel.dhrlVb/mysql.socket &
mysql_upgrade --socket=/tmp/akonadi-huettel.dhrlVb/mysql.socket

which claims that all is OK with the database.
It does not help though.

More debugging to follow...

Comment 1 Andreas K. Hüttel archtester

2014-08-22 12:29:41 UTC

OK here's the secret for Gentoo: 

You MUST run revdep-rebuild.
emerge @preserved-rebuild is NOT enough...

Keeping the bug open until I/someone else writes a blog post.

Comment 2 Felix Leif Keppmann 2014-08-22 12:39:31 UTC

Today I had to fix a related (or the same?) issue with app-office/akonadi-server-1.13.0 and dev-db/mysql-5.5.39 which is related to the Binary Log of MySQL (http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html).

"akonadictl start" threw may errors of type "Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED."...

Akonadi tried to upgrade the database and therefore used transaction level with InnoDB which InnoDB is only able to execute if "row"-based binary logging is enabled. MySQL 5.5 defaults to "statement"-based.

I added
binlog_format=MIXED
to
/etc/mysql/my.cnf
to allow both logging methods.

Afterwards akonadi was able to process all updates and continued working normally.


As I said, the issue may be related but not yours, because i don't have errors in my mysql.err

Comment 3 Felix Leif Keppmann 2014-08-22 12:41:19 UTC

You already found a solution. The "'emerge @preserved-rebuild' is not enough" issue  appears sometimes for me too. I started to use both "emerge @preserved-rebuild" and revdeb-rebuild again.

Comment 4 Andreas K. Hüttel archtester

2014-08-22 15:44:11 UTC

Maybe I should really read those news items instead of just clicking them away...