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
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
> 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?!