Not the answer you need?
Register and ask your own question!

Error on FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS after update to 2.2.10

mbetelmbetel EntrantCurrent User Role Beginner
I use xtrabackup on a Mariadb 10.0.15 running on Centos 6.7
It seems something changed in innobackupex. Yesterdays backup using the previous version 2.2.9 had no problems.
Any hints on how to solve this?

Thanks, Michiel

I include the log here:

innobackupex: Using server version 10.0.15-MariaDB-log

innobackupex: Created backup directory /var/backups/mysql/incr/2015-04-01_03-21-01/2015-04-02_03-21-01

150402 03:21:01 innobackupex: Starting ibbackup with command: xtrabackup --defaults-group="mysqld" --backup --suspend-at-end --target-dir=/var/backups/mys
ql/incr/2015-04-01_03-21-01/2015-04-02_03-21-01 --innodb_data_file_path="ibdata1:12M:autoextend" --tmpdir=/mydata/data --compress --compress-threads=4 --tab
les='.*[.].*' --extra-lsndir='/mydata/data' --incremental-basedir='/var/backups/mysql/base/2015-04-01_03-21-01' --suspend-at-start --parallel=4
innobackupex: Waiting for ibbackup (pid=29526) to suspend
innobackupex: Suspend file '/var/backups/mysql/incr/2015-04-01_03-21-01/2015-04-02_03-21-01/xtrabackup_suspended_1'

xtrabackup version 2.2.10 based on MySQL server 5.6.22 Linux (x86_64) (revision id: )
incremental backup from 2555712792976 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /mydata/data
xtrabackup: open files limit requested 65535, set to 16384
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 536870912
xtrabackup: using O_DIRECT
>> log scanned up to (2560735523319)
xtrabackup: Generating a list of tablespaces
xtrabackup: Creating suspend file '/var/backups/mysql/incr/2015-04-01_03-21-01/2015-04-02_03-21-01/xtrabackup_suspended_1' with pid '29526'

150402 03:21:02 innobackupex: Continuing after ibbackup has suspended
DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'CHANGED_PAGE_BITMAPS' at line 1 at /usr/bin/innobackupex line 3044.
innobackupex: got a fatal error with the following stacktrace: at /usr/bin/innobackupex line 3047
main::mysql_query('HASH(0x24ec2f8)', 'FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS') called at /usr/bin/innobackupex line 1970
main::backup() called at /usr/bin/innobackupex line 1601
innobackupex: Error:
Error executing 'FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS': DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'CHANGED_PAGE_BITMAPS' at line 1 at /usr/bin/innobackupex line 3044.
150402 03:21:02 innobackupex: Waiting for ibbackup (pid=29526) to finish

Comments

  • mbetelmbetel Entrant Current User Role Beginner
    looking further, it looks like MariaDB does not support the statement https://mariadb.atlassian.net/browse/MDEV-7472) but the statement setting $have_changed_page_bitmaps on line 4984 of innodbex ('SELECT COUNT(*) FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'INNODB_CHANGED_PAGES') returns 1
    thus making the if in #1966 true. Removing the 'CHANGED_PAGE_BITMAPS' from the FLUSH in #1970 makes my backup run agian.
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.