Acabei usando o ssh tunnel (e ajustando as configurações de replicação um pouco) - funciona perfeitamente:
ssh -L 3307:localhost:3307 root@the-replication-master-server
O bônus adicional é que o fluxo de replicação é criptografado.
Estamos fazendo replicação de mysql off-site através de longa distância e largura de banda limitada - latência de cerca de 200ms e cerca de 70KB / s (max).
A replicação funciona esporadicamente, transferindo várias dezenas de kilobytes e, em seguida, reconectando-se.
Eu rastreei o problema para o comportamento tcp / ip ruim do daemon mysqld no cliente - quando um único pacote tcp / ip é perdido, toda a sequência de ACK / retransmissão não pode recuperar a conexão e em algum momento o servidor FIN .
É notável que o scp do mesmo servidor funcione corretamente (mesmo com pacotes perdidos que acontecem ocasionalmente).
O cliente Mysql da máquina cliente para o servidor também funciona corretamente e a perda ocasional de pacotes não quebra a conexão.
O servidor e o cliente possuem a mesma versão do servidor mysql:
mysql> SHOW VARIABLES LIKE '%version%';
+-------------------------+---------------------+
| Variable_name | Value |
+-------------------------+---------------------+
| protocol_version | 10 |
| version | 5.0.67-0ubuntu6-log |
| version_comment | (Ubuntu) |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
+-------------------------+---------------------+
5rows in set (0.21 sec)
Isso pode ser causado pela perda de pacotes que ocorre quando o TCP / IP tenta aumentar a janela TCP / IP além do permitido pela conexão?
Tags mysql replication