Comment 7 for bug 792407

Henrik,

To be honest, we did not put much thought into this option,
it was implemented by customer request, but we did not think
to make it default.

On Mon, Jun 6, 2011 at 11:48 PM, Henrik Ingo <email address hidden> wrote:
> Thanks Vadim
>
> If you're looking into it, then I think this is a good moment to ask:
> Why isn't --safe-slave-backup on by default?
>
> --
> You received this bug notification because you are a member of Percona
> developers, which is the registrant for Percona XtraBackup.
> https://bugs.launchpad.net/bugs/792407
>
> Title:
>  Provide alternative to --no-lock that stops slave but does not lock
>  tables
>
> Status in Percona XtraBackup:
>  Triaged
>
> Bug description:
>  Hi
>
>  I've seen some backups spuriously fail with an error message:
>  innobackupex: Error: Connection to mysql child process (pid=15332) timedout. (Time limit of 900 seconds exceeded. You may adjust time limit by editing the value of parameter "$mysql_response_timeout" in this script.) while waiting for reply to MySQL request: 'FLUSH TABLES WITH READ LOCK;' at /usr/bin/innobackupex line 336.
>
>  This is in the last phase where xtrabackup has copied all InnoDB table
>  spaces, and is suspended so that innobackupex should lock all tables
>  and backup MyISAM tables and other non-InnoDB tables, .frm files and
>  such. It seems taking a global lock fails simply because there are
>  updates and inserts happening during this time.
>
>  There's the --no-lock option that would allow innobackupex to proceed
>  without trying to lock. This is safe if you are not writing to any
>  MyISAM (or other) tables, and not doing any DDL (.frm files). These
>  assumptions hold for us and indeed, taking a lock on all tables is a
>  bit hard handed, when 99% of the backup is already done in online
>  fashion by xtrabackup.
>
>  However, the problem is that we use replication, so the replication
>  state will be inconsistent. In fact, with --no-lock the slave_info and
>  binlog_info files are not written out at all (those are done inside
>  mysql_lockall().
>
>  It would be useful for us to have a new option (like --no-lock-but-
>  stop-slave) that would not lock tables, but would still do STOP SLAVE
>  SQL_THREAD where it currently does mysql_lockall(). And it should then
>  of course proceed to write slave_info and binlog_info and other files
>  as usual.
>
>  Relevant code in innobackupex are lines 370-... and 1180-1210.
>
>  Would this work and be safe?
>

--
Vadim Tkachenko, CTO, Percona Inc.
Phone +1-888-401-3403,  Skype: vadimtk153
Schedule meeting: http://tungle.me/VadimTkachenko

Flat-rate 24x7 support for MySQL <http://percona.com/mysql-support>