mysql集群和主从的区别

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集群和主从的区别的详细内容，更多请关注其它相关文章！