MySQL 主从复制原理与问题

MySQL 主从复制原理与问题

MySQL主从复制是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用。本文将详细介绍MySQL主从复制的目的、架构、原理、binlog格式、复制方式以及可能遇到的问题和解决方案。

1. 目的

MySQL主从复制（Master-Slave Replication）是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用，有以下几个主要用途：

• 高可用：主从复制通过在多个服务器之间复制数据，提供了数据冗余和高可用。如果主数据库发生故障，从数据库可以接管，确保系统继续运行。
• 高性能：主从复制支持读写分离，即读操作可以路由到从服务器，而写操作仍然由主服务器处理。这有助于提高读操作的性能，减轻主服务器的负载。
• 备份容灾：从服务器可以用于数据库备份目的。备份可以在不影响主服务器性能的情况下进行，而且备份可以是实时的，以确保数据安全。

MySQL主从复制提供了高可用性、高性能、备份灾难等关键功能，使其成为许多企业和组织在数据库管理中的重要工具。有了主从复制，MySQL的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活调整。

2. 主从架构

• 一主一从
  
• 一主多从
  
  一主一从和一主多从是最常见的主从架构，使用起来简单有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。
• 多主一从
  
  多主一从可以将多个MySQL数据库备份到一台存储性能比较好的服务器上。
• 双主复制
  
  双主复制，也就是可以互做主从复制，每个master既是master，又是另外一台服务器的salve。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
• 级联复制
  级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。
  因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接。这样不仅可以缓解主节点压力，并且对数据一致性没有负面影响。
  级联复制解决了一主多从场景下多个从库复制对主库的压力，带来的弊端就是数据同步延迟比较大。

3. 主从复制原理

要实施主从复制，必须打开Master端的Binlog功能，否则无法实现。
整个复制过程实际上就是Slave从Master获取binlog后，再顺序地执行（重放）日志记录的各种操作。
主从复制过程如下：

1. master将变更记录到二进制日志（binary log）。
2. slave通过I/O线程与maste建立长连接，master为slave创建log dump线程，将binlog发送给slave。
3. 后续当binlog有变动时，log dump线程会将变动通过I/O线程推给slave。
4. slave I/O线程将binlog写入它的中继日志（relay log）。
5. slave SQL线程解析中继日志（relay log），将变更应用到从数据库。

主从复制涉及三个线程：

• 主节点log dump线程
  当从节点连接主节点时，主节点会为其创建一个log dump线程，用于发送和读取Binlog的内容。在读取Binlog中的操作时，dump线程会对主节点上的Binlog加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为每一个从节点创建一个dump线程。
• 从节点I/O线程
  当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的Binlog。I/O线程接收到主节点的log dump线程发来的更新之后，保存到本地中继日志（relay log）。
• 从节点SQL线程
  SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
  对于每一个主从连接，都需要这三个线程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个log dump线程，而每个从节点都有自己的I/O线程和SQL线程。
  从节点将从主库拉取更新和执行分成独立的两个任务，使用两个线程来完成，这样在执行数据同步任务的时候，不会降低读操作的性能。比如，如果从节点SQL线程没有运行，此时I/O线程可以很快从主节点获取更新。如果在SQL线程执行之前从节点服务停止，至少I/O线程已经从主节点拉取到了最新的变更并且保存在本地relay log中，当服务再次起来之后就可以完成数据的同步。

4. binlog三种格式

STATEMENT

STATEMENT格式Binlog记录的是SQL语句，而不是行数据。
优点：

• Binlog文件相对较小。当更新或删除影响许多行时，这将大大减少日志文件所需的存储空间。这也意味着从备份中获取和恢复可以更快地完成。
• 日志文件包含所有变更语句，因此它们可用于审计数据库。
  缺点：
• 不够精确，因为某些操作可能无法精确还原。比如使用随机函数或非确定性存储过程。
• 某些SQL在恢复时会，需要更多的行级锁，影响恢复效率。

ROW

在ROW模式下，Binlog记录的是实际行数据的更改。具体来说，它会记录哪些行被插入、更新或删除，以及这些行的新值。
优点：

• 复制数据非常精确，不会出现非确定函数或存储过程、存储函数、触发器的调用导致数据不一致。
• 某些类型的语句，恢复时需要更少的行锁，从而实现更高的并发性。
  缺点：
• 但生成的Binlog文件通常较大，比如UPDATE或DELETE操作。
• 在某些情况下可能会影响主库的性能，尤其是在大量更新操作时。

MIXED

STATEMENT和ROW格式各有优缺点，MIXED格式结合了二者的优点，在保证「数据完整性」的情况下提供最佳的「复制性能」。
MIXED格式会根据具体情况来选择使用ROW记录或STATEMENT记录。这意味着对于某些更改，它将记录每一行数据的变化；而对于其他更改，它将记录执行的SQL语句。
这种模式在保持精确的同时，可以减小Binlog文件的大小。
从MySQL 5.1版本开始，MIXED成为了默认的binlog格式，以兼顾STATEMENT和ROW两种格式的优点。

5. 主从复制方式

5.1 异步复制

MySQL主从复制默认是异步复制。
主数据库执行写操作后，并将变更写入binlog，不等待从数据库应用这些变更，而是立即向客户端返回结果。
后续master通过log dump线程将binlog并发送给slave。slave把binlog存储到本地的relay log中，然后执行relay log的更新内容。
这个过程是异步的，所以称为异步复制。
这样就会有一个问题，主节点崩溃，此时主节点上已经提交的事务可能并没有传到从节点上。如果此时强行将从提升为主，可能导致新主节点上的数据不完整。

5.2 全同步复制

当主库执行完一个事务，然后所有的从都复制了该事务的binlog并写到relay log，主库才返回成功信息给客户端。
因为需要等待所有从库执行完该事务才能返回成功，所以全同步复制的性能必然会受到严重的影响。

5.3 半同步复制

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回客户端，而是等待至少一个从库接收到binlog并写到relay log中才返回成功信息给客户端，保证主库的binlog至少传输到了一个从节点上。
相对于异步与同步复制，半同步复制是对性能与数据一致性的权衡，保证主从最终一致。
半同步复制提高了数据的安全性，一定程度上保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步模式不是MySQL内置的，从MySQL 5.5开始集成，需要master和slave安装插件开启半同步模式。

6. 主从复制问题

数据丢失

当主库宕机后，数据可能丢失。
解决方法：使用半同步复制方式，可以解决数据丢失的问题。

同步延迟

主从延迟来自两个方面：从库进行binlog复制，从库日志回放。
从库复制binlog这个主要影响是网络带宽和网络稳定性，只能提高带宽来解决，没有什么更好的方式，所以这里更多讨论从库回放日志阶段导致的主从延迟。
从库一般是单线程重放relay log，所以如果主库写并发较大，可能导致从库单线程重放SQL压力较大，主从复制延迟较高。
所以优化思路就有2个，降低主库写并发和多线程重放SQL，提高重放效率。
（1）水平分库（降低主库写并发）
水平分库后单个分库的数据量降低，单个分库的写并发降低，从而降低从库重放SQL的排队时延，因而降低延迟。
（2）从库并行复制
升级至MySQL 5.7版本使用并行复制，官方称为Enhanced Multi-threaded Slaves，即多线程重放SQL，提高重放效率。

读写分离问题

主从同步有延迟，这个延迟期间读从库，会读到不一致的数据。
方法一：忽略。
大觉部分业务场景对主从同步延迟不敏感，如果业务可以接受，直接忽略。
方法二：放弃读写分离，强制读主。
读和写都落到主库上，在业务层面采用缓存来提升系统读性能。
方法三：选择性读主。
可以利用一个缓存key标记那些不容许主从不一致，也就是必须读主的数据，发生了更新，且设置缓存key的超时时间，超时时间设置为“主从同步时延”。同步延迟期间读主，同步完成后读从。

7. 主从复制是推还是拉？

binlog的同步可以是slave向master拉取（pull），也可以是master向slave推送（push），应该选择哪种方式？
“推”是指MySQL主库在有数据更新时推送变更给从库，这种方式只有在数据有变更的时候才会发生，资源消耗少，同步及时。
“拉”是指MySQL从库定期询问主库是否有数据更新，这种方式频繁询问，资源消耗多，效率低且同步延迟大。
那么MySQL具体是怎么同步binlog的呢？
slave与master建立连接之后，会把当前哪个binlog文件（MASTER_LOG_FILE）和具体偏移位置（MASTER_LOG_POS)告诉master。对应的，主库会启动一个log dump线程，根据传过来的（file，pos）在本地的binlog中查找，并把剩下的binlog发送给slave。这个过程是pull模式。
当主从数据一致之后，master收到的修改类操作，都会实时传播（propagate）给slave，此时属于push模式。
所以MySQL主从复制是推拉结合。