Bug #62011 page_zip_reorganize() should be logged and replayed at recovery
Submitted: 28 Jul 2011 6:33 Modified: 27 Mar 2012 10:41
Reporter: Yasufumi Kinoshita Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: InnoDB Plugin storage engine Severity:S2 (Serious)
Version:5.1 5.5 OS:Any
Assigned to: CPU Architecture:Any

[28 Jul 2011 6:33] Yasufumi Kinoshita
Description:
Currently, page_zip_reorganize() is not logged at all,
but just logged as MLOG_ZIP_PAGE_COMPRESS.
MLOG_ZIP_PAGE_COMPRESS is parsed only as sanity check at recovery.

However, page_zip_reorganize() is important operation to reserve room for additional deflation.
If page_zip_reorganize() is not replayed as same as the did in the buffer pool, the following operations in the transaction log might fail to replay because of space shortage of the compressed page. (e.g. update in place, etc...)

How to repeat:
We meet fail to recover compressed table space sometimes.
It may be one of the factors to cause the problem.

Suggested fix:
To implement logging and replaying at recovery
page_zip_reorganize() operation
[2 Aug 2011 22:53] Nizameddin Ordulu
Two things:

1- I don't think MLOG_ZIP_PAGE_COMPRESS is parsed only as sanity check at recovery. From log0recv.c:
/**********************************************************************//**     Parses a log record of compressing an index page.                                                                           
@return end of log record or NULL */
UNIV_INTERN
byte*
page_zip_parse_compress(
/*====================*/
  byte*   ptr,  /*!< in: buffer */
  byte*   end_ptr,/*!< in: buffer end */
  page_t*   page, /*!< out: uncompressed page */
  page_zip_des_t* page_zip)/*!< out: compressed page */

the argument page_t* page is the output of parsing MLOG_ZIP_PAGE_COMPRESS. Compressed page image is read from the log record and decompressed into page_t* page. Older uncompressed version is discarded.

2- Because the compressed image is saved after reorganization, performing reorganization during recovery is not necessary. The compressed page image is already reorganized.
[27 Mar 2012 10:41] Marko Mäkelä
Nizameddin Ordulu is right.

This bug alleges that InnoDB is writing too little redo log for compressed pages. Actually, you should be alleging the opposite. There is some room for avoiding page recompression, and we could write less redo log if we can be sure that zlib is deterministic across restarts (that is, the same page contents will always compress in the same way). One scenario where this is not necessarily true is when zlib is updated, and the DBA forgets to do a clean InnoDB shutdown before the zlib update.