Basic questions on slave servers

[andys-2]

Hi list,


  hopefully a couple of easy to answer fundamental questions on a simple master slave setup.

1) When a DB is in slave mode, does MySQL prevent any other updates to the DB other than those from the master?
ie, can someone accidentally update the slave with data that doesnt match the master DB or is this prevented, or put
another way, is the slave effectively in read-only mode whilst it is running as a slave?

2) If the master should fail and I want my slave to run as a normal standalone read/write DB what do I have to do? Is it
just:
stop slave;
reset master;
?

thanks in advance! Andy.

[Edward F. Pauley II]

Andy,
1. MySQL does not prevent any other updates to the slave. You can do this
yourself by only allowing SELECT privileges to users.

2. You really need not do anything, unless you have restricted users access
like mentioned in above.

Syncing the slave up to the master upon recovery is an entirely different
story. This is not easy to accomplish. There are several options for this
though and it is not impossible.

If High Availability is your goal you should consider other easier to manage
HA solutions such as DRBD.

Ed Pauley II
MySQL DBA - CMDBA



-----Original Message-----
From: Andy Smith [mailto:a.smith@...]
Sent: Tuesday, March 18, 2008 9:13 AM
To: replication@...
Subject: Basic questions on slave servers

Hi list,


  hopefully a couple of easy to answer fundamental questions on a simple
master slave setup.

1) When a DB is in slave mode, does MySQL prevent any other updates to the
DB other than those from the master?
ie, can someone accidentally update the slave with data that doesnt match
the master DB or is this prevented, or put
another way, is the slave effectively in read-only mode whilst it is running
as a slave?

2) If the master should fail and I want my slave to run as a normal
standalone read/write DB what do I have to do? Is it
just:
stop slave;
reset master;
?

thanks in advance! Andy.



--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[Chris.Leeworthy]

Hi Andy,

On your first point, MySQL itself will not stop you from inserting or
updating records on tables in the slave database, it's something you will
need to protect yourself against.  One of my colleagues discovered this to
his cost when he accidentaly inserted records on the slave instead of the
master.  I should probably qualify this by saying we work with MyISAM
tables, I don't know how the other database engines might cope with it.

On the second one, I can't really remember well enough to give an
answer.  What I can say is that the one time I needed to do it the
documentation on the MySQL website guided me through.

With any luck the more experienced folk around here might give you a more
detailed answer.

Best Regards

Chris.
|-----------------------------+-------------------------------------------|
|   "Andy Smith"              |                                           |
|   <a.smith@...>      |                                           |
|                             |                                         To|
|   18/03/2008 13:14          |                                <replicatio|
|                             |                                n@...|
|                             |                                ql.com>    |
|                             |                                         cc|
|                             |                                           |
|                             |                                    Subject|
|                             |                                Basic      |
|                             |                                questions  |
|                             |                                on slave   |
|                             |                                servers    |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|                             |                                           |
|-----------------------------+-------------------------------------------|






Hi list,


hopefully a couple of easy to answer fundamental questions on a simple
master slave setup.

1) When a DB is in slave mode, does MySQL prevent any other updates to the
DB other than those from the master?
ie, can someone accidentally update the slave with data that doesnt match
the master DB or is this prevented, or put
another way, is the slave effectively in read-only mode whilst it is
running as a slave?

2) If the master should fail and I want my slave to run as a normal
standalone read/write DB what do I have to do? Is it
just:
stop slave;
reset master;
?

thanks in advance! Andy.

**********************************************************************
This transmission is confidential and must not be used or disclosed by
anyone other than the intended recipient. Neither Corus Group Limited nor
any of its subsidiaries can accept any responsibility for any use or
misuse of the transmission by anyone.

For address and company registration details of certain entities
within the Corus group of companies, please visit
http://www.corusgroup.com/entities

**********************************************************************


--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[andys-2]

Hi,

  thanks for the repsonces....
With regards to DRDB, wouldnt a Master - Master environment be simpler than this? Also is it available as OpenSource?
Its listed on the MySQL enterprise section, do you have to pay for this?

thanks Andy.

[Rick James]

"Dual Master" (two masters replicating from each other) do not need
Enterprise.  And if you have the two masters in geographically different
locations, you get an added degree of disaster recovery.
 

> -----Original Message-----
> From: Andy Smith [mailto:a.smith@...]
> Sent: Tuesday, March 18, 2008 11:14 AM
> To: replication@...
> Subject: Re: Basic questions on slave servers
>
> Hi,
>
>   thanks for the repsonces....
> With regards to DRDB, wouldnt a Master - Master environment
> be simpler than this? Also is it available as OpenSource?
> Its listed on the MySQL enterprise section, do you have to
> pay for this?
>
> thanks Andy.
>

--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[andys-2]

Strangely regarding master-master replication there doesnt seem to be any documentation on this on the mysql site (tho there is
on other external sites). Is there any particular reason for this lack of information? I'd like to see some info on the theory of how
master-master works and the limitations...

thanks Andy.

[Martin MC Brown]

Hi Andy,

> Strangely regarding master-master replication there doesnt seem to  
> be any documentation on this on the mysql site (tho there is
> on other external sites). Is there any particular reason for this  
> lack of information? I'd like to see some info on the theory of how
> master-master works and the limitations...


There are two reasons for this:

1) It's not something that in the past we have recommended as a  
solution because of the potential problems (overwriting IDs, getting  
DBs out of sync, etc).

2) We did have, incomplete, information and advice in the manual,  
which was removed to be part of a new topology chapter. This new  
chapter is currently being written :)

MC


--
Martin MC Brown, Technical Writer
MySQL AB, http://www.mysql.com
Skype: mcmcslp



--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[andys-2]

Hi Martin,

  ok thanks, so the next questions that come to mind are:

You say in the past its not been recommended, that implies that the situation has now changed and that
this is seen as a stable configuration (production ready or however u want to call it). Would that be correct?

Good to hear your working on some complete documentation! In the mean time, can you point me at any
useful information regarding this?? How it handles replication WRT writes to multiple hosts etc?

If I just need HA and in practice I am never going to be doing writes to both masters at the same time is this
already a fairly robust solution for my needs? Ie perhaps I will have a floating IP which Ill move from one system
to the other in the event of any issues on the primary master,

thanks for your help! Andy.
There are two reasons for this:

1) It's not something that in the past we have recommended as a  
solution because of the potential problems (overwriting IDs, getting  
DBs out of sync, etc).

2) We did have, incomplete, information and advice in the manual,  
which was removed to be part of a new topology chapter. This new  
chapter is currently being written :)

[Marcus Bointon]

On 20 Mar 2008, at 17:51, Andy Smith wrote:
> You say in the past its not been recommended, that implies that the  
> situation has now changed and that
> this is seen as a stable configuration (production ready or however  
> u want to call it). Would that be correct?


He may be referring to the new replication features in 5.1 which make  
replication generally more reliable, particularly in the case of row-
based replication.

5.1 is not released yet, so I wouldn't describe it as stable, though  
it may well be in practice.

Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info@hand CRM solutions
marcus@... | http://www.synchromedia.co.uk/

[Rick James]

* Write to only one of the Masters -- this eliminates various
auto-increment issues, etc.  Also, writing to both masters buys nothing,
certainly not write-scalability since all writes have to be performed on
both machines.

* Do not attempt to deploy automatic failover -- there can be partial
network outages that will fool the automatic thingie into thinking a
Master is down.  You can end up with 2 masters being written to; this
will hopelessly corrupt the data.

* If you scale reads by having slaves, some should hang off each Master.
This way, half your slaves are still up-to-date if one (either) master
dies.

* There are rare cases where "one" item in the replication stream
between the Masters will get lost in a hard crash.

* Put your Masters in two geographically separate places -- why have
dual-master if a power failure (earthquake, etc) can still bring down
the whole system?

* To be doubly safe, set the backup master to read_only.

* Replication items will not "loop" -- the server_id of the original
sender is noticed, thereby allowing the items to be tossed.

> -----Original Message-----
> From: Andy Smith [mailto:a.smith@...]
> Sent: Thursday, March 20, 2008 10:52 AM
> To: replication@...
> Subject: Re: Basic questions on slave servers
>
> Hi Martin,
>
>   ok thanks, so the next questions that come to mind are:
>
> You say in the past its not been recommended, that implies
> that the situation has now changed and that
> this is seen as a stable configuration (production ready or
> however u want to call it). Would that be correct?
>
> Good to hear your working on some complete documentation! In
> the mean time, can you point me at any
> useful information regarding this?? How it handles
> replication WRT writes to multiple hosts etc?
>
> If I just need HA and in practice I am never going to be
> doing writes to both masters at the same time is this
> already a fairly robust solution for my needs? Ie perhaps I
> will have a floating IP which Ill move from one system
> to the other in the event of any issues on the primary master,
>
> thanks for your help! Andy.
> There are two reasons for this:
>
> 1) It's not something that in the past we have recommended as a  
> solution because of the potential problems (overwriting IDs, getting  
> DBs out of sync, etc).
>
> 2) We did have, incomplete, information and advice in the manual,  
> which was removed to be part of a new topology chapter. This new  
> chapter is currently being written :)
>

--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[Eric Frazier-4]

Rick James wrote:
> * Write to only one of the Masters -- this eliminates various
> auto-increment issues, etc.  Also, writing to both masters buys nothing,
> certainly not write-scalability since all writes have to be performed on
> both machines.
>  
It does indeed buy you something. If your masters are in "geographicly
diverse locations"  Take 90ms latency to a webserver vs .2ms over the
course of a few million connections.

> * Do not attempt to deploy automatic failover -- there can be partial
> network outages that will fool the automatic thingie into thinking a
> Master is down.  You can end up with 2 masters being written to; this
> will hopelessly corrupt the data.
>  
Little bit of a bold statement. Given your failover script, what caused
the problem exactly? How could you have fixed things to prevent the dual
write? How was a dual write even possible according to your DB scheme?

> * If you scale reads by having slaves, some should hang off each Master.
> This way, half your slaves are still up-to-date if one (either) master
> dies.
>  
Good advice I think.

> * There are rare cases where "one" item in the replication stream
> between the Masters will get lost in a hard crash.
>
> * Put your Masters in two geographically separate places -- why have
> dual-master if a power failure (earthquake, etc) can still bring down
> the whole system?
>
> * To be doubly safe, set the backup master to read_only.
>  

What about sync_binlog=1 ?
> * Replication items will not "loop" -- the server_id of the original
> sender is noticed, thereby allowing the items to be tossed.
>  
No one should think of using autoinc keys in tables unless they want to
run into larger problems as they scale, at least not with MySQL. Having
said that, auto_increment_increment, auto_increment_offset   allow
screwed up DBs to still work with master - master. I use those because
those choices are not always mine.

Thanks,

Eric

>  
>> -----Original Message-----
>> From: Andy Smith [mailto:a.smith@...]
>> Sent: Thursday, March 20, 2008 10:52 AM
>> To: replication@...
>> Subject: Re: Basic questions on slave servers
>>
>> Hi Martin,
>>
>>   ok thanks, so the next questions that come to mind are:
>>
>> You say in the past its not been recommended, that implies
>> that the situation has now changed and that
>> this is seen as a stable configuration (production ready or
>> however u want to call it). Would that be correct?
>>
>> Good to hear your working on some complete documentation! In
>> the mean time, can you point me at any
>> useful information regarding this?? How it handles
>> replication WRT writes to multiple hosts etc?
>>
>> If I just need HA and in practice I am never going to be
>> doing writes to both masters at the same time is this
>> already a fairly robust solution for my needs? Ie perhaps I
>> will have a floating IP which Ill move from one system
>> to the other in the event of any issues on the primary master,
>>
>> thanks for your help! Andy.
>> There are two reasons for this:
>>
>> 1) It's not something that in the past we have recommended as a  
>> solution because of the potential problems (overwriting IDs, getting  
>> DBs out of sync, etc).
>>
>> 2) We did have, incomplete, information and advice in the manual,  
>> which was removed to be part of a new topology chapter. This new  
>> chapter is currently being written :)
>>
>>    
>
>  

--
Eric Frazier
Holistis.com
216 Main Street, Suite 312  
Bathurst, NB, E2A 1A8        
Canada    
Phone  : [phone]  ext 3303  
Fax    : [phone]        


--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[Rick James]

below...

> -----Original Message-----
> From: Eric Frazier [mailto:efrazier@...]
> Sent: Thursday, March 20, 2008 1:02 PM
> To: Rick James
> Cc: Andy Smith; replication@...
> Subject: Re: Basic questions on slave servers
>
> Rick James wrote:
> > * Write to only one of the Masters -- this eliminates various
> > auto-increment issues, etc.  Also, writing to both masters
> buys nothing,
> > certainly not write-scalability since all writes have to be
> performed on
> > both machines.
> >  
> It does indeed buy you something. If your masters are in
> "geographicly
> diverse locations"  Take 90ms latency to a webserver vs .2ms over the
> course of a few million connections.

In one case, we chose to send the API request to the colo where the
master is.

Usually the one or two INSERTs can afford the 70ms delay we see between
coasts.

> > * Do not attempt to deploy automatic failover -- there can
> be partial
> > network outages that will fool the automatic thingie into thinking a
> > Master is down.  You can end up with 2 masters being
> written to; this
> > will hopelessly corrupt the data.
> >  
> Little bit of a bold statement. Given your failover script,
> what caused
> the problem exactly? How could you have fixed things to
> prevent the dual
> write? How was a dual write even possible according to your DB scheme?

More details on the bad case:
* Colo where Master is goes dark, but it is actually because of a
network glitch.
* Clients within that colo were happily writing to the Master.
* Failover script (not automated), alert us that the "master seems to be
dead".
* Manual fishing around discovered what the case really was, so we held
off on failing over.

Alas, that led to a "partial outage" for a couple hours while the
network was repaired.  But that was better than having two writable
masters.

Note: I could not reach the Master to determine its state, nor to shut
it down.

> > * If you scale reads by having slaves, some should hang off
> each Master.
> > This way, half your slaves are still up-to-date if one
> (either) master
> > dies.
> >  
> Good advice I think.
>
> > * There are rare cases where "one" item in the replication stream
> > between the Masters will get lost in a hard crash.
> >
> > * Put your Masters in two geographically separate places -- why have
> > dual-master if a power failure (earthquake, etc) can still
> bring down
> > the whole system?
> >
> > * To be doubly safe, set the backup master to read_only.
> >  
>
> What about sync_binlog=1 ?

New feature; haven't tried it yet.  But with our Masters 70ms apart, and
avg of 150 updates/sec, it might not be viable?

> > * Replication items will not "loop" -- the server_id of the original
> > sender is noticed, thereby allowing the items to be tossed.
> >  
> No one should think of using autoinc keys in tables unless
> they want to
> run into larger problems as they scale, at least not with
> MySQL. Having
> said that, auto_increment_increment, auto_increment_offset   allow
> screwed up DBs to still work with master - master. I use
> those because
> those choices are not always mine.

Yeah, I leave those tricks as a last resort.

> Thanks,
>
> Eric
>
> >  
> >> -----Original Message-----
> >> From: Andy Smith [mailto:a.smith@...]
> >> Sent: Thursday, March 20, 2008 10:52 AM
> >> To: replication@...
> >> Subject: Re: Basic questions on slave servers
> >>
> >> Hi Martin,
> >>
> >>   ok thanks, so the next questions that come to mind are:
> >>
> >> You say in the past its not been recommended, that implies
> >> that the situation has now changed and that
> >> this is seen as a stable configuration (production ready or
> >> however u want to call it). Would that be correct?
> >>
> >> Good to hear your working on some complete documentation! In
> >> the mean time, can you point me at any
> >> useful information regarding this?? How it handles
> >> replication WRT writes to multiple hosts etc?
> >>
> >> If I just need HA and in practice I am never going to be
> >> doing writes to both masters at the same time is this
> >> already a fairly robust solution for my needs? Ie perhaps I
> >> will have a floating IP which Ill move from one system
> >> to the other in the event of any issues on the primary master,
> >>
> >> thanks for your help! Andy.
> >> There are two reasons for this:
> >>
> >> 1) It's not something that in the past we have recommended as a  
> >> solution because of the potential problems (overwriting
> IDs, getting  
> >> DBs out of sync, etc).
> >>
> >> 2) We did have, incomplete, information and advice in the manual,  
> >> which was removed to be part of a new topology chapter. This new  
> >> chapter is currently being written :)
> >>
> >>    
> >
> >  
>
>
> --
> Eric Frazier
> Holistis.com
> 216 Main Street, Suite 312  
> Bathurst, NB, E2A 1A8        
> Canada    
> Phone  : [phone]  ext 3303  
> Fax    : [phone]        
>
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:    
> http://lists.mysql.com/replication?unsub=rjames@...
>
>

--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...

[Moon's Father]

You should add read-only in your slave's configuration file.

On Fri, Mar 21, 2008 at 5:04 AM, Rick James <rjames@...> wrote:

> below...
>
> > -----Original Message-----
> > From: Eric Frazier [mailto:efrazier@...]
> > Sent: Thursday, March 20, 2008 1:02 PM
> > To: Rick James
> > Cc: Andy Smith; replication@...
> > Subject: Re: Basic questions on slave servers
> >
> > Rick James wrote:
> > > * Write to only one of the Masters -- this eliminates various
> > > auto-increment issues, etc.  Also, writing to both masters
> > buys nothing,
> > > certainly not write-scalability since all writes have to be
> > performed on
> > > both machines.
> > >
> > It does indeed buy you something. If your masters are in
> > "geographicly
> > diverse locations"  Take 90ms latency to a webserver vs .2ms over the
> > course of a few million connections.
>
> In one case, we chose to send the API request to the colo where the
> master is.
>
> Usually the one or two INSERTs can afford the 70ms delay we see between
> coasts.
>
> > > * Do not attempt to deploy automatic failover -- there can
> > be partial
> > > network outages that will fool the automatic thingie into thinking a
> > > Master is down.  You can end up with 2 masters being
> > written to; this
> > > will hopelessly corrupt the data.
> > >
> > Little bit of a bold statement. Given your failover script,
> > what caused
> > the problem exactly? How could you have fixed things to
> > prevent the dual
> > write? How was a dual write even possible according to your DB scheme?
>
> More details on the bad case:
> * Colo where Master is goes dark, but it is actually because of a
> network glitch.
> * Clients within that colo were happily writing to the Master.
> * Failover script (not automated), alert us that the "master seems to be
> dead".
> * Manual fishing around discovered what the case really was, so we held
> off on failing over.
>
> Alas, that led to a "partial outage" for a couple hours while the
> network was repaired.  But that was better than having two writable
> masters.
>
> Note: I could not reach the Master to determine its state, nor to shut
> it down.
>
> > > * If you scale reads by having slaves, some should hang off
> > each Master.
> > > This way, half your slaves are still up-to-date if one
> > (either) master
> > > dies.
> > >
> > Good advice I think.
> >
> > > * There are rare cases where "one" item in the replication stream
> > > between the Masters will get lost in a hard crash.
> > >
> > > * Put your Masters in two geographically separate places -- why have
> > > dual-master if a power failure (earthquake, etc) can still
> > bring down
> > > the whole system?
> > >
> > > * To be doubly safe, set the backup master to read_only.
> > >
> >
> > What about sync_binlog=1 ?
>
> New feature; haven't tried it yet.  But with our Masters 70ms apart, and
> avg of 150 updates/sec, it might not be viable?
>
> > > * Replication items will not "loop" -- the server_id of the original
> > > sender is noticed, thereby allowing the items to be tossed.
> > >
> > No one should think of using autoinc keys in tables unless
> > they want to
> > run into larger problems as they scale, at least not with
> > MySQL. Having
> > said that, auto_increment_increment, auto_increment_offset   allow
> > screwed up DBs to still work with master - master. I use
> > those because
> > those choices are not always mine.
>
> Yeah, I leave those tricks as a last resort.
>
> > Thanks,
> >
> > Eric
> >
> > >
> > >> -----Original Message-----
> > >> From: Andy Smith [mailto:a.smith@...]
> > >> Sent: Thursday, March 20, 2008 10:52 AM
> > >> To: replication@...
> > >> Subject: Re: Basic questions on slave servers
> > >>
> > >> Hi Martin,
> > >>
> > >>   ok thanks, so the next questions that come to mind are:
> > >>
> > >> You say in the past its not been recommended, that implies
> > >> that the situation has now changed and that
> > >> this is seen as a stable configuration (production ready or
> > >> however u want to call it). Would that be correct?
> > >>
> > >> Good to hear your working on some complete documentation! In
> > >> the mean time, can you point me at any
> > >> useful information regarding this?? How it handles
> > >> replication WRT writes to multiple hosts etc?
> > >>
> > >> If I just need HA and in practice I am never going to be
> > >> doing writes to both masters at the same time is this
> > >> already a fairly robust solution for my needs? Ie perhaps I
> > >> will have a floating IP which Ill move from one system
> > >> to the other in the event of any issues on the primary master,
> > >>
> > >> thanks for your help! Andy.
> > >> There are two reasons for this:
> > >>
> > >> 1) It's not something that in the past we have recommended as a
> > >> solution because of the potential problems (overwriting
> > IDs, getting
> > >> DBs out of sync, etc).
> > >>
> > >> 2) We did have, incomplete, information and advice in the manual,
> > >> which was removed to be part of a new topology chapter. This new
> > >> chapter is currently being written :)
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Eric Frazier
> > Holistis.com
> > 216 Main Street, Suite 312
> > Bathurst, NB, E2A 1A8
> > Canada
> > Phone  : [phone]  ext 3303
> > Fax    : [phone]
> >
> >
> > --
> > MySQL Replication Mailing List
> > For list archives: http://lists.mysql.com/replication
> > To unsubscribe:
> > http://lists.mysql.com/replication?unsub=rjames@...
> >
> >
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:
> http://lists.mysql.com/replication?unsub=yueliangdao0608@...
>
>

--
I'm a mysql DBA in china.
More about me just visit here:
http://yueliangdao0608.cublog.cn

[andys-2]

Hi All,

  thanks for all your comments, always good to get opinions from those who've had to implement stuff
before and fromm people who have different solutions and have encountered different problems etc...
From the discussion so far I think my plan to achieve a reasonable degree of availability will be:

Create a master-master system (systems in different locations)
Set global read_only on the secondary master
Manually change DNS or move a floating IP in event of failure of primary master

I think this will be great as will be very simple, allow quick and easy failover in event of system failure and
also allow maintenance for upgrading etc of MySQL or OS with little or no impact to running systems.

thanks! Andy.

[Ed Wildgoose-2]

Chris.Leeworthy@... wrote:

>
>
> Hi Andy,
>
> On your first point, MySQL itself will not stop you from inserting or
> updating records on tables in the slave database, it's something you will
> need to protect yourself against.  One of my colleagues discovered this to
> his cost when he accidentaly inserted records on the slave instead of the
> master.  
>  

I'm suprised it isn't mentioned more often by the tools in the maatkit
are absolutely fantastic and make repairing from that kind of damage
very achievable.  I haven't seen how they work on very large databases,
but at least they will have a go at figuring out what happened and
generate some clues to recover

For those who don't know what I am talking about there is a very clever
tool which attempts to figure out the difference between two db replicas
and generates a set of sql which brings the databases back into sync -
it's designed to fix broken replication sync and so it generates sql
which should fix the differences (you can then examine it and decide if
it helps or not...)

Much easier than tearing down the database to resync when a failure
occurs!  Can also repair damage where someone updates a slave server for
example!

Ed W

--
MySQL Replication Mailing List
For list archives: http://lists.mysql.com/replication
To unsubscribe:    http://lists.mysql.com/replication?unsub=lists@...