MySQL主從復制能完美解決數(shù)據(jù)庫的單點問題嗎？為什么？沒有完美的解決方案。只有合適的解決方案。當使用主從時，實際已經(jīng)放棄了強一致性了。(既然題主只問單點問題，就不考慮訪問量問題。即假設主從復制完全能

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

沒有完美的解決方案。只有合適的解決方案。

當使用主從時，實際已經(jīng)放棄了強一致性了。(既然題主只問單點問題，就不考慮訪問量問題。即假設主從復制完全能支撐目前的系統(tǒng)訪問。)

一般數(shù)據(jù)庫主從設置：

• 主庫可讀可寫

• 從庫只讀

即系統(tǒng)既可以從主庫獲取數(shù)據(jù)，也可以從從庫獲取數(shù)據(jù)。數(shù)據(jù)寫入主庫后，自動同步到從庫。

這構(gòu)成了一個簡單的分布式系統(tǒng)。根據(jù)cap定理，只能三選一。主從之間是最終一致，如果強一致，不但不會提高系統(tǒng)可用性，反而降低了系統(tǒng)可用性。

我們看上面的主從結(jié)構(gòu)可能會出現(xiàn)哪些問題：

• 系統(tǒng)寫入主庫，再從主庫查詢。這就是個單點數(shù)據(jù)庫，沒有什么影響。

• 系統(tǒng)寫入主庫，再從從庫查：

- 如果數(shù)據(jù)已經(jīng)同步，則沒有影響

- 如果數(shù)據(jù)還未同步，則查詢的是老數(shù)據(jù)

- 如果同步出現(xiàn)了問題，則主從斷開。如果系統(tǒng)無法感知，則查詢到的可能一直是老數(shù)據(jù)。這里就需要對同步進行監(jiān)控，當同步出現(xiàn)問題時，及時處理

• 主庫掛掉。從庫需要及時感知，并替換主庫。同時需要再通知運維人員處理，否則又變成了單點。
  

• 從庫掛掉。主庫數(shù)據(jù)無法同步到從庫。同樣需要及時通知處理

如果主從切換自動化，那單點故障的概率也只是降低50%而已（主庫或備庫掛掉沒人恢復的話）。