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 <[EMAIL PROTECTED]> 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 >> >> > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
