hitsbion.blogg.se

maintain are temp tables created within the session of the SQL Thread.reading the next SQL statement from the Slave’s relay logs and processing them.It downloads binary log entries from the Master and stores them in the Slave’s relay logs. The IO Thread is responsible for communication between Master and Slave. Think about this: When you issue FLUSH TABLES WITH READ LOCK, how is replication affected? Recall that replication has two threads You are worried about any pending changes when running FLUSH TABLES WITH READ LOCK. Would you agree with this or am I missing something? Answer :Īll of these approaches show that you gave these things a lot of thought. Even if they look good by the time I would issue stop slave to S1/S2 something could have come into M1 or M2 and made it into just their slave. There is a non zero amount of time that occurs between measuring/comparing the M’s relationship with each other. One of my requirements is having minimal downtime for the Master-Master cycle while allowing more extended replication downtime for the slave-only instances.Įven if it’s overly complicated what ever approach I go would with end up being scripted so if there’s some kind of rapid looping/checking until just the right time that shouldn’t be a problem.Īn end goal of what I’m trying to accomplish with this is to stop slaving (at least sql_thread execution) on S1 and S2 to have time to do some lengthy comparisons (checksuming etc).Ī concern I have is after step 04 is even though these steps are stopping/starting the master SQL threads, the slaves (S1/S2) replication to their respective masters (M1/M2) is still going. Problem again being during the shuffling there could have been some M2 writes that made it to s2 but never s1.Ĭan anyway think of a clean way to tweak these approached to make it work? stop slaving s1, s2, start until common position on M2.Change master on s1 to M2 (s1 and s2 are now slaving directly from M2).Start slaving on M2/S1 until some common position on M1.The problem though is by step 4, there might have been writes on M2 which had since propagated to S2 but where blocked from getting to S1 b/c of M1’s read lock. Start slave on M1, M2, leaving s1,s2 stopped.Start slave until M2’s master log pos on (S2,M1).Start slave until M1’s master log pos on S1,M2.Even if that’s scripted to happen one after another it’s just a race condition where say a write got to M2 and subsequently S2, but had been been blocked from getting to S1 b/c of M1’s read lock (which made it in before). To their respective masters position and just stop slave. I’m wanting to get it to a point where S1 and S2 are stopped and should be in exact sync.Īs I try thinking this out I keep running into gotchas that won’t quite work out.įlush tables with read lock on both masters, ensure the slaves are all caught up That is both S1 and M2 slave from M1 both S2 and M1 slave from M2. They layout might be illustrated as: M1 M2

I have a master-master setup where each master has it’s own slave.