MySQL主從復制能完美解決數(shù)據(jù)庫的單點問題嗎？為什么？使用主從時，實際上放棄了強一致性。由于受試者只問一個問題，我們不考慮訪問次數(shù)的問題。換句話說，假設主從復制可以完全支持當前的系統(tǒng)訪問。)通用數(shù)據(jù)

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

使用主從時，實際上放棄了強一致性。由于受試者只問一個問題，我們不考慮訪問次數(shù)的問題。換句話說，假設主從復制可以完全支持當前的系統(tǒng)訪問。)

通用數(shù)據(jù)庫主從設置：

主數(shù)據(jù)庫可以讀寫

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

這構成了一個簡單的分布式系統(tǒng)。根據(jù)cap定理，三個中只能選擇一個。如果一致性很強，則不會提高系統(tǒng)的可用性，反而會降低系統(tǒng)的可用性。

讓我們看看上面的主從結構中可能出現(xiàn)什么問題：

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

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

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

-如果同步有問題，則會斷開主設備和從設備的連接。如果系統(tǒng)無法感知它，那么查詢可能總是舊數(shù)據(jù)。這里我們需要監(jiān)視同步。當同步出現(xiàn)問題時，我們應該及時處理

掛斷庫。主數(shù)據(jù)不能與從數(shù)據(jù)同步。如果主從交換機是自動的，單點故障的概率只會降低50%（如果主數(shù)據(jù)庫或備用數(shù)據(jù)庫發(fā)生故障，并且沒有人恢復）。

mysql如果出現(xiàn)主從數(shù)據(jù)不一致情況怎么弄？

1. 網(wǎng)絡延遲。由于MySQL主從復制是基于binlog的異步復制，binlog文件通過網(wǎng)絡傳輸，當然網(wǎng)絡延遲是主從異步的絕大多數(shù)原因，特別是對于跨機房的數(shù)據(jù)同步，概率非常大，所以我們應該把讀寫分開，從業(yè)務層面注意初步設計。

2. 主從機負載不一致。由于MySQL的主從復制在主數(shù)據(jù)庫上啟動了一個IO線程，并從上面啟動了一個SQL線程和一個IO線程，因此任何一臺機器的負載都非常高，而且非常繁忙，導致任何一個線程的資源都不足，會出現(xiàn)主從不一致的情況。

3.max u2;允許2;數(shù)據(jù)包設置與主數(shù)據(jù)庫上方的最大設置不一致2;允許2;數(shù)據(jù)包大于從屬數(shù)據(jù)庫。當一個大的SQL語句可以在master數(shù)據(jù)庫上執(zhí)行時，slave數(shù)據(jù)庫上的設置太小，無法執(zhí)行，導致master和slave之間的不一致。

4. 主從不一致是由于從密鑰增量開始的密鑰值與密鑰增量的步長不一致造成的。

5. 在MySQL異常宕機的情況下，如果sync未設置為Binlog=1或InnoDB flushlogat rxuucommit=1，則可能導致Binlog或relaylog文件損壞，導致主從不一致。

6. MySQL錯誤導致的主從異步。

7. 版本不一致，特別是高版本為主，低版本從時，從庫不支持主庫支持的功能。

什么情況會導致MySQL主從復制延遲？

主從復制有兩個線程，SQL和Io。前者負責SQL的復制，后者負責編寫。因此，從兩個方面來看，當網(wǎng)絡較差，或者帶寬有限，或者主CPU太忙，跟不上binlog傳輸速度，或者從機IO性能較差時，很容易造成主從復制延遲。從show slave status的一些參數(shù)可以看出，大約在master后面XX個左右，實際上MySQL的主從問題很大，設計比較低。我至少三年沒有關注MySQL了。我不知道這方面有沒有改進。