It seems theoretically possible that table could still dump properly if the corruption were in the indexes, which aren't dumped.
It should not be possible for anything in your configuration to cause MySQL to crash with a Signal 11, a segmentation fault.
I've been staring at this for a while, now, and I haven't come up with answers... just questions (in no particular order):
- have you run memory diagnostics on your server? You mentioned that you "tried to move hardware" but you also mention having not tried a restore of your dump, so I'm not clear exactly what you tried moving. Resist the temptation to think "it can't be that." Test the memory.
- is your system using any swap space at all? Hopefully not -- but if (and only if) it is, then you should reduce the innodb_buffer_pool_size to the point that it isn't ... because there's not really a point in buffering to memory that gets swapped, and the swap partition could be introducing problems. This one is a stretch, but worth eliminating, I think.
- is this a problem that occurred after an upgrade to 5.5.28 or is this a new application or deployment?
- if it's new, have you tried replicating the problem with MySQL 5.6?
- is partitioning involved? That means touching more code.
- are you using a binary distribution of MySQL that you downloaded from Oracle (tar/deb/rpm)? Or is it from Ubuntu (I always use generic tar binaries, so I don't know what the current version of MySQL 5.5 is, in 12.04LTS) or another source? Or compiled from source code?
- are you using any unusual plugins or UDFs?
This could be a bug, but when you hear the sound of hooves, suspect horses before zebras (at least where I come from).
update (from comments):
"Another" memory bug?
Checking the memory would be the first thing I would try, for sure.
The snapshots should be getting you a reliable backup, I agree, but if there's any kind of binary wierdness going on in your files, it would be perfectly replicated. It will take some time, but restoring to a fresh system using mysqldump files would be a better test, since all of the table structures would all be absolutely rebuilt from scratch. Since the table structures seem to be valid, it may be unlikely that this will change anything, but it feels like you're kind of at the point where every possibility needs to be pinned down... clearly, what you're seeing should not be happening.
For a new test system, though, I would install the server using the "Linux - Generic 2.6 (x86, 64-bit), Compressed TAR Archive" package from the download site. Download the tarball, verify it's md5 checksum, then tar xvzf it into /usr/local and symlink the resulting directory to /usr/local/mysql. (I think Ubuntu still puts it in /var/lib/mysql, so you can probably do this even without removing the distro version, as long as you don't have the other copy running). Then move the "data" directory from inside /usr/local/mysql to whatever partition it needs to live on (if different), and symlink it back into /usr/local/mysql/data. Put your config file at /usr/local/mysql/my.cnf and pass that as the first option ... using --defaults-file=/usr/local/mysql/my.cnf when using the install scripts and when starting the server -- this will cause any other my.cnf's (such as those in /etc) to not be read.
The rest of the setup is pretty straightforward. It's more work, but it completely eliminates the "black box" of using the package manager. The real motivation here, though, is that the disto packages may have been compiled from source, and the resulting binaries could have slight variations from the "official" Oracle binaries.
OBSERVATION #1
When committing to use InnoDB, you also need to commit to tuning for multiple cores.
OBSERVATION #2
I see you have innodb_thread_concurrency = 8
. If you set innodb_thread_concurrency to 0 (which is the default), you will have infinite concurrency. That let's the InnoDB storage engine decide how to many threads it feels it needs and can handle.
OBSERVATION #3
Your DB Server has 12GB of RAM. Your InnoDB Buffer Pool is bigger than half the RAM. You need to partition the Buffer Pool by setting innodb_buffer_pool_instances to 2. In conjunction with this, you need to run numactl --interleave=all
(Not applicable to VMs).
OBSERVATION #4
I see you have innodb_file_format = Barracuda
. I wish you can go back to innodb_file_format = Antelope
. Why go back to uncompressed? It tends to bloat the InnoDB Buffer Pool because compressed and uncompressed data and index pages coexist in the Buffer Pool. I just wrote about this : See my post innodb_file_format Barracuda
EPILOGUE
Here are some of my past posts on tuning InnoDB
Give it a Try !!!
Best Answer
Back on March 15, 2012, I answered this question : MySql recommended hardware.
In my answer, I mentioned a client who is still in my employer's web hosting company to this very day. They are currently running 3 DB Servers in Circular Replication. Each DB Server has:
I have them set with
Bottom line: You got the cores, and 128G RAM? What are you waiting for ? Crank it up and have some fun. My client has been all but flabbergasted with these settings against that hardware since March 2011. You will be blown away !!!
CAVEAT
All kidding aside, you should be careful when working with VMs(VMWare, AWS, any other cloud-based MySQL Instances) or commodity hardware. However, with that much firepower in bare metal, by all means, you should exploit those settings because any version of MySQL before MySQL 5.5 works with single threaded InnoDB. If you have MySQL 5.1, the InnoDB plugin (starting from MySQL 5.1.38) would have to be installed and then set. All Percona Server 5.1 binaries already have these in place. Since you have MySQL 5.5, these settings are natively installed and have been tested in many respects. You just have to take responsibility for tuning the new InnoDB Settings.
Please see my other posts on setting InnoDB's new settings:
Jan 11, 2012
: 16 Cores 12 GB RAM server MySql Configuration - my.cnfOct 05, 2011
: Query runs a long time in some newer MySQL versionsSep 20, 2011
: Multi cores and MySQL PerformanceSep 12, 2011
: Possible to make MySQL use more than one core?May 26, 2011
: About single threaded versus multithreaded databases performanceNov 24, 2011
: Why mysql 5.5 slower than 5.1 (linux,using mysqlslap)UPDATE 2013-01-18 21:52 EDT
You need to take the bull by the horns and setup some benchmarks. Let's go back historically. innodb_read_io_threads and innodb_writes_io_threads did not come with MySQL 5.0 or 5.1. Someone created a plugin and made it available in MySQL 5.1.38. The defaults were 4. I also notice that Percona Server implemented these things early in MySQL 5.1 with defaults of 8. Most people who use Percona Server out-of-the-box swear by it and often say that it is better than MySQL. However, this comparison is usually done with tweeking InnoDB. So, of course, Percona Server, with double the number of threads, would be better.
Given this conservative way to get better performance (upgrading to Percona), you will never really know how good, bad, or ugly InnoDB will go unless you tune for it. Keep in mind my post from Nov 24, 2011. Multiple versions of MySQL were benchmarked and, in some cases, InnoDB under MySQL 4.1 outperformed 5.x in a single-threaded environment. That's given the same level playing field.
To tip the scales in your favor, you must tune InnoDB. Rather than give you any single definitive Pick-This-Pick-That guide, you need to read about the settings InnoDB ghas been given to make multiple cores come alive. Not every environment is like my client's dual hexacore servers or your dual hexadecacore.
If I had to give you a good starting point, it would have the be
mysqlperformanceblog.com
. Everything performance-centric about mysql is there for you to read, select, and benchmark.