TCP checksums aren't as strong as encryption. It's rare but corruption can happen.
Where are you reading the positions from and how are you taking the snapshot to restore 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 > -- high performance mysql consulting. http://provenscaling.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
