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要求運行在千兆以上的局域網內，節點可以采用雙網卡，節點組之間采用直連方式以保證數據更新速度。
