holland-coredev team mailing list archive

[Andrew Garner <766681@xxxxxxxxxxxxxxxxxx>]

I think this would be a better fit for some front-end script that assist
with the restore (maybe a holland restore ... command).  I don't think
we should be messing with mysqldump's standard output at backup time at
any rate.

For an example of how I might envision a restore script working you can
see the holland_restore experiment for mysqldump I have here:

https://github.com/abg/holland_restore

I just implemented this basic idea:

$ mysqlrestore  --start-slave-early < sakila.binlog.sql > sakila.binlog.io_thread.sql
…
$ diff -u sakila.binlog.sql sakila.binlog.io_thread.sql 
--- sakila.binlog.sql    2011-04-19 21:31:59.000000000 -0400
+++ sakila.binlog.io_thread.sql    2011-04-19 21:41:10.000000000 -0400
@@ -20,6 +20,7 @@
--

CHANGE MASTER TO MASTER_LOG_FILE='bin-log.000001', MASTER_LOG_POS=106;
+START SLAVE IO_THREAD;

--
-- Table structure for table `actor`
$

-- 
You received this bug notification because you are a member of Holland
Build, which is subscribed to holland-backup.
https://bugs.launchpad.net/bugs/766681

Title:
  Start slave IO_THREAD in mysqldump output

Status in Holland Backup Framework:
  New

Bug description:
  To immediately start queuing the master logs during a slave
  initialization from a master-data dump, it would be nice to optionally
  inject START SLAVE IO_THREAD after the CHANGE MASTER TO
  MASTER_LOG_FILE ...

  This would presumably fail if the slave had not first had CHANGE
  MASTER TO MASTER_HOST, MASTER_USER, MASTER_PASSWORD but perhaps that
  is a feature since you then avoid having to manually extract the
  CHANGE from the dump file and worse forget to do so starting at the
  master's first available.