List:Replication« Previous MessageNext Message »
From:Jed Reynolds Date:February 26 2008 3:52pm
Subject:Re: Stopping replication
View as plain text  
Ed W wrote:
> Marcus Bointon wrote:
>> I have a circular replication setup that I want to stop, leaving just 
>> one master. The (irreparably out of sync) second master has been 
>> stopped for a while, and I want to abandon all changes that are 
>> pending for it, wipe any pending logs, remove its databases prior to 
>> rebuilding it. How do I safely deactivate secondary master references 
>> on the primary? On the primary master I can do "stop slave", but I 
>> want to make sure that it won't attempt to reconnect to the secondary 
>> master if I restart it and won't execute functions from the secondary 
>> that are part of the cleanup process (which could be fatal to the 
>> real DB).
> This is a bit late, but I have had a lot of success using Maatkit from 
> The basic idea is that you keep replication going at all costs, detect 
> it going out of sync using his rather clever table-checksum routines, 
> then carefully resync the servers using his rather clever resync 
> routines.  By using "replace into" the point is that you can create a 
> transaction which will replicate out and fix your servers and bring 
> them back into sync again.
> Works very well for me.  The use of replication to do the checksums is 
> completely inspired also!  Works fine for multi-master replication as 
> well

My experience with maatkit, especially after running it after doing a 
'repair table' is that it's pretty one-sided
and you might need to use the --print option to mk-table-sync before 
actually running it a full strength.

Consider multi-masters A, B. You get application warnings that 
B:bigtable is missing entries and has entries not on A:bigtable. You 
look closer and find that A:bigtable reports 'crashed'. You've repaired 
A:bigtable. That repair found shortened records and deleted them. If you 
run mk-table-sync A B now, to replace the entries missing on B:bigtable, 
B:bigtable will also lose the shortened records deleted from A:bigtable. 
This whole situation started because replication behavior can seem to 
become undefined when a table gets marked as crashed.

I do not know of a way to "Union" missing results with mk-table-sync, 
because it certainly would be useful to keep the data in both tables. To 
do that you'd have to query with 'mk-table-sync --print A B' then from 
the other direction 'mk-table-sync --print B A' and then reconcile the 

Stopping replicationMarcus Bointon19 Feb
  • Re: Stopping replicationAugusto Bott20 Feb
    • Re: Stopping replicationMarcus Bointon20 Feb
  • Re: Stopping replicationEd W26 Feb
    • Re: Stopping replicationJed Reynolds26 Feb
      • Re: Stopping replicationEd W26 Feb
Re: Stopping replicationLuis Torres20 Feb