Mysql的“主从”和“集群”

发布于 2020-01-12  217 次阅读


主从之间是通过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
  • 从库开启只读,不允许人为写入
  • 定期进行主从一致性检验

本博客这篇文章 https://loneking.cn/server/493 讲了MySql主从读写分离及其部署

关于集群

集群最大的优点就是数据实时同步高可用,每个节点的数据都是同步一致的,不像主从,有时会出现数据不一致,而高可用,任何一个节点宕机都不会影响业务。

但是缺点就是性能,写的性能,每次写操作,都会在所有节点之间进行同步,有失有得,损失了一点性能,保证了高可用和数据一致。

在集群中,管理节点有一个,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要求运行在千兆以上的局域网内,节点可以采用双网卡,节点组之间采用直连方式以保证数据更新速度。