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]
