Мы выполняем репликацию mysql на большие расстояния и с ограниченной пропускной способностью - задержка около 200 мс и около 70 КБ / с (макс.).
Репликация работает спорадически, передается несколько десятков килобайт, а затем выполняется повторное подключение.
Я проследил проблему до плохого поведения tcp / ip демона mysqld на клиенте - когда один пакет tcp / ip теряется, вся последовательность ACK / повторной передачи не может восстановить соединение, и в какой-то момент сервер выдает FIN.
Примечательно, что scp с того же сервера работает правильно (даже с потерянными пакетами, что иногда случается).
Клиент Mysql с клиентской машины на сервер также работает правильно, и случайная потеря пакетов не прерывает соединение.
И сервер, и клиент имеют одну и ту же версию сервера 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)
Может ли это быть вызвано потерей пакетов, которая происходит, когда TCP / IP пытается поднять окно TCP / IP сверх того, что разрешено соединением?
В итоге я использовал ssh-туннель (и немного изменил настройки репликации) - отлично работает:
ssh -L 3307:localhost:3307 root@the-replication-master-server
Дополнительным бонусом является то, что поток репликации зашифрован.