Piping ALTER TABLE commands throuh mysql client corrupts INNODB tables

Asked by Larry Irwin

Will re-submit with info on how to duplicate...
(did not mean to submit until I had it all in the report, but I did, somehow...)

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: mysql-server-5.5 5.5.40-0ubuntu0.14.04.1
ProcVersionSignature: Ubuntu 3.13.0-34.60-generic 3.13.11.4
Uname: Linux 3.13.0-34-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
Date: Wed Dec 31 15:53:57 2014
InstallationDate: Installed on 2014-08-18 (135 days ago)
InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3)
Logs.var.log.daemon.log:

Logs.var.log.mysql.error.log:
MySQLConf.etc.mysql.conf.d..keepme:
MySQLConf.etc.mysql.conf.d.mysqld.safe.syslog.cnf:
 [mysqld_safe]
 # syslog
MySQLVarLibDirListing: False
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: mysql-5.5
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.mysql.conf.d.mysqld.safe.syslog.cnf: [modified]
mtime.conffile..etc.mysql.conf.d.mysqld.safe.syslog.cnf: 2014-08-18T17:14:53.949242

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu mysql-5.5 Edit question
Assignee:
No assignee Edit question
Solved by:
Larry Irwin
Solved:
Last query:
Last reply:
Revision history for this message
Larry Irwin (lrirwin) said :
#1

Having issue with 5.5 when scripting updates to table structures.
In many cases, adding a new column will result in the xxx.ibd file left in place and three #sqlxxxxx files.
And it is too much trouble to go through the innodb recovery process - so I re-load the database(s).
I will create repeatable script and submit.
It does not occur on mysql 5.1 nor 5.0 on any of the 70+ servers I work on.
Only on version 5.5 am I having this problem - and only when scripted to cycle through multiple database instances updating all their structures.

Revision history for this message
actionparsnip (andrew-woodhead666) said :
#2

I suggest you report a bug

Revision history for this message
Larry Irwin (lrirwin) said :
#3

I was able to work around the problem with mysql-5.5 by removing all mysql-5.5 packages from the system and installing the binary distribution of mysql-5.6 from the dev.mysql site.

The only issue encountered with this solution was the removal of the mailutils package.
The solution for that was to re-install mailustils and then rename the /etc/mysql folder installed due to the dependency tree where libmysqlclient18 is dependent on mysql-common.
I think that relationship should be a "recommends" vs. a dependency, since a site may need the mailutils package, but have their own MySQL installation - with its own my.cnf setup.
(libmysqlclient18 does not -need- mysql-common to function...)

This also worked on Debian 7. (though on Debian 7, removal of mysql-5.5 did not remove the mailutils package... which further supports the "recommends" idea.)