基于tungsten API 同步mysql binlog出现EOF packet received的问题解决

        tungsten是一个开源的数据库同步工具，详细可参考官网（http://en.wikipedia.org/wiki/Tungsten）

        项目需要，需要实时知道mysql更新的数据，因此需要同步对应mysql结点的binlog日志数据并解析，对于同步与解析tungsten 相关API都能实现。其中日志同步主要是RelayClient类，还解析是MysqlExtractor类，对于mysql日志解析，首先需要了解binlog日志格式，主要有（Mixed,row，statement三种），详细有时间会整理一篇文章说明其三种日志格式的区别，以及在解析过程中跟据应用以及服务器的需求选择不同日志，以及不同日志不同的解析等。

        此篇需要记录的是在同步RelayClient日志过程中，在项目结尾阶段，部署后，测试阶段，突然发现开发环境在读完一个Binlog日志后会收到mysql服务器返回EOF的问题，由于开发过程中修改了tungsten API相关代码，开始一直在排查源代码相关问题，以及线上mysql部署的问题，都未发现原因。对于mysql主动关闭感觉到不知所措。

         最后通过tungsten相关issuse论坛，有人提及多slave引起，以及查看mysql主从同步时，不同slave相关配制时 会配制不同的serverId，立即查看tungsten相关源码，其中有此项配制，由于测试环境与开发环境使用的是同一mysql结点，并且使用了同一serverId，从而引起了此问题的产生，经测试，使用不同serverId，此问题不再重现。

         通过以上问题的排查感受很多：1.DB遇到问题时，一定要在可重现的机器上查到问题的原因，中间有想重新配制数据库结点的时候，重新配制开发结点，问题是能得以解决，但是部署线上时此问题一定会重现，从而会引起线上问题，因为如果DB问题能重现，一定要引起重视，排查出原因。2.对于开源项目使用时，遇到相关问题，查询issus相关论坛很重要，使用过程中也许有人遇到同类问题（在一个连接池源码研究过程中也深有感悟）。3.对于mysql多slave同步知识的不够了解也有一定原因，因为相关问题一定要对相关知识足够熟悉。

        小记一下！以表这几天排查过程中的辛酸！