> In one extreme instance, having a few terabytes of data > across several instances (on distinct hosts), I was required > to do a full-refactoring data migration with an absolute > limitation on allowable downtime. > Among the technique which I used (and I can't take credit for this > one) was to use rsync on the live server for innodb files > (this phase took a very long time, but did not interfere with > operations). The result of this phase was, as you would > expect, a set a seriously broken files which were notheless > very similar to the correct files. > When that phase was complete, I shut the server down and did > another rsync. It required perhaps a minute or 2, but the > result was 100% clean innodb data files which satisfied my > downtime limitations. > > FLUSH TABLES WITH READ LOCK might suffice if all > transactions are completed/rolled-back but I would stil > advise that you scan SHOW ENGINE INNODB STATUS but I would > carefully experiment with that. >
You just described almost the exact procedure that I described at the beginning of this thread, except I use MyISAM so my question was whether the same technique could work with InnoDB. It sounds like it very well could if combined with SHOW ENGINE INNODB STATUS. I will definitely test it to be sure. > As for maat-kit, don't let the disclaimers discourage you. > If you read the disclaimers carefully on any product (at > least those released with the benefit(?) of legal advice), > you would have a hard time trusting any of it with your > enterprise. The maat-kit team (and Baron Schwartz in > particular) and quite simply the *best* MySQL engineering > team out there, with the possible exception of the vendor. I > would not hesitate to trust them with my data. > I will definitely look at it again. Thanks. --Eric Disclaimer - January 28, 2011 This email and any files transmitted with it are confidential and intended solely for Michael Dykman,mysql@lists.mysql.com,Shawn Green (MySQL). If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physicians' Managed Care or Physician Select Management. Warning: Although Physicians' Managed Care or Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. This disclaimer was added by Policy Patrol: http://www.policypatrol.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
