List:General Discussion« Previous MessageNext Message »
From:Jan Kirchhoff Date:April 22 2008 8:02am
Subject:Re: problems w/ Replication over the Internet
View as plain text  
Eric Bergen schrieb:
> TCP checksums aren't as strong as encryption. It's rare but corruption
> can happen.
>   
But it happens every other day? that means at least one error in 4GB of
data (I have around 2GB of binlogs/day)?
Every DVD-ISO you download would be corrupt (statistically)?

> Where are you reading the positions from and how are you taking the
> snapshot to restore the slave?
>   
From the log file:

080415  6:39:20 [ERROR] Error
running query, slave SQL thread aborted. Fix the problem, and restart
the slave SQL thread with "SLAVE START". We stopped at log
'mysql-bin.045709' position 172


I use rsync to set up the slave...


>
> On Mon, Apr 21, 2008 at 12:30 AM, Jan Kirchhoff <kirchy@stripped> wrote:
>   
>> Eric Bergen schrieb:
>>
>>     
>>> Hi Jan,
>>>       
>>  >
>>  > You have two separate issues here. First the issue with the link
>>  > between the external slave and the master. Running mysql through
>>  > something like stunnel may help with the connection and data loss
>>  > issues.
>>  >
>>  I wonder how any corruption could happen on a TCP connection as TCP has
>>  its own checksums and a connection would break down in case of a missing
>>  packet?
>>
>>     
>>> The second problem is that your slave is corrupt. Duplicate key errors
>>>       
>>  > are sometimes caused by a corrupt table but more often by restarting
>>  > replication from an incorrect binlog location. Try recloning the slave
>>  > and starting replication again through stunnel.
>>  >
>>  The duplicate key errors happen after I start at the beginning of a
>>  logfile (master_log_pos=0) when the positions that mysql reports as its
>>  last positions is not working.
>>
>>  I think I have 2 issues:
>>  #1: how can this kind of binlog corruption happen on a TCP link although
>>  TCP has its checksums and resends lost packets?
>>
>>  #2: why does mysql report a master log position that is obviously wrong?
>>  mysql  reports log-posion 172 which is not working at all in a "change
>>  master to" command, my only option is to start with master_log_pos=0 and
>>  the number of duplicate key errors and such that I have to skip after
>>  starting from master_log_pos=0 shows me that the real position that
>>  mysql has stopped processing the binlog must be something in the
>>  thousands or tenthousands and not 172?!
>>
>>  Jan
>>
>>     
>
>
>
>   

Thread
problems w/ Replication over the InternetJan Kirchhoff15 Apr
  • Re: problems w/ Replication over the InternetEric Bergen21 Apr
    • Re: problems w/ Replication over the InternetJan Kirchhoff21 Apr
      • Re: problems w/ Replication over the InternetEric Bergen21 Apr
        • Re: problems w/ Replication over the InternetJan Kirchhoff22 Apr
          • Re: problems w/ Replication over the InternetJan Kirchhoff25 Apr