You can read binlogs with the mysqlbinlog tool, and produce a stream of logical changes, like a mysqldump backup. The mysqlbinlog has an option --database=dbname so you can extract only changes pertaining to the named database.

Read more about using this option here: http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

Two caveats:

• This assumes that you have a continuous set of binary logs back either to the last full backup or to the last incremental dump.

• It's not really a filter for changes to dbname. It's a filter for all binlog events applied to any database while dbname was selected as the default database. So if you have an event where someone updated dbname2.tablename while dbname was the default, then the dump will include that change to dbname2.

This makes this method unsafe to use this as a per-database incremental backup method, unless you have 100% certainty that no such transactions occurred.

P.S.: Your comments about LSN are a bit incorrect. Mysqldump knows nothing about the LSN, which is a feature of the InnoDB redo log. Mysqldump does examine the binary log position, and can output that position if you use the option --master-data.

You can read binlogs with the mysqlbinlog tool, and produce a stream of logical changes, like a mysqldump backup. The mysqlbinlog has an option --database=dbname so you can extract only changes pertaining to the named database.

Read more about using this option here: http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

Two caveats:

• This assumes that you have a continuous set of binary logs back either to the last full backup or to the last incremental dump.

• It's not really a filter for changes to dbname. It's a filter for all binlog events applied to any database while dbname was selected as the default database. So if you have an event where someone updated dbname2.tablename while dbname was the default, then the dump will include that change to dbname2.

  This makes this method unsafe to use this as a per-database incremental backup method, unless you have 100% certainty that no such transactions occurred.

P.S.: Your comments about LSN are a bit incorrect. Mysqldump knows nothing about the LSN, which is a feature of the InnoDB redo log. Mysqldump does examine the binary log position, and can output that position if you use the option --master-data.

You can read binlogs with the mysqlbinlog tool, and produce a stream of logical changes, like a mysqldump backup. The mysqlbinlog has an option --database=dbname so you can extract only changes pertaining to the named database.

Read more about using this option here: http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

Two caveats:

• This assumes that you have a continuous set of binary logs back either to the last full backup or to the last incremental dump.

• It's not really a filter for changes to dbname. It's a filter for all binlog events applied to any database while dbname was selected as the default database. So if you have an event where someone updated dbname2.tablename while dbname was the default, then the dump will include that event.

This makes this method unsafe to use this as a per-database incremental backup method, unless you have 100% certainty that no such transactions occurred.

P.S.: Your comments about LSN are a bit incorrect. Mysqldump knows nothing about the LSN, which is a feature of the InnoDB redo log. Mysqldump does examine the binary log position, and can output that position if you use the option --master-data.

You can read binlogs with the mysqlbinlog tool, and produce a stream of logical changes, like a mysqldump backup. The mysqlbinlog has an option --database=dbname so you can extract only changes pertaining to the named database.

Read more about using this option here: http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html#option_mysqlbinlog_database

Two caveats:

• This assumes that you have a continuous set of binary logs back either to the last full backup or to the last incremental dump.

• It's not really a filter for changes to dbname. It's a filter for all binlog events applied to any database while dbname was selected as the default database. So if you have an event where someone updated dbname2.tablename while dbname was the default, then the dump will include that change to dbname2.

This makes this method unsafe to use this as a per-database incremental backup method, unless you have 100% certainty that no such transactions occurred.

P.S.: Your comments about LSN are a bit incorrect. Mysqldump knows nothing about the LSN, which is a feature of the InnoDB redo log. Mysqldump does examine the binary log position, and can output that position if you use the option --master-data.