Flush logs and lock tables order

Bug #1514927 reported by IB Development Team
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mylvmbackup
New
Undecided
Unassigned

Bug Description

Hi,

In

http://bazaar.launchpad.net/~lenzgr/mylvmbackup/trunk/view/head:/mylvmbackup.pl.in

flushing binary log is done in "preflush" before locking tables "flush_tables":

  run_hook ("preflush");
  flush_tables($dbh) unless ($skip_flush_tables == 1);

  create_posfile($dbh);

  run_hook ("presnapshot");
  $snapshot_created= create_lvm_snapshot();

Why not to flush logs ("preflush") after tables are locked ("flush_tables") and have posfile to point to the beginning of next binlog file? We can see this (correct?) order on

http://dba.stackexchange.com/questions/116816/flush-tables-with-read-lock-not-working
http://www.daork.net/archives/4

Now it is possible to have some changes recorded in new binlog file between preflush and flush_tables which probably is less elegant/problematic?

One more thing; in

http://bazaar.launchpad.net/~lenzgr/mylvmbackup/trunk/view/head:/man/mylvmbackup.pod

there is

"
If you use InnoDB tables exclusively, you may also want to consider to include
the option I<--skip_flush_tables>, to avoid the probably time-consuming and in
this case unnecessary flushing of buffers.
"

but using this option does not stop database InnoDB write activity probably and binlog may change between pos file creation and lvm snap which may be a problem?

Please verify and fix.

Regards,
Pawel

IB Development Team
https://dev.ib.pl/

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.