14_MySQL日志和主从复制原理

Justinyh

已于 2023-01-17 17:55:56 修改

阅读量332

点赞数 1

分类专栏：数据库文章标签： mysql 数据库 java

于 2022-12-23 16:02:48 首次发布

本文链接：https://blog.csdn.net/qq_38926742/article/details/128419946

版权

数据库专栏收录该内容

20 篇文章 0 订阅

订阅专栏

系列文章目录

一、日志类型

慢查询日志：记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。
通用查询日志：记录所有连接的起始时间和终止时间，以及连接发送给数据库服务器的所有指令，对我们复原操作的实际场景、发现问题，甚至是对数据库操作的审计都有很大的帮助。
错误日志：记录MySQL服务的启动、运行或停止MySQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。
二进制日志：记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。
中继日志：用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
数据定义语句日志：记录数据定义语句执行的元数据操作。

二、主从复制概述

2.1、主从复制的作用

1、读写分离

2、数据备份
3、使系统具有高可用性

2.1、主从复制的原理

在主从复制过程中，会基于 3 个线程来操作，一个主库线程，两个从库线程。
在这里插入图片描述 二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候，主库可以将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志（Relay log）。
从库 SQL 线程会读取从库中的中继日志，执行日志中的事件，将从库中的数据与主库保持同步。

复制三步骤
步骤1： Master 将写操作记录到二进制日志（ binlog ）。
步骤2： Slave 将Master 的binary log events拷贝到它的中继日志（ relay log ）；
步骤3： Slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的，而且重启后从接入点开始复制。

三、同步数据一致性问题

主从同步的要求：

读库和写库的数据一致(最终一致)；
写数据必须写到写库；
读数据必须到读库(不一定)；

3.1、主从延时问题

网络传输的过程中就一定会存在主从延迟（比如 500ms），这样就可能造成用户在从库上读取的数据不是最新的数据，也就是主从同步中的数据不一致性问题。主备延迟最直接的表现是，从库消费中继日志（relay log）的速度，比主库生产binlog的速度要慢。
因为：
1、从库的机器性能比主库要差
2、从库的压力大
3、大事务的执行

3.2、如何减少主从延迟

降低多线程大事务并发的概率，优化业务逻辑
优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成。
提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。
尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输
的网络延时。
实时性要求的业务读强制走主库，从库只做灾备，备份。

3.3、如何解决一致性问题

按照数据一致性从弱到强来进行划分，有以下 3 种复制方式。
方法 1：异步复制
在这里插入图片描述 方法 2：半同步复制

主库增删改的时候，会等从库复制了并且通知了主库，才会把这个操作叫做成功。
在这里插入图片描述 方法 3：组复制MGR
异步复制和半同步复制都无法最终保证数据的一致性问题，半同步复制是通过判断从库响应的个数来决
定是否返回给客户端，虽然数据一致性相比于异步复制有提升，但仍然无法满足对数据一致性要求高的
场景，比如金融领域。MGR 很好地弥补了这两种复制模式的不足。
组复制技术，简称 MGR（MySQL Group Replication）。是 MySQL 在 5.7.17 版本中推出的一种新的数据复制技术，这种复制技术是基于 Paxos 协议的状态机复制。

MGR 是如何工作的
首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层
（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节
点）的同意，大多数指的是同意的节点数量需要大于（N/2+1），这样才可以进行提交，而不是原发起
方一个说了算。而针对只读（RO）事务则不需要经过组内同意，直接 COMMIT 即可。
在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消
息和全局有序消息，从而保证组内数据的一致性。
在这里插入图片描述
MGR 将 MySQL 带入了数据强一致性的时代，是一个划时代的创新，其中一个重要的原因就是MGR 是基于 Paxos 协议的。Paxos 算法是由 2013 年的图灵奖获得者 Leslie Lamport 于 1990 年提出的，有关这个算法的决策机制可以搜一下。事实上，Paxos 算法提出来之后就作为分布式一致性算法被广泛应用，比如Apache 的 ZooKeeper 也是基于 Paxos 实现的。