如何把mysql中的數(shù)據(jù)同步到elasticsearch中？

至于ES，我還沒有沒有在實(shí)際項(xiàng)目中應(yīng)用過(我自己學(xué)過，沒有t沒經(jīng)過實(shí)戰(zhàn))；我們的項(xiàng)目使用MongoDB；由于項(xiàng)目的特殊性，我們研究了很多關(guān)于A-gtB的數(shù)據(jù)同步方案，包括DB2/Mysql到MongoDB，MongoDB到MongoDB等等。

將MySQL數(shù)據(jù)同步到es的方案將MySQL數(shù)據(jù)實(shí)時(shí)同步到ES，可以實(shí)現(xiàn)ES中的低延遲檢索。有的公司為自己的項(xiàng)目做了子庫，可以設(shè)置一套es來放所有的數(shù)據(jù)(或者所有數(shù)據(jù)的某些字段，達(dá)到全檢索的效果)。常用的數(shù)據(jù)同步方案如下:

MySQLBinlog:MySQLBinlog日志可以用于數(shù)據(jù)庫的主從復(fù)制和數(shù)據(jù)恢復(fù)，也可以將MySQL數(shù)據(jù)同步到ES；這里需要注意的是，Binlog的日志模式只能使用行模式(另外兩種模式是語句和混合)；解析Binlog日志的內(nèi)容，執(zhí)行ES文檔API，這樣數(shù)據(jù)就可以同步到ES中；

MySQLdump:如果是新建項(xiàng)目，使用Binlog進(jìn)行數(shù)據(jù)同步是沒有問題的。但是如果MySQL已經(jīng)運(yùn)行了一段時(shí)間，項(xiàng)目架構(gòu)中加入了ES，那么歷史數(shù)據(jù)的遷移就需要額外的處理，因?yàn)锽inlog可能已經(jīng)被覆蓋了。此時(shí)可以通過mysqldump導(dǎo)出已有數(shù)據(jù)，然后使用Binlog來同步歷史數(shù)據(jù)。

開源工具:前兩種方法都是數(shù)據(jù)庫日志級(jí)別的，我們也可以使用一些開源工具，比如Go-Go-MySQL-elasticsearch；；它可以幫助我們完成第一次完全數(shù)據(jù)同步和后續(xù)的增量數(shù)據(jù)同步(底層也是解析Binlog日志)；或者mypip

MySQL主從復(fù)制能完美解決數(shù)據(jù)庫的單點(diǎn)問題嗎？為什么？

沒有完美的解決方案。只有正確的解決方案。

在使用主從的時(shí)候，我們其實(shí)已經(jīng)放棄了強(qiáng)一致性。因?yàn)閷?shí)驗(yàn)對(duì)象只問了一個(gè)問題，他沒有問。;不要考慮訪問量。即假設(shè)主從復(fù)制可以完全支持當(dāng)前的系統(tǒng)訪問。)

常規(guī)數(shù)據(jù)庫主從設(shè)置:

主庫可以讀寫。

從庫中只讀意味著系統(tǒng)可以從主庫和從庫中獲取數(shù)據(jù)。數(shù)據(jù)寫入主庫后，會(huì)自動(dòng)同步到從庫。

這就構(gòu)成了一個(gè)簡(jiǎn)單的分布式系統(tǒng)。根據(jù)cap定理，三個(gè)只能選一個(gè)。主從終于一致了。如果它們強(qiáng)一致，系統(tǒng)可用性不但不會(huì)提高，反而會(huì)降低。

讓讓我們看看上面的主從結(jié)構(gòu)可能會(huì)出現(xiàn)什么問題:

系統(tǒng)寫入主庫，然后從主庫查詢。這是單點(diǎn)數(shù)據(jù)庫，沒有影響。

系統(tǒng)寫入主庫，然后從從庫檢查:-如果數(shù)據(jù)已經(jīng)同步，它沒有影響。

-如果數(shù)據(jù)尚未同步，則查詢是舊數(shù)據(jù)。

-如果同步出現(xiàn)問題，主機(jī)和從機(jī)將斷開連接。如果系統(tǒng)可以如果沒有察覺到，查詢可能總是舊數(shù)據(jù)。這里需要對(duì)同步進(jìn)行監(jiān)控，當(dāng)同步出現(xiàn)問題時(shí)，及時(shí)處理。

主庫掛機(jī)。從庫需要及時(shí)察覺，替換主庫。同時(shí)需要通知運(yùn)維人員處理，否則會(huì)變成單點(diǎn)。

掛在圖書館。主庫數(shù)據(jù)無法與從庫同步。也要及時(shí)通知處理。

如果主從切換自動(dòng)化，單點(diǎn)故障的概率只會(huì)降低50%(如果主庫或備用庫掛起，無人恢復(fù))。