日常办公中，我们主要运用的是 MySQL 数据库系统，业务量持续增长后，若仅依靠一台服务器运行，其承载压力会急剧上升，进而可能导致系统崩溃。
如果这样，我们存储在 MySQL 数据库里的信息就会不见，那么要怎么办呢？
实际上 MySQL 内置了主从复制机制，该机制能够协助达成负载均衡，并且实现读写分离的目的。
主服务器承担主要写入任务，从服务器负责主要读取工作，这种分工能够显著降低系统负担，进而提升整体运行效能。
接下来，跟着小羽一起来看看它都有哪些核心知识点呢：
简介
业务规模持续扩大，单台数据服务器承载压力加剧，已无法满足当前要求，必须进行优化调整，采用负载分散策略，通过读写分离来缓解压力，可以设置一个主服务器，搭配一个或多个从服务器运行。
主要服务器仅承担记录功能，次要服务器仅执行查询任务，以此方式优化了性能并降低了负担。
主从复制可以分为：
形式一主一从
一主一从
一主多从
一主多从
主从式和主多从式是目前最常见的两种主从结构，它们操作简便且效果显著，既能完成高可用部署，又可以执行读写分离，从而增强整个集群的并发处理性能。
多主一从
多主一从
将多个 MySQL 数据库进行备份，可以集中到性能较高的服务器中存储。
双主复制
双主复制
双重主备机制，允许彼此转换角色，每个主节点既是领导者，也是其他服务器的从属节点。任何一方执行的数据更新，都会经由同步机制传递至对方的存储系统中。
级联复制
级联复制
在级联复制机制中，有部分从站的数据同步并非直接与主站相连，而是与其它从站进行同步。
如果主节点连接的从节点数量过多，会造成性能损耗用于数据复制，因此可以设置 3 到 5 个从节点直接与主节点相连，其余从节点则通过二级或三级连接到这些从节点，这种方式既能减轻主节点的负担，也不会对数据统一性产生不良影响。
原理
MySQL 的主从同步机制依靠主端系统记录所有数据库变更的操作记录。要实现同步功能，需要在主端系统开启操作记录功能。
每台从服务器都从主服务器那里获取已经记录在日志里的数据。每当一台从服务器连接到主服务器，它就会告知主服务器，从服务器的日志中需要读取最后成功更新的位置。
接收来自服务器的后续所有变更，并在本机实施这些变更。接着，暂停等待主服务器发布的最新更新。
服务器进行数据备份时，主服务器不受影响，在备份操作期间，主服务器仍可正常处理数据更新。
过程工作过程
MySQL 的主从复制工作过程大致如下：
新建两个执行任务，其一负责数据交互，其二负责数据库指令处理；数据交互任务向主数据库索取二进制日志，并将获取内容记录在中继日志文档中；主数据库会设立一个日志传输任务，用于向从数据库的数据交互任务提供二进制日志；数据库指令处理任务会查阅中继日志文档里的记录，将其转化为具体指令，以此达成主从数据库的指令同步，并确保最终数据保持一致。
工作过程
请求流程
MySQL 建立请求的主从的详细流程如下：
在从服务器接入主服务器期间，主服务器会启动一个日志转储进程，负责传输二进制日志数据。该进程在读取主节点二进制日志时会实施锁定措施，待数据读取完毕并转发给从服务器后，会解除锁定状态。启动从节点上的特定指令后，该节点会设立一个专门线程，目的是与主节点建立连接，进而向主数据库索要二进制日志信息。该线程接收到主节点发送的二进制日志数据后，会将这些数据存储在转发日志中。该节点上的 SQL 线程承担着读取 reely-log 的任务，将其内容解析为具体操作来执行，目的是确保主从数据保持同步，属于异步复制类型。
一个主库，一个或多个从库，数据异步同步到从库。
异步复制
在这种情形下，主节点不会自行传送资料至从节点，主数据库在处理完用户端提交的指令后会立刻将信息反馈给用户端，并且对从数据库是否已经收到并执行毫不在意。
当主节点发生故障，已提交的事务数据未必能同步到从节点，倘若此刻将从节点强制切换为主节点，新主节点内的数据很可能存在缺失。
同步复制
在 MySQL cluster 中特有的复制方式。
主库完成一个事务操作之后，各个从库需要逐一复制并处理该事务，全部操作成功后才向客户端反馈确认信息。
由于必须等到所有从库都完成该事务操作，才能反馈成功信号，因此完全同步复制的方式会对执行效率造成很大阻碍。
半同步复制
通过异步复制机制，要保证每个主数据库中的操作，在最终确认前，都至少有一个从数据库接收到了该操作，并且已经将操作信息记录在日志里。
半同步复制
主库在处理客户端提交的事务时，不会马上回应请求，而是会稍作等待，确保至少有一个从库接收并记录了相关数据到中继日志里，才会向客户端反馈操作成功的信息，这仅能证明主库的二进制日志已经成功发送给一个从节点，如果这个过程中没有从库接收到数据，主库会继续等待，直到达到预设的等待时间，届时会转为异步模式再进行提交。
半同步复制比异步复制更安全，能够较大幅度确保数据传输到从库，但也会产生一定时间差，这个时间差小于全同步模式，最短也要经过一次 TCP/IP 交互。因此，半同步复制适合在延迟较小的网络环境下应用。
半同步模式并非 MySQL 的固有功能，自 5.5 版本起才得以整合，要启用此模式，主库与从库都必须安装相应的插件。
延迟复制
采用异步复制机制，特意规定主库向从库传输数据的滞后时长，确保数据差距不会少于这个数值。
方式
MySQL 的主从同步功能提供了两种不同的记录机制，这两种记录机制分别对应着各自的同步模式。除此之外，还存在一种将两者特点融合的复合同步方式。
语句复制
复制语句等同于逻辑复制，二进制日志会记录下执行的操作，借助这些操作可以在从属数据库上重播，以此达成复制效果。
这种办法比较简便，生成的二进制文件体积不大，对网络传输容量的消耗也不多。不过，信息的变更过程受制于某些条件，例如，在增加数据内容时会借助时间标记。
因此，在项目实施时，需要尽量把业务规则实现到程序代码里，不宜把其放在 MySQL 数据库中，那样扩展性较差。
特点：
行数据复制
按照记录的行进行拷贝，等同进行物理复制，即二进制日志里，实际变更的每一条数据记录。
这种办法造成复制负担很重，记录文件消耗存储容量多，信息流通渠道负载也高。不过，这种途径比起依据语句进行的复制，实现的效果更为准确。
特点：
混合类型的复制
通常情况下，系统会优先选用逐句复制的方式，如果这种复制方法效果不佳，则会切换到逐行复制模式。
配置
配置主要要点如下：
当双主复制构造里缺少身份标识设定时，便会产生数据交互混乱状况，进而引发信息来回传输故障
server_id=1
# 即日志中记录的是语句还是行更新或者是混合
binlog_format=mixed
当执行了若干笔事务操作后，MySQL会发起一次磁盘同步操作。具体来说，它会运用fsync指令，把缓冲区里的数据完整写入到存储介质上。
# 为0的话由Mysql自己控制频率。
sync_binlog=n
若该值为零，则记录缓冲区会每秒钟向日志文件中记录数据，并且将内容同步至磁盘。
mysqld进程崩溃会丢失一秒内的所有事务。
当设置为第一档时，每次事务日志缓冲区会记录日志内容并传送至磁盘文件，同时执行磁盘刷新操作，这种方式更加稳妥可靠。
# 在崩溃的时候,仅会丢失一个事务。
当涉及第二项内容时，每次事务日志缓冲区会记录日志到日志文件中，并且每秒钟进行一次数据刷新至磁盘
这个参数的值设为0，意味着事务日志的刷新操作不会每次都执行，而是会采用一种更高效的策略来处理日志的持久化。
禁止数据库瘫痪后系统自动开启镜像，需要预留修复潜在故障的时段
系统在出现故障后若尝试自动进行数据备份，可能会引发一系列新的故障，而且这种操作方式从本质上就存在缺陷。
skip_slave_start=1
# 是否将从库同步的事件也记录到从库自身的bin-log中
备库能够把重放的操作记录到自己的二进制日志文件里，同时也可以将备库当作其他主库的从库来使用
log_slave_update
# 日志过期删除时间，延迟严重的话会导致日志文件占用磁盘
expire_logs_days=7
问题延迟
主库的 TPS 并发量很大时，主库是多线程执行写入操作的，而副库的 SQL 线程却是单线程运行的，这会造成副库 SQL 无法跟上主库的处理节奏。
解决方法：
数据丢失
当主库宕机后，数据可能丢失。
解决方法：
使用半同步复制，可以解决数据丢失的问题。
注意事项
MySQL 需要注意以下事项：
作用
主从备份展现出诸多优势，若主服务器发生故障，能够转向备用服务器；能够实现数据库的读与写分离处理；能够借助从数据库执行常规备份工作。同时确保了
数据更加稳妥：实现了数据备份，不会因为单个服务器的故障而造成数据损失；运行效率显著增强：采用主从架构，各个用户从不同的数据库获取信息，效率得到提高；系统更容易扩展：当访问量增加时，能够便捷地扩充从服务器，且不会干扰系统的正常运作；实现了任务分配均衡：主从模式有助于分散主机的压力，起到了负载均衡的作用。适用范围
MySQL 的主从复制集群技术让数据库能够处理海量高并发的读写操作，此外还能在物理服务器出现故障时有效保障数据备份。
横向扩展
将工作负载分发到各 Slave 节点上，从而提高系统性能。
当前情况下，所有写入及修改任务都在主节点上实施；所有查询任务都在从节点上执行。通过增添更多从节点，可以有效加快系统的查询效率。
数据安全
信息从主节点传输到从节点上，在从节点处能够中断传输过程。可以在从节点处存储与主节点相匹配的信息，且不会干扰主节点的运作。
数据分析
即时信息能够在主节点上建立，而处理这些信息则可以在从节点上执行，并且不会干扰主节点的运作效率。
远距离数据分布
能够借助远程系统上的复制功能，生成本地信息的另一份复制件，这样就不必持续地与主节点建立连接关系。
拆分访问
可以将不同的从服务器，按照企业的工作内容划分开来。这种划分方式，有助于缓解主服务器的负担，同时也能让数据库在对外提供信息查询服务，对内支持业务运作，以及 DBA 人员执行数据备份等任务时，彼此之间不会相互干扰。
