mysql中集群和主从的区别:主从之间是通过mysql的replication来保证数据的一致性;相对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要求运行在千兆以上的局域网内,节点可以采用双网卡,节点组之间采用直连方式以保证数据更新速度。