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同步知識的不夠了解也有一定原因，因爲相關問題一定要對相關知識足夠熟悉。
小記一下！以表這幾天排查過程中的辛酸！