mysql中群集和主從的區別：主從之間是透過mysql的replication來保證資料的一致性；相對mysql群集的資料同步方式來講是異步的。因為異步，所以主從之間複製資料可能會有一點微小的延時，就會出現不一致。
推薦課程：MySQL教學。
主從之間是透過mysql的replication來保證資料的一致性。相對mysql cluster的資料同步方式來講是異步的。
叢集是使用PXC （Percona XtraDB Cluster），多節點的資料即時同步(讀寫)
關於主從
#主從可以保證讀寫分離，也就是寫操作在master，讀操作在slave，主從模式也有多個，這裡只說一主多從。
例如有兩個業務模組，一個不斷寫入訂單記錄等，另一個模組則是產生報表，這時如果不採用讀寫分離，讀寫操作碰一起，可能會發生衝突，影響效能，如果讀寫分離，則不用考慮讀寫同一張表從而影響效能，而且多從可以很好的分攤伺服器的壓力，降低單台機器的壓力。
主從之間是透過mysql的replication來保證資料的一致性，相對群集的資料同步方式來講是異步的，因為非同步，所以主從之間複製資料可能會有一點微小的延時，就會出現不一致。
Replication：主節點要開啟binlog，設定一個唯一的server-id（區域網路內唯一），從節點設定server-id，binlog記錄了master上的所有操作，會被複製到從節點的relaylog並在從節點上回放。
但是主從也有缺點，一個是不滿足高可用，master宕機，需要手動切換才行，業務會中斷不允許的,
還有就是數據不一致，而不一致可能導致的原因有很多，以下是常見的幾點
主庫或從庫意外宕機，宕機可能會造成binlog或relaylog檔案出現損壞，導致主從不一致（本博有篇文章，當機後修復）
主函式庫執行變更前有執行set sql_log_bin=0，會使主函式庫不記錄binlog，從函式庫也無法變更這部分資料
主庫binlog格式為Statement，同步到從庫執行後可能造成主從不一致
從節點未設定唯讀，誤操作寫入資料
主從實例版本不一致，特別是高版本是主，低版本為從的情況下，主資料庫上面支援的功能，從資料庫上面可能不支援該功能
MySql的BUG
#那麼在使用時就需要注意以下這些事項
主庫binlog採用ROW格式
主從實例資料庫版本保持一致
主庫做好帳號權限把控，不可以執行set sql_log_bin=0
從函式庫開啟只讀，不允許人為寫入
定期進行主從一致性檢定
關於叢集
叢集最大的優點就是資料即時同步，高可用，每個節點的資料都是同步一致的，不像主從，有時會出現資料不一致，而高可用，任何一個節點宕機都不會影響業務。
但是缺點就是性能，寫的性能，每次寫操作，都會在所有節點之間進行同步，有失有得，損失了一點性能，保證了高可用和數據一致。
在叢集中，管理節點有一個，SQL節點和資料節點都是多個， 資料節點之間採用的是同步複製來確保各節點之間的資料一致性，一般透過兩階段提交協定來實現，一般工作過程如下
Master執行提交語句時，事務被傳送到slave，slave開始準備事務的提交
每個slave都要準備事務，然後向master發送OK(或ABORT)訊息，表明事務已經準備好（或無法準備該事務）
Master等待所有Slave發送OK或ABORT訊息
如果Master收到所有Slave的OK訊息，它就會向所有Slave發送提交訊息，告訴Slave提交該交易；
如果Master收到來自任何一個Slave的ABORT訊息，它就向所有Slave發送ABORT訊息，告訴Slave去中止事務。
每個Slave等待來自Master的OK或ABORT訊息
如果Slave收到提交請求，它們就會提交事務，並向Master發送交易已提交的確認；
如果Slave收到取消請求,它們就會撤銷所有改變並釋放所佔有的資源，從而中止事務，然後向Masterv送事務已中止的確認。
當Master收到來自所有Slave的確認後，就會報告該交易被提交（或中止），然後繼續進行下一個事務處理
由於同步複製一共需要4次訊息傳遞，所以mysql cluster的資料更新速度比單機mysql慢。於是mysql cluster要求運作在千兆以上的區域網路內，節點可以採用雙網路卡，節點群組之間採用直連方式以確保資料更新速度。
以上是mysql集群和主從的區別的詳細內容。更多資訊請關注PHP中文網其他相關文章！
