[华为云在线课程][7天玩转MySQL基础实战营][day06高可用][学习笔记]

举报
John2021 发表于 2022/02/27 14:19:37 2022/02/27
【摘要】 MySQL replication概述复制使来自一个MySQL数据库服务器(称为源/主库)的数据能够复制到一个或多个MySQL数据库服务器(称为副本/从/备/只读库)默认情况下,复制是异步的复制使得MySQL从单机走向集群异步复制:源(A库)发送事务的更新到副本(B库),源(A库)上事务的提交不等待副本(B库)的任何反馈副本(B库)不需要永久连接源(A库)根据配置,副本(B库)可以复制源(...

MySQL replication概述

  • 复制使来自一个MySQL数据库服务器(称为源/主库)的数据能够复制到一个或多个MySQL数据库服务器(称为副本/从/备/只读库)

  • 默认情况下,复制是异步的

  • 复制使得MySQL从单机走向集群

  • 异步复制:

    • 源(A库)发送事务的更新到副本(B库),源(A库)上事务的提交不等待副本(B库)的任何反馈
    • 副本(B库)不需要永久连接源(A库)
    • 根据配置,副本(B库)可以复制源(A库)中的所有数据库、选定的数据库,甚至选定的表。
  • 半同步复制:内置异步复制,源(A库)发送事务的更新到副本(B库),源(A库)上事务的提交需要等待副本(B库)接收到这个事务的反馈

  • 半同步复制包括两种复制状态:同步复制状态和异步复制状态,绝大多数情况下处于同步复制状态,在网络闪断和大事务的情况下为了保护主库的高性能,自动转换为异步复制状态,副本库追赶上源库后,会自动转换为同步复制状态。

  • 半同步复制实际上是弹性同步复制,自推出以来,被广泛使用。

  • DML和DDL语句对源数据库产生的改变会被写入BINLOG,然后被复制到副本数据库

  • SELECT语句不对数据库产生改变,所以不会被复制到副本数据库

  • 副本数据库也可以把DML和DDL语句对数据库产生的改变写入BINLOG

MySQL replication拓扑

  • 简单拓扑

  • 链式拓扑

  • 任意拓扑

The binary log

The binary log是什么?

  • 是连续的逻辑流,记录主库正在发生的改变

  • 这个逻辑流会被持久化到文件中

  • 每个事务都包含一组LOG EVENTS,始于GTID LOG EVENT,终于COMMIT LOG EVENT。如下图所示:

  • 注:The binary log简称binlog

The binary log有什么用途?

  • 实现数据流式复制,是MySQL replication的根基
  • 保存数据库的变化历史
  • 使得MySQL从单机走向集群
  • BINLOG的格式非常的规范和标准,因而社区有很多基于BINLOG的工具,进而产生了极强的MySQL生态粘性
  • 是平滑迁移的基础
  • 基于任意时间点的恢复

The binary log持久化在哪里?

  • 持久化在一组文件中
    • 主库正在发生的变化被持久化在一组文件中,这组文件的后缀是递增的
    • 这组文件的名字保存在一个索引文件中,比如:binlog.index

多线程只读库和备库

  • 协调者从relay log(中继日志)中读取事务,并且安排这些事务给多个工作者
  • 多个工作者可以并发执行在主库上并发执行的事务,能跟上主库吗?

自动连接

自动连接 - 有什么用途?

  • 备库和只读库崩溃恢复后,能够自动连接到主库继续复制
  • 主库和备库切换后,只读库能自动连接到新主库继续复制
  • 减少了维护成本和中断时间
  • 增加了集群的可用性
  • 支持任意拓扑,如下图所示:

自动连接 - 基于什么做到的?

  • 自动连接是基于GTID做到的

  • 主库给每个事务分配一个全局事务标识符(GTID)

    • 全局事务标识符由server_uuid:number组成,例如:a61678ba-4889-4279-9e58:1
    • server_uuid标识一个数据库并且是全局唯一的
    • number是同一个数据库上的每个事务的编号,每个事务递增一
  • 写全局事务标识符(GTID)到binlog中,每个事务一个GTID

自动连接 - 怎么做到的?

  • 副本(B库)重新执行来自源(A库)的事务时会保存这个事务原有的GTID
  • 副本通过GTID做到不会重新执行同一个事务两次
  • 源与副本之间的协议:
    • 副本发送已经执行的事务的GTID集合到源
    • 源发送所有其他的事务到副本

高可靠怎么做到的?

高可靠怎么做到的 - 同步复制状态

  • 主库与备库之间是半同步复制关系,绝大多数情况下处于半同步复制的同步复制状态
  • 在同步复制状态下,主库崩溃,直接切换到备库,备库升级成新主库对外服务

高可靠怎么做到的 - 异步复制状态

  • 网络闪断或主库执行大事务时,半同步复制处于异步复制状态下,此时主库崩溃,必须把主库拉起(为什么?),对外服务,中断时间稍长。

高可靠怎么做到的 - 手动切换原理

  • 主库与备库支持手动切换,手动切换后,主库降级成新备库,备库升级成新主库

异地灾备怎么做到的?

  • 主库通过DRS异步复制到异地灾难备库,为什么不是半同步复制?
  • 主库和备库所在区域不可用时,异地灾难备库升级成主库对外服务。

异地灾备 - 双活

  • 主库A通过DRS异步复制事务到主库B,同时主库B通过DRS异步复制事务到主库A
  • 主库A与备库A之间是半同步复制关系
  • 主库B与备库B之间是半同步复制关系

高性能的只读库和备库

  • 只读库和备库的并发度低于主库的并发度

    • 导致只读库复制延迟比较大
    • 导致主备切换中断的时间长
  • 通过非持久化的技术,事务在内存中执行和提交,很大地提高了只读库和备库的性能,缩短了复制延迟

  • 事务提交不持久化,怎么保证只读库和备库崩溃后事务不丢失?

    • 没有被持久化事务在数据库崩溃重启后是丢失了的
    • 但是这些丢失了的事务可以通过基于GTID的自动连接从主库上重新拉取过来,重新执行。
    • 为什么主库不能使用非持久化的技术?

怎么恢复到任意指定的时刻?

  • 数据库崩溃后,怎么恢复到任意指定的时刻?
    • binlog保存了数据库的变化历史,所以回放这些binlog到指定的时刻,就能把数据库恢复到指定的时刻
    • 华为云RDS for MySQL主库定期做全量备份,以这个全量备份为基础,回放增量的binlog到指定的时刻,就能把数据库恢复到指定的时刻
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200