mysql主從同步配置 mysql主主和主從區(qū)別?
mysql主主和主從區(qū)別?MySQL復制的原理:將MySQL的一臺主機的數據復制到另一臺(從)主機上,再執(zhí)行一次,將數據分發(fā)到多個系統(tǒng)中;在復制過程中,一臺服務器作為主服務器,另一臺或多臺服務器作為從
mysql主主和主從區(qū)別?
MySQL復制的原理:
將MySQL的一臺主機的數據復制到另一臺(從)主機上,再執(zhí)行一次,將數據分發(fā)到多個系統(tǒng)中;
在復制過程中,一臺服務器作為主服務器,另一臺或多臺服務器作為從服務器。主服務器將更新寫入二進制日志文件,并維護該文件的索引以跟蹤日志周期。
這些日志可以記錄發(fā)送到從屬服務器的更新。當從屬服務器連接到主服務器時,它會在日志中通知主服務器上一次從服務器讀取的成功更新的位置。從屬服務器
接收此后發(fā)生的任何更新,然后阻塞并等待主服務器通知新的更新。
主服務器中主數據庫的DDL和DML操作通過二進制日志傳輸到從服務器,然后在主服務器中重新執(zhí)行這些日志文件,以便從服務器和主服務器上的數據信息可以同步。
MySQL主從模式是在主機上操作數據,從機實時同步數據。相反,對于從機操作,主機不會同步數據,可能造成數據混亂,導致主、從機故障。
MySQL主模式是彼此的從屬服務器。每臺服務器互為主服務器和從服務器。無論操作哪一個,另一個都會同步數據。它通常用作高災難恢復方案。
什么情況會導致MySQL主從復制延遲?
主從復制有兩個線程,SQL和Io。前者負責SQL的復制,后者負責編寫。因此,從兩個方面來看,當網絡較差,或者帶寬有限,或者主CPU太忙,跟不上binlog傳輸速度,或者從機IO性能較差時,很容易造成主從復制延遲。從show slave status的一些參數可以看出,大約在master后面XX個左右,實際上MySQL的主從問題很大,設計比較低。我至少三年沒有關注MySQL了。我不知道這方面有沒有改進。
MySQL主從復制能完美解決數據庫的單點問題嗎?為什么?
使用主從時,實際上放棄了強一致性。由于受試者只問一個問題,我們不考慮訪問次數的問題。換句話說,假設主從復制可以完全支持當前的系統(tǒng)訪問。)
通用數據庫主從設置:
主數據庫可以讀寫
即系統(tǒng)可以同時從主數據庫和從數據庫獲取數據。數據寫入主庫后,會自動同步到從庫。
這構成了一個簡單的分布式系統(tǒng)。根據cap定理,三個中只能選擇一個。如果一致性很強,則不會提高系統(tǒng)的可用性,反而會降低系統(tǒng)的可用性。
讓我們看看上面的主從結構中可能出現什么問題:
系統(tǒng)寫入主數據庫,然后從主數據庫進行查詢。這是一個單點數據庫,沒有影響。
-如果數據已同步,則沒有影響
-如果數據未同步,則會查詢舊數據
-如果同步有問題,則會斷開主設備和從設備的連接。如果系統(tǒng)無法感知它,那么查詢可能總是舊數據。這里我們需要監(jiān)視同步。當同步出現問題時,我們應該及時處理
掛斷庫。主數據不能與從數據同步。如果主從交換機是自動的,單點故障的概率只會降低50%(如果主數據庫或備用數據庫發(fā)生故障,并且沒有人恢復)。