1.目的
MySQL 主从复制（Master-Slave Replication）是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用，有以下几个主要用途：
- 高可用：主从复制通过在多个服务器之间复制数据，提供了数据冗余和高可用。如果主数据库发生故障，从数据库可以接管，确保系统继续运行。
- 高性能：主从复制支持读写分离，即读操作可以路由到从服务器，而写操作仍然由主服务器处理。这有助于提高读操作的性能，减轻主服务器的负载。
- 备份容灾：从服务器可以用于数据库备份目的。备份可以在不影响主服务器性能的情况下进行，而且备份可以是实时的，以确保数据安全。
MySQL 主从复制提供了高可用性、高性能、备份灾难等关键功能，使其成为许多企业和组织在数据库管理中的重要工具。有了主从复制，MySQL 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活调整。
2.主从架构
- 一主一从
- 一主多从
一主一从和一主多从是最常见的主从架构，使用起来简单有效，不仅可以实现 HA，而且还能读写分离，进而提升集群的并发能力。
- 多主一从
多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上。
- 双主复制
双主复制，也就是可以互做主从复制，每个 master 既是 master，又是另外一台服务器的 salve。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
- 级联复制
级联复制模式下，部分 slave 的数据同步不连接主节点，而是连接从节点。
因为如果主节点有太多的从节点，就会损耗一部分性能用于 replication ，那么我们可以让 3~5 个从节点连接主节点，其它从节点作为二级或者三级与从节点连接。这样不仅可以缓解主节点压力，并且对数据一致性没有负面影响。
级联复制解决了一主多从场景下多个从库复制对主库的压力，带来的弊端就是数据同步延迟比较大。
3.主从复制原理
要实施主从复制，必须打开 Master 端的 Binlog 功能，否则无法实现。
整个复制过程实际上就是 Slave 从 Master 获取 binlog 后，再顺序地执行（重放）日志记录的各种操作。
主从复制过程如下：
- master 将变更记录到二进制日志（binary log）。
- slave 通过 I/O 线程与 maste 建立长连接，master 为 slave 创建 log dump 线程，将 binlog 发送给 slave。
- 后续当 binlog 有变动时，log dump 线程会将变动通过 I/O 线程推给 slave。
- slave I/O 线程将 binlog 写入它的中继日志（relay log）。
- 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 在恢复时会，需要更多的行级锁，影响恢复效率。
INSERT ... SELECT
UPDATE ... WHERE 没有命中索引导致锁表
ROW
在 ROW 模式下，Binlog 记录的是实际行数据的更改。具体来说，它会记录哪些行被插入、更新或删除，以及这些行的新值。
优点：
- 复制数据非常精确，不会出现非确定函数或存储过程、存储函数、触发器的调用导致数据不一致。
- 某些类型的语句，恢复时需要更少的行锁，从而实现更高的并发性。
INSERT ... SELECT
INSERT statements with AUTO_INCREMENT
UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
缺点：
- 但生成的 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 主从复制是推拉结合。
参考文献
17.2 Replication Implementation - MySQL 看完这篇还不懂MySQL主从复制，可以回家躺平了 - 腾讯云 主从同步中的关键技术解析 - 腾讯云 主从不一致解决方案&& 如何降低主从延迟 - 阿里云MySQL主从不一致情形与解决方法原创 - CSDN