华为OD技术面真题 - Mysql相关 - 4

简单介绍一下Mysql中BinLog、RedoLog和UndoLog

RedoLog

重做日志是 InnoDB 存储引擎独有的，它让 MySQL 拥有了崩溃恢复能力。在MySQL 实例挂了或宕机了，重启时，InnoDB 存储引擎会使用 Redolog 恢复数据，保证数据的持久性与完整性。

redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎独有。

BinLog

Binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server层。不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。

MySQL 数据库的数据备份、主备、主主、主从都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。

binlog记录日hi有三种格式，通过binlog_format参数指定

• statement：记录的内容是SQL语句原文。对于这类SQL语句update T set update_time=now() where id=1，now()函数直接执行会导致与原库的数据不一致。
• row: 记录的内容不再是简单的SQL语句了，还包含操作的具体数据。不只记录SQL语句同时记录具体数据。缺点：需要更多容量来记录。
• mixed: MySQL 会判断这条SQL语句是否可能引起数据不一致，如果是，就用row格式，否则就用statement格式。

UndoLog

每一个事务对数据的修改都会被记录到 undolog ，当执行事务过程中出现错误或者需要执行回滚操作的话，MySQL 可以利用 undo log 将数据恢复到事务开始之前的状态。

undo log 属于逻辑日志，记录的是 SQL 语句，比如说事务执行一条 DELETE 语句，那 undo log 就会记录一条相对应的 INSERT 语句。同时，undo log 的信息也会被记录到 redo log 中，因为 undo log 也要实现持久性保护。undo-log 本身是会被删除清理的.

Mysql中事务为什么需要两阶段提交

在未开启两阶段提交时，可能出现 redo log 写入成功但 binlog 写入失败（或者反之），导致主从库数据不同步。两阶段提交通过将 Redo log 状态标记为 Prepare，充当了协调者，确保了崩溃恢复（Crash-Safe）时可以一致地提交或回滚事务。

简单介绍一下两阶段提交的流程

• 准备阶段：
  • 执行SQL修改数据，将修改记录写入 redo log，并将该条 redo log 标记为prepare状态。
  • 将该事务的 XID（内部事务ID）写入 redo log，并持久化到磁盘。
• 提交阶段：
  • 将该事务的 SQL 语句写入 binlog，并将 binlog 持久化到磁盘
  • 将 redo log 中的事务状态修改为commit状态，标志事务提交成功

什么是读写分离

读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。这样的话，就能够小幅提升写性能，大幅提升读性能。

一般情况下，我们都会选择一主多从，也就是一台主数据库负责写，其他的从数据库负责读。主库和从库之间会进行数据同步，以保证从库中数据的准确性。这样的架构实现起来比较简单，并且也符合系统的写少读多的特点。

怎样实现读写分离

实现读写分离一般包含以下几步：

1. 部署多台数据库，选择其中的一台作为主数据库，其他的一台或者多台作为从数据库。
2. 保证主数据库和从数据库之间的数据是实时同步的，这个过程也就是我们常说的主从复制。
3. 系统将写请求交给主数据库处理，读请求交给从数据库处理。

常见实现方案：

1. 代理方式：应用和数据中间加了一个代理层。应用程序所有的数据请求都交给代理层处理，代理层负责分离读写请求，将它们路由到对应的数据库中。可使用中间件MyCat和Mysql Router等。
2. 组件实现：通过引入第三方组件来帮助我们读写请求。例如sharding-jdbc.

说说Mysql主从复制流程

主要涉及三个线程: binlog 线程、I/O 线程和 SQL 线程。

• binlog 线程: 负责将主服务器上的数据更改写入二进制日志中。
• I/O 线程: 负责从主服务器上读取二进制日志，并写入从服务器的中继日志中。
• SQL 线程: 负责读取中继日志并重放其中的 SQL 语句

主从复制流程基本流程：

• 主库将数据库中数据的变化写入到 binlog
• 从库连接主库
• 从库会创建一个 I/O 线程向主库请求更新的 binlog
• 主库会创建一个 binlog dump 线程来发送 binlog ，从库中的 I/O 线程负责接收
• 从库的 I/O 线程将接收的 binlog 写入到 relay log 中。
• 从库的 SQL 线程读取 relay log 同步数据到本地。

主从复制分为全同步复制和半同步复制，不同之处：

• 全同步复制：主库写入binlog后强制同步日志到从库，所有的从库都执行完成后才返回给客户端。这种方式严重影响性能。
• 半同步复制：从库写入日志成功后返回ACK确认给主库，主库收到至少一个从库的确认就认为写操作完成。

怎么避免主从延迟

读写分离对于提升数据库的并发非常有效，但是，同时也会引来一个问题：主库和从库的数据存在延迟，比如你写完主库之后，主库的数据同步到从库是需要时间的，这个时间差就导致了主库和从库的数据不一致性问题。这也就是我们经常说的主从同步延迟。

因为存在主从延迟问题，为了改善主从延迟造成读取过期数据主要有以下两种方案：

• 对于强实时性业务场景，可强制读取主库，避免读取过期树。
• 对于一些对数据比较敏感的场景，你可以在完成写请求之后，避免立即进行请求操作，延迟进行读取。这个需要考虑到业务场景，同时延迟多少也是一个值得商榷的问题。