對於ES，我並沒有在實際專案中應用（自己研究過，沒有實戰過）；我們專案使用的是MongoDB；由於專案的特殊性，我們研究了很多關於A->B的資料同步方案，包括DB2/Mysql到MongoDB，MongoDB到MongoDB等等。

MySQL資料同步到ES的方案

把MySQL的資料實時同步到ES，這樣可以實現在ES中低延遲的檢索，有些公司的專案做了分庫，可以單獨搭建一套ES來放全量的資料（或全量資料的部分欄位，達到全量檢索的效果），常用的資料同步實現方案有這些：

MySQL Binlog：MySQL的Binlog日誌可以用於資料庫的主從複製、資料恢復，也可以將MySQL的資料同步給ES；這裡需要注意，Binlog的日誌模式只能使用ROW模式（另外兩種模式是STATEMENT和MIXED）；解析Binlog日誌中的內容，執行ES Document API，這樣就可以將資料同步到ES中；

MySQL dump：如果是新建的專案，使用Binlog做資料同步是沒有問題的，但如果MySQL已經運行了一段時間，專案架構中後增加的ES，那麼歷史資料的遷移就要額外處理了，因為Binlog可能已經被覆蓋了。這時候歷史資料的同步，可以使用mysqldump對現有資料匯出，之後再使用Binlog的方式；

開源工具：前兩種方式都是在資料庫日誌這個級別做文章，我們還可以使用一些開源工具，比如go-mysql-elasticsearch；它可以幫助我們完成第一次全量資料同步，後續增量資料同步的工作（底層也是解析Binlog日誌）；又或者mypipe，它支援將Binlog日誌內容解析後推送到Kafka，如果要寫入到ES中，還需要寫額外的程式碼從Kafka中消費資料寫入ES。

我們專案中的實現方案

上面提過，我們專案中是將關係型資料庫DB2/Mysql中的資料同步到MongoDB中，Mysql尚且還能使用Binlog日誌，DB2想要把變化的資料實時通知出來，實現起來比較困難（寫程式部署到DB2伺服器上，要和資料庫做關聯配置，當資料發生變化，程式傳送MQ通知給外圍系統），先不說效能是否能保證，就是“自己寫一個通知程式部署到資料庫所在伺服器上（有侵入）”，這一點至少在我們公司是無法做到的。

我們採用了一個非常low的方式來解決這個問題，就是Java程式掃描DB2表中的時間戳，讀取最近變化的資料，加工到MongoDB中；

雖然實現方案比較low，但是效果還不錯，因為我們在從關係型資料到MongoDB的資料同步過程中，可以自有地做資料加工；相當於按照一定的資料維度，比如按照客戶維度，把幾十張表做關聯，加工後行程一個document儲存到MongoDB中；再對外提供服務的時候，查詢效率提升的很明顯，因為表關聯已經提前完成了（介面響應大多數時候都是毫秒級，超過50ms就算慢了）。

缺點也很明顯，資料從關係型資料庫到MongoDB的延遲很高，我們專案幾經最佳化，也需要20分鐘左右；所以一定要結合著業務場景考慮是否使用這種方案。

近年來接觸了比較多的有同步需求的專案，檔案同步以及各種主流和非主流資料庫之間的同步。要把資料從 MySQL 同步到 Elasticsearch，可以透過以下辦法實現。

自實現

資料同步的關鍵的就是提取變化資料，MySQL 中捕獲資料變化的方式有：

觸發器：簡單直接，使用觸發器把變化記錄的主鍵插入到一箇中間表中，程式定時掃描提取資料

Binlog：基於資料庫二進位制日誌，日誌中記錄了資料的增刪改操作，一般都是使用程式模擬 Slave 接收並解析日誌，從而獲取資料

冗餘欄位：可以在同步表中新增一個更新時間欄位，定時掃描並提取大於某個時間點的資料

自實現是需要成本的，當然了，也有很多開源工具可以使用。

使用其他工具 logstash-input-jdbc：這是 logstash 官方提供的一個外掛，支援全量同步和增量同步，原理也比較簡單，就是定時執行SQL，可使用上述使用**冗餘欄位**的方法。地址：https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html go-mysql-elasticsearch：基於 Go 開發的，使用 Binlog 進行同步的第三方開源工具。地址：https://github.com/siddontang/go-mysql-elasticsearch elasticsearch-jdbc：第三方工具，基於 SQL 進行全量和增量的同步。地址：https://github.com/jprante/elasticsearch-jdbc

推薦使用 logstash-input-jdbc，比較易用且穩定。