innodb_fast_checksum not recognized by PS 5.6 but it's in backup-my.cnf

[Kenny Gryp]

[root@ip-10-10-10-165 backups]# cat xtrabackup_info
uuid = 2d7a6d7f-3e6d-11e4-aed2-0a8c4e06d5ca
name =
tool_name = innobackupex
tool_command = . --no-lock --stream=tar
tool_version = 1.5.1-xtrabackup
ibbackup_version = xtrabackup version 2.2.3 based on MySQL server 5.6.17 Linux (x86_64) (revision id: )
server_version = 5.6.20-68.0-log
start_time = 2014-09-17 13:15:48
end_time = 2014-09-17 13:18:56
lock_time = 0
binlog_pos = filename 'mysqld-bin.000004', position 431
innodb_from_lsn = 0
innodb_to_lsn = 7277989941
partial = N
incremental = N
format = tar
compact = N
compressed = N
encrypted = N

[root@ip-10-10-10-165 backups]# cat backup-my.cnf
# This MySQL options file was generated by innobackupex.

# The MySQL server
[mysqld]
innodb_checksum_algorithm=innodb
innodb_log_checksum_algorithm=innodb
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=50331648
innodb_fast_checksum=0
innodb_page_size=16384
innodb_log_block_size=512
innodb_undo_tablespaces=0

If we then use the backup-my.cnf settings in the my.cnf on the 'slave', mysql won't start::

2014-09-17 13:39:31 10737 [ERROR] mysqld: unknown variable 'innodb_fast_checksum=0'
2014-09-17 13:39:31 10737 [ERROR] Aborting

[Hrvoje Matijakovic (hrvojem)]

From the docs: http://www.percona.com/doc/percona-xtrabackup/2.2/xtrabackup-files.html

- backup-my.cnf

This file contains information to start the mini instance of InnoDB during the --apply-log. This is NOT a backup of original my.cnf. The InnoDB configuration is read from the file backup-my.cnf created by innobackupex when the backup was made. innobackupex --apply-log uses InnoDB configuration from backup-my.cnf by default, or from innobackupex --defaults-file, if specified. InnoDB configuration in this context means server variables that affect data format, i.e. innodb_page_size, innodb_log_block_size, etc. Location-related variables, like innodb_log_group_home_dir or innodb_data_file_path are always ignored by innobackupex --apply-log, so preparing a backup always works with data files from the backup directory, rather than any external ones.

[Kenny Gryp (gryp)]

Thanks for the explanation Hrvoje.

As is well known, In older MySQL versions (<5.6) you had to copy the innodb_log_file_size from the backup-my.cnf (or from the production server my.cnf) or MySQL wouldn't start properly (as the log file size is fixed).
Many customers (where this request originated from) actually took the value from the backup-my.cnf (including myself).

Maybe the name backup-my.cnf is a bit confusing.

Or maybe a separate feature request should be opened to copy the whole my.cnf to the backup directory as well. I'll leave that up to others to decide.

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXB-1298