当前位置: 主页 > 香港六和彩出码表 >

聊聊 MySQL 的主从

时间:2022-04-02 08:20来源:未知 作者:admin 点击:

  是什么意思呢,主是主库的意思,从是从库的意思。数据库主库对外提供读写的操作,从库对外提供读的操作。

  主数据库有个 bin log 二进制文件,纪录了所有增删改 SQL 语句。(binlog线程)

  从数据库把主数据库的 bin log 文件的 SQL 语句复制到自己的中继日志 relay log (io线程)

  从数据库的 relay log 重做日志文件,再执行一次这些sql语句。(Sql执行线程)

  从库启动之后,创建一个 I/O 线程,读取主库传过来的 bin log 内容并写入到 relay log

  从库还会创建一个SQL线程,从 relay log 里面读取内容,从 ExecMasterLog_Pos 位置开始执行读取到的更新事件,将更新内容写入到 slave 的db

  数据库主主:两台都是主数据库,同时对外提供读写操作。客户端访问任意一台。数据存在双向同步。

  数据库主从:一台是主数据库,同时对外提供读写操作。一台是从数据库,对外提供读的操作。数据从主库同步到从库。

  数据库主备:一台是主数据库,同时对外提供读写操作。一台是备库,只作为备份作用,不对外提供读写,主机挂了它就取而代之。数据从主库同步到备库。

  从库和备库,就是slave库功能不同因此叫法才不一样而已。一般slave库都会对外提供读的功能的,因此,大家日常听得比较多就是主从。

  我们学习数据库的主从复制原理后,了解到从库拿到并执行主库的binlog日志,就可以保持数据与主库一致了。这是为什么呢?哪些情况会导致不一致呢?

  主库和从库在同步数据的过程中断怎么办呢,数据不就会丢失了嘛。因此主库与从库之间维持了一个长链接,主库内部有一个线程,专门服务于从库的这个长链接的。

  如果是 statement 格式,binlog记录的是SQL的原文,如果主库和从库选的索引不一致,可能会导致主库不一致。我们来分析一下。假设主库执行删除这个SQL(其中 a和create_time 都有索引)如下:

  我们知道,数据库选择了 a 索引和选择 create_time 索引,最后 limit 1 出来的数据一般是不一样的。所以就会存在这种情况:在binlog = statement 格式时,主库在执行这条SQL时,使用的是索引a,而从库在执行这条SQL时,使用了索引 create_time 。壮元红高手论坛39333,最后主从数据不一致了。

  但是如果SQL删除10万行数据,使用row格式就会很占空间的,10万条数据都在binlog里面,写binlog的时候也很耗IO。但是 statement 格式的binlog可能会导致数据不一致,因此设计MySQL的大叔想了一个折中的方案, mixed 格式的binlog。所谓的mixed格式其实就是 row 和 statement 格式混合使用,当MySQL判断可能数据不一致时,就用 row 格式,否则使用就用 statement 格式。

  所谓主从延迟,其实就是指同一个事务,在从库执行完的时间和在主库执行完的时间差值,即 T3-T1 。

  如果从库所在的机器比主库的机器性能差,会导致主从延迟,这种情况比较好解决,只需选择主从库一样规格的机器就好。

  如果从库的压力大,也会导致主从延迟。比如主库直接影响业务的,大家可能使用会比较克制,因此一般查询都打到从库了,结果导致从库查询消耗大量CPU,影响同步速度,最后导致主从延迟。这种情况的话,可以搞了一主多从的架构,即多接几个从库分摊读的压力。另外,还可以把binlog接入到Hadoop这类系统,让它们提供查询的能力。

  大事务也会导致主从延迟。如果一个事务执行就要10分钟,那么主库执行完后,给到从库执行,最后这个事务可能就会导致从库延迟10分钟啦。日常开发中,我们为什么特别强调,不要一次性delete太多SQL,需要分批进行,其实也是为了避免大事务。另外,大表的DDL语句,也会导致大事务,大家日常开发关注一下哈。

  网络延迟也会导致主从延迟,这种情况你只能优化你的网络啦,比如带宽20M升级到100M类似意思等。

  如果从数据库过多也会导致主从延迟,因此要避免复制的从节点数量过多。从库数据一般以3-5个为宜。

  低版本的MySQL只支持单线程复制,如果主库并发高,来不及传送到从库,就会导致延迟。可以换用更高版本的Mysql,可以支持多线. 聊聊数据的库高可用方案

  声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。