<bytee> serg: we do have bitmap changed page tracking in XtraDB
<bytee> serg: implemented MDEV-7472 makes sense so its user exposed
<bytee> esp when a feature is used by innobackupex
<bytee> see: FLUSH CHANGED_PAGE_BITMAPS - this statement can be used for synchronous bitmap write for immediate catch-up with the log checkpoint. This is used by innobackupex to make sure that XtraBackup indeed has all the required data it needs.

Any chance of this being implemented quicker than 10.2?

Percona's latest backup release now means incremental backups are not possible on MariaDB:

https://github.com/percona/percona-xtrabackup/pull/25/files

Their check returns true on MariaDB:

SELECT COUNT(*) FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'INNODB_CHANGED_PAGES';

Resulting in:

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.

During an incremental backup.

This is unlikely. 10.1 is already beta and we generally don't add new statements after alpha.

We could add

FLUSH NO_WRITE_TO_BINLOG INNODB_CHANGED_PAGES

statement though, because it doesn't change the parser — it's an internal change inside XtraDB (adding FLUSH support to the INFORMATION_SCHEMA.INNODB_CHANGED_PAGES table).

But I am not sure it'll help xtrabackup.

Hmm. In fact, we could add INFORMATION_SCHEMA.CHANGED_PAGE_BITMAP table to XtraDB — and then FLUSH will work. Which is a pretty silly solution (dummy I_S table with no content), but it might work.

Adding just IS table CHANGED_PAGE_BITMAPS is not enough

FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS;

ERROR 42000: 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

select * from information_schema.changed_page_bitmaps;

dummy

0

See https://mariadb.com/kb/en/mariadb/information-schema-plugins-show-and-flush-statements/

For I_S table to support FLUSH, it must implement a reset_table callback.

commit b7ff2f1b59c42171ff50fc682e8f723f0713d688
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Tue Jun 23 14:36:24 2015 +0300

MDEV-7472: Implementation of user statements for handling the xtradb changed page bitmaps

Introduce a new dummy INFORMATION_SCHEMA.CHANGED_PAGE_BITMAPS table to XtraDB
with reset_table callback to allow FLUSH NO_WRITE_TO_BINLOG CHANGED_PAGE_BITMAPS
to be called from innobackupex.

Hi,

Sorry to re-open this, I see that the following feature has been implemented:

• FLUSH CHANGED_PAGE_BITMAPS
  But what about the 2 following:
• RESET CHANGED_PAGE_BITMAPS
• PURGE CHANGED_PAGE_BITMAPS BEFORE <lsn>
  ?
  I am especially interested in the last one, as it is used generally in post backup scripts to safely remove unneeded xdb files.

Regards,
Joffrey

As Joffrey, I'd also like ask what about RESET CHANGED_PAGE_BITMAPS and PURGE
CHANGED_PAGE_BITMAPS BEFORE. It would really help us with the incremental backups in MariaDB.

Hi,

to avoid polluting this task, I have created https://jira.mariadb.org/browse/MDEV-10798
You are welcome to follow/vote on it.

Regards,
Joffrey