db1046 (m4 master, behind dbproxy1004) mysqld aborted:
2015-07-03 23:16:27 7f5a0fbff700 InnoDB: Assertion failure in thread 140024788023040 in file buf0flu.cc line 939 InnoDB: Failing assertion: page_zip_verify_checksum(frame, zip_size) InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 150703 23:16:27 [ERROR] mysqld got signal 6 ;
- DBA: Figure it out. Compression related? But InnoDB compressed tables should have been replaced with TokuDB...
- Analytics: Check out eventlogging consumer with analytics. The haproxy on dbproxy1004 redirected traffic to db1047, bu did the consumer like that? Do we (a DBA) need to sync events back to the master, or just do a backfill?