数据库原理——主从复制

数据库原理——主从复制

1. 主从复制

wps1647.tmp

箭头顺序依次从左到右

注:slave端也有 binlog

延迟分析

  • 读写:

    • Data changes: 顺序的写操作,比较快,不太会发生延迟。一个大文件和多个小文件相比,大文件读取更快(顺序读写),因为小文件需要频繁多次寻址(随机读写)。kafka消息队列,数据放在磁盘上,只支持append操作(append的大多数是顺序读写),包括大数据分布式的也是,不支持Insert和update

    • I/O Thread读操作:顺序读取,几乎不延迟。(异地,不在同一个局域网,用专用光纤传输,此处不要省钱)

    • I/O Thread 顺序写入 Relay log,无延迟

    • SQL Thread读取Relay log: 顺序读

    • SQL Thread 写的时候(找到对应的sql语句进行修改)是随机的,可能会延迟

      • 例如:update table set name=zhiang where id=1
      • update table set name lsi where id=200

      注:append是顺序的,update和insert是随机的

  • 整体流程分析:

    • 前面都是顺序的,不延迟
    • 只在SQL Thread写时延迟,因为是随机读写的
    • 可能会造成relay log堆积

怎么解决延迟问题

MTS:multi-thread salve

在这里插入图片描述

SQL Thread并行复制,多线程
并行复制的粒度:库、表、行
查看粒度: show variables like’%parallel%’
会显示slave_parallel_type = DATABASE(这是库级别的)|| ROW(行)

2. 主从复制延迟产生的原因

  1. 备库机器性能比主库差
  2. 主库主要是写,备库主要读,若查询压力大,备库的查询消耗大量CPU资源,影响同步速度
  3. 大事务执行,如果主库的一个事务执行了10分钟,而binlog的写入必须要等待事务完成之后,才会传入备库,那么在开始执行时就延迟了
  4. 主库的写操作是顺序写binlog,从库单线程去主库顺序读binlog,从库取到binlog之后再本地执行。mysql的主从复制都是单线程操作,但由于主库是顺序写的,所以效率很高,而从库也是顺序读取主库的日志,此时的效率也比较高,但当数据拉取回来之后变成了随机操作,而不是顺序的,所以成本会提高。
  5. 从库在同步数据的同时,可能跟其他查询的线程发生锁抢占情况,也会发生延迟
  6. 当主库的TPS(服务器每秒处理的事务数)并发非常高时,产生的DDL数量超过了一个线程所能承受的范围,那么也可能会带来延迟
  7. 在进行binlog日志传输的时候,如果网络带宽不是很好,网络延迟也会造成数据同步延迟

3. 如何解决复制延迟问题

Mysql版本5.6之后引入并行复制的概念

问题

  1. 在并行操作(多个worker并行)的时候,可能会有并发的事务问题,我们的备库在执行的时候可以按照轮训的方式发送给各个worker吗? 不可以
  2. 同一个事务的不同sql语句,可以分发给不同的worker执行? 不可以

规则

  1. 更新同一行的多个事务,必须要分发到同一个worker中执行

  2. 同一个事务不能被拆开,必须要放到同一个worker中执行

    库——》worker上必须要加标识——》db

    表——》worker上必须要加标识——》库名:表名

    行——》worker上必须要加标识——》库名:表名+唯一值(不一定是主键)

GTID:全局事务ID

由两部分组成:服务器的唯一标识 + 递增的事务id

GTID工作原理简单介绍

  1. master更新数据的时候,会在事务前产生GTID,一同记录到binlog日志中。
  2. slave端的io线程将binlog写入到本地relay log中。
  3. 然后SQL线程从relay log中读取GTID,设置gtid_next的值为该gtid,然后对比slave端的binlog是否有记录
  4. 如果有记录的话,说明该GTID的事务已经运行,slave会忽略
  5. 如果没有记录的话,slave就会执行该GTID对应的事务,并记录到binlog中

参考

4. 并行复制策略

--查看并行的slave的线程的个数,默认是0,表示单线程,worker与核心CPU数保持一致最佳8~16
show global variables like 'slave_parallel_workers';
--设置并发复制方式:库、表
show global variables like '%slave_parallel_types%';

如何写binlog日志——》二阶段提交

数据更新流程
1.执行器先从引擎中找到数据,如果在内存中直接返回,如果不在内存中,查询后返回
2.执行器拿到数据之后会先修改数据,然后调用引擎接口重新写入数据
3. 引擎将数据更新到内存,同时写数据到redo中,此时处于prepare阶段,并通知执行器执行完成,随时可以操作
4. 执行器生成这个操作的binlog
5. 执行器调用引擎的事务提交接口,引擎把刚刚写完的redo改成commit状态,更新完成

redo log的两阶段提交/两个日志必须同时写

  • 先写redo log后写binlog:
    redo log写完之后,系统即使崩溃,仍然能够把数据恢复回来。但由于binlog没写完,这时候binlog里就没有记录这个语句。因此,之后备份日志的时候,存起来的binlog里就没有这条语句,这时,若用binlog恢复临时库会少一次更新,与原库不一致。
  • 先写binlog后写redo log:
    如果binlog写完之后crash,由于redo log还没写,崩溃恢复以后这个事务无效,但用binlog恢复时多了一个事务,与原库不一致。

mysql5.7版本,根据mariaDB的并行复制策略,做了相应的优化调整后,提供了自己的并行复制策略,并且可通过参数slave-parallel-type来控制并行复制的策略:

  1. 当配置的值为databse时,表示使用5.6版本的按库并行策略
  2. 当为logical_clock时,表示跟mariaDB相同的策略。

同时处于执行状态的所有事务,是否可以并行?
不可以。因为多个执行中的事务是由可能出现锁冲突的,锁冲突之后会产生锁等待问题。

mysql5.7的并行复制策略的思想:(基于组提交)

  1. 同时处于prepare状态的事务,在备库执行时可以并行的
  2. 处于prepare状态的事务,与处于commit状态的事务之间,在备库上执行也是可以并行的。

以下讨论的前提 是设置MySQL的crash safe相关参数为双1:
sync_binlog=1
innodb_flush_log_at_trx_commit=1
组提交
是mysql处理日志的一种优化方式,主要为了解决写日志时频繁刷磁盘的问题。组提交伴随着Mysql的发展,已经支持了redo log和bin log组提交。
组提交的作用:

  • 在没有开启binlog时,Redo log的刷盘操作将会是最终影响MySQL TPS的瓶颈所在。为了缓解这一问题,MySQL使用了组提交,将多个刷盘操作合并成一个,如果说10个事务依次排队刷盘的时间成本是10,那么将这10个事务一次性一起刷盘的时间成本则近似于1。
  • 当开启binlog时为了保证Redo log和binlog的数据一致性,MySQL使用了二阶段提交,由binlog作为事务的协调者。而 引入二阶段提交 使得binlog又成为了性能瓶颈,先前的Redo log 组提交 也成了摆设。为了再次缓解这一问题,MySQL增加了binlog的组提交,目的同样是将binlog的多个刷盘操作合并成一个,结合Redo log本身已经实现的 组提交,分为三个阶段(Flush 阶段、Sync 阶段、Commit 阶段)完成binlog 组提交,最大化每次刷盘的收益,弱化磁盘瓶颈,提高性能。
    MySQL组提交

基于这样的处理机制,可以将大部分的日志处于prepare状态,因此可以设置:

  1. binlog_group_commit_sync_delay参数,表示延迟多少微妙采用fsync
  2. binlog_group_commit_sync_no_delay_count参数,表示累积多少次后才调用fsync
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/100173.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)
blank

相关推荐

  • opencv环境的搭建,并打开一个本地PC摄像头。

    opencv环境的搭建,并打开一个本地PC摄像头。

  • Solr之配置DataImport

    1、拷贝将/opt/solr/solr-7.3.1下的dist和contrib目录拷贝到/opt/solr/solrhome目录下.2、相关jar包拷贝solr-dataimporthandler-7.3.1.jar和solr-dataimporthandler-extras-7.3.1.jar包拷贝到/opt/tomcat/apache-tomcat-8.5.31/webapps/s…

  • FusionCharts參数中文说明

    FusionCharts參数中文说明

    2021年12月15日
  • SM4加密运算_数据加密标准des采用的密码类型是

    SM4加密运算_数据加密标准des采用的密码类型是javaSM4加密运算自己的理解:sm4加密,其实就是将字符串转成byte数组,再设置一个与解密相同的字符串,将byte的数据再转成二级制的数据,进行异或的运算,得到一组没有规则的字符串!案例上面是一些算法下面是应用方法这是自己的认知,有什么不同建议可以留言,XXXX是自己加密的字符串…

  • hikaripool信息_HikariPool源码(四)资源状态[通俗易懂]

    hikaripool信息_HikariPool源码(四)资源状态[通俗易懂]Java极客|作者/铿然一叶这是Java极客的第55篇原创文章1.本章目的了解池资源的状态,以及状态如何变迁,用于池化资源设计参考。2.HikariPool资源核心类回顾HikariPool资源相关的类如下:类说明:类职责HikariPool资源池,客户端资源操作的入口。ConcurrentBag通用的并发包工具。CopyOnWriteArrayList一个列表,用于存储资源,…

  • UML 包图

    UML 包图什么是包包可直接理解为命名空间,文件夹,是用来组织图形的封装,包图可以用来表述功能组命名空间的组织层次。•在面向对象软件开发的视角中,类显然是构建整个系统的基本构造块。但是对于庞大的应用系统而言,其包

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号