一、导读
1.1、认识主从复制
数据库的主从复制（master-slave
replication）是一种数据复制技术，其中一台数据库服务器（主服务器）上的数据变更会复制到另一台或多台数据库服务器（从服务器）上。这种复制可以是同步的或异步的。
注：其中最重要的是：两个日志三个线程。
1.2、主从复制使用场景
（1） 快速构建测试环境：在开发和测试环境中快速创建与生产环境数据一致的数据库副本，以进行功能测试、性能测试等。
（2）灾难恢复：在数据库发生故障时，可以快速从备份或另一个健康实例克隆数据，以减少恢复时间和业务中断。
（3）数据库迁移：在升级硬件、切换服务器时，使用克隆插件可以快速迁移数据而无需长时间的停机。
（4）水平扩展：在数据库需要增加读取能力时，可以快速克隆数据库到新的服务器上，作为只读从库。
（5）数据库物理备份：克隆插件可以用于构建本地或远程的热备节点，以提高数据的可用性和容错能力。
1.3、主从复制流程
1.3.1、Master端的操作
记录变更到二进制日志（Binary Log）：
在每个事务更新数据完成之前，Master会在其二进制日志中记录这些改变。这些改变包括数据修改、结构变更等所有会影响数据库状态的操作。
写入二进制日志的操作完成后，Master会通知存储引擎提交事务。这一步确保了事务的完整性和数据的一致性。
1.3.2、Slave端的操作
（1）复制二进制日志到中继日志（Relay Log）：
Slave会启动一个I/O线程，该线程在Master上打开一个普通的连接，并启动Binlog dump process；
Binlog dump process负责从Master的二进制日志中读取事件。如果Slave已经跟上Master的进度，它会进入睡眠状态等待Master产生新的事件；
I/O线程将这些从Master读取到的事件写入到Slave的中继日志中。中继日志是Slave端用于暂存从Master接收到的变更事件的日志。
（2）应用变更到Slave数据库：
接下来，SQL从线程（SQL slave thread）会处理中继日志中的事件。它从中继日志中读取事件，并重新执行这些事件，以此来更新Slave数据库中的数据，使其与Master数据库中的数据保持一致；
只要SQL线程与I/O线程保持一致，中继日志通常会位于操作系统的缓存中，这大大减少了磁盘I/O的开销。
二、主从复制多维度对比分析
2.1、从库数据初始化方式
在搭建MySQL主从复制架构时，从库数据初始化的方式一般有使用Mysqldump进行逻辑导出、Xtrabackup物理备份及在线clone克隆等三种方式。
2.1.1、使用Mysqldump逻辑导出主库
Mysqldump 是 MySQL 自带的一个逻辑备份工具。它可以将数据库中的数据以SQL语句的形式导出，然后在从库上执行这些 SQL 语句进行数据恢复和初始化。
优点
简单易用：作为 MySQL 自带的工具，无需额外安装，使用方便。
灵活性高：可以通过各种参数来定制备份的内容，比如指定特定的数据库、表、数据范围等。
缺点
备份和恢复速度较慢：由于是逻辑备份，需要将数据转换为 SQL 语句，在恢复时又要执行这些 SQL 语句，对于大型数据库来说，这个过程可能非常耗时。
可能会导致主从同步延迟：在初始化从库时，如果主库上的数据量很大，使用Mysqldump进行备份和恢复可能需要很长时间，从而导致从库与主库之间的同步延迟较大。
适用场景
小型数据库：对于数据量较小的数据库，Mysqldump是一个简单有效的备份和初始化从库的方式。
特定数据的备份和恢复：如果只需要备份和恢复特定的数据库、表或数据范围，Mysqldump的灵活性可以很好地满足需求。
2.1.2、使用xtrabackup物理备份主库
Percona XtraBackup是一个开源的物理备份工具，它可以在不影响数据库正常运行的情况下进行备份。它通过复制数据库文件的方式进行备份，然后在从库上进行恢复。
优点
备份和恢复速度快：由于是物理备份，直接复制数据库文件，所以备份和恢复速度比Mysqldump 快很多。
支持在线备份：可以在数据库运行的情况下进行备份，不会影响数据库的正常使用。
缺点
相对复杂：需要额外安装和配置，对于不熟悉的用户来说，可能有一定的学习成本。
占用磁盘空间较大：物理备份会复制整个数据库文件，所以占用的磁盘空间可能比逻辑备份大。
注：可以使用不落盘直接边备份、边压缩以流的方式直接传输到从库，而无需消耗主库空间。
适用场景
大型数据库：对于数据量较大的数据库，Xtrabackup可以快速地进行备份和恢复，减少主从同步的延迟。
对备份时间有要求的场景：如果需要在较短的时间内完成备份和恢复，Xtrabackup是一个更好的选择。
2.1.3、使用clone在线克隆主库
MySQL 从 8.0.17 版本开始支持克隆插件，可以通过克隆插件将主库的数据直接克隆到从库。
优点
极快的初始化速度：可以快速地将主库的数据复制到从库，大大减少了从库的初始化时间。
简单方便：无需复杂的备份和恢复过程，只需要在从库上执行克隆操作即可。
缺点
对版本有要求：只适用于 MySQL 8.0.17 及以上版本。
网络要求高：克隆过程需要通过网络传输数据，如果网络条件不好，可能会影响克隆的速度和稳定性。
适用场景
MySQL 8.0 及以上版本的环境：只有在支持克隆插件的 MySQL 版本中才能使用。
对从库初始化速度要求极高的场景：如果需要快速地搭建主从复制环境，clone 是一个非常好的选择。
2.2、binlog日志格式
在 MySQL 主从复制架构下，二进制日志（binlog）有三种格式：STATEMENT、ROW、MIXED。
2.2.1、STATEMENT格式
这种格式下，binlog 中记录的是执行的 SQL 语句。例如，执行一条UPDATE table SET column
= value WHERE id = 1;语句，binlog 中就会记录这条 SQL 语句。
优点
日志文件相对较小：节省磁盘空间和网络传输带宽。因为只记录了 SQL 语句，而不是每一行数据的具体变化。
具有较高的可读性：对于熟悉 SQL 语言的人来说，很容易理解和分析日志内容。
缺点
存在不确定性：某些 SQL 语句在不同的环境下执行结果可能不一致，比如使用NOW()函数获取当前时间，或者依赖于特定的系统变量、自增主键等情况。这可能导致主从数据库的数据不一致。
不适合存储过程、触发器等复杂语句的复制：因为这些复杂语句的执行效果可能难以准确复制。
适用场景
对日志大小有限制且对数据一致性要求不是特别严格的场景。
简单的 SQL 操作且主从数据库环境较为一致的情况。
2.2.2、ROW格式
在这种格式下，binlog 记录的是每一行数据的变化。例如，当更新一行数据时，binlog 中会记录这行数据的变化前后的值以及相关的信息。
优点
数据准确性高：无论 SQL 语句多么复杂，都能确保主从数据库的数据一致性，因为它是精确地记录了每一行数据的变化。
适用于各种复杂的 SQL 操作：包括存储过程、触发器等。对于包含这些复杂逻辑的操作，也能准确地复制数据变化。
缺点
日志文件较大：由于记录了每一行数据的变化，所以生成的日志文件通常比 STATEMENT 格式的大很多，占用更多的磁盘空间和网络传输带宽。
可读性较差：记录的是二进制数据，对于不熟悉二进制格式的人来说，很难理解和分析日志内容。
适用场景
对数据一致性要求非常高的场景，如金融、电商等关键业务系统。
数据库中包含大量存储过程、触发器等复杂逻辑的情况。
2.2.3、MIXED格式
这是一种混合模式，MySQL 会根据具体的 SQL 语句自动选择使用 STATEMENT 格式还是 ROW 格式。例如，对于简单的 SQL 语句，可能会使用 STATEMENT 格式；对于可能导致主从不一致的复杂语句，则使用 ROW 格式。
优点
兼具 STATEMENT 和 ROW 格式的一些优点，在一定程度上平衡了日志大小和数据一致性。既可以在大多数情况下保持较小的日志文件，又能在必要时确保数据的准确性。
缺点
复杂性增加。由于系统自动选择日志格式，可能会导致主从复制的行为不太容易预测，增加了排查问题的难度。
可能会带来一定的性能开销，因为需要判断每个 SQL 语句使用哪种格式。
适用场景
希望在日志大小和数据一致性之间取得平衡的场景。
不确定数据库中 SQL 语句的复杂性，又不想完全依赖一种格式的情况。
2.3、主从复制方法
MySQL的主从复制支持两种复制方法，一种是使用二进制日志文件名称和事件的位置，另一种是使用GTID。
2.3.1、基于binlog和position
使用二进制日志文件名称和事件的位置来执行事件或应用更改，并同步主服务器和从服务器之间的数据。
优点
灵活性高：对于一些特定的复杂数据库架构调整或故障恢复场景，可以更精细地控制复制的起始点和进度。比如，当需要从特定的时间点或特定的事务位置进行恢复时，可以准确地指定日志文件和位置，实现精准的复制控制。
兼容性较好：对于旧版本的 MySQL 系统或者一些特殊的第三方工具，可能更容易兼容基于日志文件和位置的复制方式。在一些遗留系统的升级和维护过程中，这种兼容性可以减少升级的难度和风险。
缺点
管理复杂：需要手动记录和管理主库的日志文件和位置信息。如果主库的日志文件发生滚动或者主从库之间的连接出现问题，重新配置复制时需要准确地找到上次复制的位置，这增加了管理的复杂性和出错的可能性。
故障切换困难：在主从切换场景下，确定新主库的正确日志位置比较困难，可能需要进行一系列复杂的操作和验证，以确保从库能够正确地从新主库继续复制。这使得故障切换的过程变得复杂和耗时，容易影响系统的可用性。
扩展性受限：当数据库集群规模较大或者需要频繁添加或删除从库时，基于日志文件和位置的复制方式管理起来会变得更加困难。每个从库都需要独立配置和管理日志位置信息，增加了管理的工作量和出错的风险。
适用场景
旧系统升级和维护：对于一些使用旧版本 MySQL 且无法轻易升级到支持 GTID 的系统，可以继续使用基于日志文件和位置的复制方式进行数据同步和维护。
特定时间点恢复：当需要从特定的时间点恢复数据时，基于日志文件和位置的复制可以更精确地实现这一需求。
2.3.2、基于GTID
使用GTID（全局事务标识符）的方法具有事务性，不需要处理日志文件或这些文件中的位置，该特性大大简化了许多常见的复制任务。使用GTID进行复制可以保证主服务器和从服务器之间的一致性。
优点
自动识别和管理事务：GTID 可以唯一标识一个事务在整个复制拓扑中的位置，使得主从库之间的复制更加自动化和可靠。无需手动记录日志文件和位置信息，大大简化了复制的管理和故障恢复过程。
易于故障切换：在主从切换时，新主库可以通过 GTID 快速确定哪些事务已经被执行，哪些事务需要被同步到从库。这使得故障切换更加迅速和可靠，减少了系统的停机时间。
更好的扩展性：当添加新的从库时，从库可以自动从主库获取 GTID 信息，并确定需要同步的事务范围。无需进行复杂的日志文件和位置配置，使得数据库集群的扩展更加容易。
缺点
对 MySQL 版本有要求：基于 GTID 的复制需要特定版本（5.6）的 MySQL 支持，旧版本的 MySQL 可能无法使用这种复制方式。在升级数据库版本时，需要考虑到兼容性和可能出现的问题。
可能存在性能开销：在某些情况下，GTID 的管理和同步可能会带来一定的性能开销。特别是在高并发的环境下，需要对 GTID 的性能进行仔细的评估和优化。
复杂性增加：对于一些不熟悉 GTID 复制的管理员来说，理解和管理基于 GTID 的复制可能会有一定的学习曲线。需要深入了解 GTID 的工作原理和配置方法，以确保复制的正确运行。
适用场景
新系统部署和高可用架构：在新的数据库系统部署中，尤其是对高可用性有较高要求的场景，基于 GTID 的复制可以提供更简单、可靠的主从复制解决方案。
大规模数据库集群：对于大规模的数据库集群，基于 GTID 的复制可以更方便地管理和扩展，减少管理的复杂性和工作量。
2.4、主从复制类型
在 MySQL 主从复制架构中，主要有异步复制、半同步复制和完全同步复制、延迟复制等类型。
2.4.1、异步复制
主库在执行完事务后，立即将结果返回给客户端，而不必等待从库接收并应用事务日志。从库会在后台异步地从主库拉取事务日志并进行应用。
优点
性能高：主库不需要等待从库的响应，因此可以快速地处理事务并响应客户端请求，从而提供较高的性能。
简单易实现：实现相对简单，不需要复杂的配置和协调机制。
缺点
数据一致性较弱：在主库发生故障时，可能存在从库还未接收到某些事务日志的情况，导致主从数据不一致。
可能出现数据丢失：如果主库在事务提交后但从库还未复制该事务时发生故障，那么该事务可能会丢失。
适用场景
对性能要求较高，且对数据一致性要求相对较低的场景。
可以容忍一定程度的数据丢失的应用：例如一些非关键业务系统或者对数据实时性要求不高的分析型系统。
2.4.2、半同步复制
主库在执行完事务后，必须等待至少一个从库接收到事务日志并返回确认信息后，才将结果返回给客户端。如果在一定时间内没有从库确认，主库会切换回异步复制模式。
优点
提高数据一致性：相比异步复制，半同步复制在一定程度上保证了主库提交的事务至少已经被一个从库接收，降低了数据丢失的风险。
性能和一致性的平衡：在保证一定数据一致性的前提下，性能损失相对较小。
缺点
性能开销：由于需要等待从库的确认，主库的响应时间会增加，从而导致性能下降。
复杂性增加：需要额外的配置和监控来确保半同步复制的正常运行。
适用场景
对数据一致性有一定要求，但又不能接受完全同步复制带来的性能损失的场景。
关键业务系统，希望在保证数据可靠性的同时，尽量减少性能影响。2.4.3、完全同步复制
主库在执行完事务后，必须等待所有从库都接收到事务日志并应用成功后，才将结果返回给客户端。
优点
数据一致性最强：确保了主从数据库在任何时刻都保持完全一致。
数据安全性高：几乎不会出现数据丢失的情况。
缺点
性能极差：主库的响应时间取决于最慢的从库，当从库数量较多或者网络延迟较大时，性能会严重下降。
系统复杂性高：实现和管理非常复杂，需要处理各种可能的故障情况。
适用场景
对数据一致性要求极高，且可以接受极低性能的场景，例如一些金融交易系统中的关键数据存储。
在特殊的高可靠性要求环境下，且系统规模较小、性能要求不高的情况。2.4.4、延迟复制
在 MySQL 主从复制中，延迟复制是一种特殊的复制方式，从库在复制主库的二进制日志时，不是立即应用，而是人为地设置一定的时间延迟后再进行应用。延迟复制可以通过在从库的配置文件中设置CHANGE MASTER TO MASTER_DELAY = N（其中 N 为延迟的秒数）来实现。例如，设置 MASTER_DELAY = 3600，则从库会延迟一小时应用主库的二进制日志。
优点
数据恢复：在某些误操作或数据损坏的情况下，可以利用延迟复制的从库来恢复数据。例如，如果主库上不小心执行了错误的删除或更新操作，在发现问题后，可以停止从库的复制进程，并将从库的数据恢复到错误操作之前的状态，从而减少数据损失。
避免错误传播：当主库上出现一些不可预见的问题，如软件漏洞导致的数据错误写入，延迟复制的从库可以避免立即应用这些错误操作，为管理员提供一定的时间窗口来发现和解决问题，防止错误快速传播到整个数据库系统。
测试和验证：对于一些新的数据库变更或应用程序升级，可以先在主库上进行操作，然后观察延迟复制的从库一段时间，以验证这些变更是否会对系统产生不良影响。如果发现问题，可以在从库上进行调试和修复，而不会影响生产环境的主库。
缺点
增加复杂性：引入延迟复制会增加数据库系统的复杂性。管理员需要额外管理和监控从库的延迟状态，确保延迟设置正确，并且在需要时能够及时调整延迟时间。这增加了管理的工作量和难度。
占用更多资源：由于从库需要存储一段时间内未应用的二进制日志，可能会占用更多的磁盘空间。此外，在应用延迟的日志时，可能会对系统资源（如 CPU、内存和磁盘 I/O）产生一定的压力，尤其是在延迟时间较长、日志积累较多的情况下。
可能影响业务连续性：在某些情况下，延迟复制可能会影响业务的连续性。例如，如果主库发生故障，需要切换到从库时，延迟复制的从库可能无法立即提供与主库完全同步的数据，从而导致业务中断时间延长。
适用场景
高风险操作环境：在一些对数据准确性要求极高，且可能存在高风险操作的环境中，如金融交易系统或重要的企业级数据库，延迟复制可以作为一种额外的安全保障措施。当出现错误操作时，能够有时间进行数据恢复，降低损失。
数据库变更管理：对于频繁进行数据库结构变更或数据更新的系统，延迟复制可以用于在变更实施后进行验证。通过观察延迟复制的从库，可以及时发现变更带来的问题，并在问题影响到生产环境之前进行修复。
数据备份和恢复策略：作为数据备份和恢复策略的一部分，延迟复制的从库可以提供一个在特定时间点之前的数据副本，用于灾难恢复或数据回滚。在发生数据丢失或损坏的情况下，可以选择使用延迟复制的从库进行恢复，而不是依赖传统的备份文件。
