List:Internals« Previous MessageNext Message »
From:Christian Rabe Date:November 1 2000 10:59am
Subject:Re: A suggestion on Replication
View as plain text  
Hi,

Yes, you are right.
User-variables are supported by replication neither.
So far I know (only what I read in the manual), user-variables are thread-bound. And
therefore only the replication-thread on
the slave knows anything of them, if at all. So the values are lost on reconnect or the
next flush slave at the latest.

Regards,

Christian "Maverick" Rabe
IT-Development
wallstreet:online AG
------------------------------------------
http://www.wallstreet-online.de
Tel.:  03 37 01 5 29 16
Fax.:  03 37 01 5 29 19
  ----- Original Message ----- 
  From: Wei He 
  To: Christian Rabe 
  Cc: internals@stripped 
  Sent: Wednesday, November 01, 2000 3:18 AM
  Subject: Re: A suggestion on Replication


  On Thu, 26 Oct 2000, Christian Rabe wrote:

  Thanks for your instruction. I didn't have and change to try again until
  todayb I found my replication being interrupted again. In my
  environment, your first and third cases can be excluded. 

  Instead of using temporary tables, I use variables like @ID, @tempid...
  Since the connection between my master and slave is poor, I wonder once 
  the connection is broken, the @ID will lose its value when reconnected.
  I this case, hacking of slave.cc will not only of no help but dangerous.
  Am I right? 

  Wei He





  > Hi,
  > 
  > To 1: To accomplish this, you have to disable the lines 926-933 in the
  > sql/slave.cc (3.23.26)
  > To 2: This is already the case. Only successful master-querys are logged.
  > There are 3 cases, so far I know, when the
  >         slave gets a query to break on.
  >         First: there are Tables on the master that are not on the slave and
  > you write to them.
  >         Second: You use temporary tables,which are not temporary on the
  > slave and therefore not deletet afterward.
  >         So the Slave breaks the moment you try to recreate it on the master.
  >         In this two cases the command "SET SQL_LOG_BIN = 0" can help you,
  > which switches the logging off.
  > 
  >         Third: You make a flush slave without a former flush master. The
  > slave reads
  >         then all existing logfiles anew which can lead to problems with
  > duplicate entries on the slave and BANG!
  > 
  > I too had to use the dirty way of disabling the error with the drawback that
  > when there really is an error you won't notice it.
  > 
  > Regards,
  > 
  > Christian "Maverick" Rabe
  > IT-Development
  > wallstreet:online AG
  > ------------------------------------------
  > http://www.wallstreet-online.de
  > Tel.:  03 37 01 5 29 16
  > Fax.:  03 37 01 5 29 19
  > 
  > 
  > ----- Original Message -----
  > From: Wei He
  > To: internals@stripped
  > Sent: Thursday, October 26, 2000 4:45 AM
  > Subject: A suggestion on Replication
  > 
  > 
  > Hi,
  > 
  > According to my experience, the replication will be broken when the slave
  > executes a error sql command. Can this be changed to:
  > 
  > 1. The slave ignores the error and continues the replication;
  > 2. The master only bin-logs sql commands that succeed.
  > 
  > 
  > Wei He
  > 
  > 
  > ---------------------------------------------------------------------
  > Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
  > posting. To request this thread, e-mail internals-thread55@stripped
  > 
  > To unsubscribe, send a message to the address shown in the
  > List-Unsubscribe header of this message. If you cannot see it,
  > e-mail internals-unsubscribe@stripped instead.
  > 
  > 
  > ---------------------------------------------------------------------
  > Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
  > posting. To request this thread, e-mail internals-thread56@stripped
  > 
  > To unsubscribe, send a message to the address shown in the
  > List-Unsubscribe header of this message. If you cannot see it,
  > e-mail internals-unsubscribe@stripped instead.
  > 
  >

Thread
A suggestion on ReplicationWei He26 Oct
  • Re: A suggestion on ReplicationChristian Rabe26 Oct
    • Re: A suggestion on ReplicationThimble Smith26 Oct
    • Re: A suggestion on ReplicationWei He1 Nov
      • Re: A suggestion on ReplicationChristian Rabe1 Nov
  • Re: A suggestion on Replicationsasha26 Oct
  • Strange behavior of flush logs with the replicationChristian Rabe26 Oct
  • Re: Strange behavior of flush logs with the replicationsasha26 Oct
  • Re: Strange behavior of flush logs with the replicationChristian Rabe26 Oct
  • Re: Strange behavior of flush logs with the replicationChristian Rabe27 Oct