MYSQL-主从复制（Replication）介绍_复制(replication)—

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

数据库是一个系统（应用）最重要的资产之一，所以我们的数据库将从以下几个数据库来进行介绍。

MySQL（本章节）

PostgreSQL

MongoDB

Redis

Etcd

上个小节我们利用了MYSQL的Binlog日志进行恢复数据，但是这个是在主库无法连接的时候的兜底方案，并不适合拿来日常使用。下面就介绍一种适合在日常运维使用的方案：主从模式。

MySQL 主从模式是一种数据复制技术，它允许将一个 MySQL 数据库服务器（称为主服务器，Master）的数据自动同步到一个或多个其他 MySQL 数据库服务器（称为从服务器，Slave）。

其核心思想是：主服务器负责处理写操作（增、删、改），然后将这些操作记录下來，从服务器通过读取这些记录，在自己的数据库上重新执行一遍，从而保持与主数据库的数据一致性。

主从复制的核心是基于二进制日志（Binary Log, Binlog）。整个过程可以简化为三个步骤：

主库的更改记录（Master Side）：
- 当主服务器上发生数据变更（如 INSERT, UPDATE, DELETE）时，这些变更语句或变更后的数据行会被写入到主服务器的二进制日志文件中。
- 二进制日志就像是主数据库的“操作流水账”。
从库的获取与中转（Slave Side - I/O Thread）：
- 每个从服务器都有一个 I/O 线程。这个线程会连接到主服务器，并请求读取主服务器的二进制日志。
- 主服务器上有一个 Binlog Dump 线程，负责将二进制日志的内容发送给从服务器的 I/O 线程。
- 从服务器的 I/O 线程将接收到的日志内容写入到本地的中继日志（Relay Log） 中。
从库的重放执行（Slave Side - SQL Thread）：
- 从服务器上还有一个 SQL 线程。这个线程会读取本地的中继日志，并解析出其中记录的 SQL 语句（或行数据变更），然后在从数据库上逐一执行这些 SQL 语句。这样，从服务器上的数据就与主服务器保持同步了。

三、主从模式的架构形式

根据从库的数量和用途，主从模式可以演变成多种架构：

一主一从：最基本的模式，用于数据备份或读写分离。
一主多从：一个主库对应多个从库。适用于读请求远大于写请求的场景，通过多个从库分担读负载。
双主复制（主主复制）：两个服务器互为主从。任何一方的变更都会同步到另一方。这种架构更复杂，需要处理自增ID冲突等问题，通常用于需要高可用性的场景。
级联复制（Master - Slave - Slaves）：一个从库再作为其他从库的主库。这样可以减轻主库的压力，因为主库只需要给一个从库发送日志，但这个从库的延迟会影响它下面所有的从库。

读写分离：
- 写操作（增、删、改）全部交给主服务器处理。
- 读操作（查询）可以分散到一个或多个从服务器上。
- 这极大地提升了数据库的并发处理能力和整体性能。这是主从模式最常用的场景。
数据备份与灾难恢复：
- 从服务器相当于主服务器的一个“热备份”。当主服务器发生故障时，可以快速切换到从服务器继续提供服务，减少停机时间。
- 需要注意的是，从库的备份不是绝对安全的，逻辑错误（如误删表）也会被同步到从库。
数据分析与报表：
- 可以在从服务器上执行耗时的数据分析或报表生成任务，而不会影响主服务器的在线业务性能。
高可用性基石：
- 主从复制是构建更高级高可用架构（如 MHA、MGR、Orchestrator）的基础。

数据延迟：
- 由于复制是异步的（默认方式），从库的数据相对于主库会有一定的延迟。在高速写入的场景下，延迟可能非常明显。
- 对数据实时性要求极高的读操作（如查询刚下的订单）可能读到旧数据。
数据一致性问题：
- 如果网络中断或从库宕机，恢复后可能面临数据不一致的风险，需要人工干预来修复。
主库的单点故障风险：
- 主从模式本身没有解决主库的单点问题。如果主库宕机，需要手动或借助工具将从库提升为主库，并调整应用配置，这个过程存在服务中断时间。
写入瓶颈：
- 所有的写操作仍然集中在单个主库上，写入性能有上限。主从模式无法解决写入瓶颈问题。