Hey, The perl script that does the backup issues a SLAVE STOP just before it starts dumping. It also grabs SHOW SLAVE STATUS, which has a bunch of file positions and I'm pretty sure it's everything that is in the master.info file.
The backup I'd be pulling is going to be at least a day old, so it will be out of sync and reseting the master will not help. Thanks. On Fri, 8 Oct 2004 13:24:00 -0400, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Gary, > > We go through the process of removing the slave DB and restoring from > backup on a fairly regular basis (due to testing new functionality of our > app). My first question would be about your backups - how are you doing > them? > > If you are doing a filesystem backup (taring the entire mysql data > directory and replication files, for instance) then your master info and > relay-log will have the information on where the to start the replication > from the master. This is what we are doing. > > I'm not 100% certain about using a mysqldump type program, but I suspect > that you would need to reset the master logs after the backup to tell the > slave to basically start from line 1. I dont know how you would ensure that > the master would reset at the very last command that was backed up on the > slave, perhaps someone using this type of slave/backup scenario could share > some knowledge on the correct procedure. > > > Regards, > > Scott Tanner > Systems Administrator > Rowe/AMi > > > > > "Gary Richardson" <[EMAIL PROTECTED]> > > 10/08/2004 01:01 PM > Please respond to Gary Richardson > > To: [EMAIL PROTECTED] > cc: > Subject: Restarting Replication from Backup > > > > > Hey guys, > > I'm running a master/slave setup with v4.0.20. There are a hand full > of databases being replicated. For backups, we stop replication on the > slave and pull a text dump using mysqldump. I also record a 'SHOW > SLAVE STATUS' from the time of the backup. > > My replica server crashed last night. It looks like it had something > to do with the disk cache as the replica was trying to replay already > committed transactions (lots of duplicate record errors). > > After running an integritty check on the servers, the row counts are > out of sync for far more large tables than I care to manually fix. I'm > thinking of: > > 1) deleting all the data on the replica > 2) pulling a backup from a few days ago and re-importing it with > replication disabled on the replica (ie, comment out all replication > configuration directives). > 3) artificially recreating master-info-file using the information from > 'SHOW SLAVE STATUS' > 4) restart the replica with replication turned back on > > With MySQL's two phase replication, will the IO thread automatically > figure out what file to start downloading and where to resume? > > Thanks. > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
