📑 主从复制
主从复制指主服务器（master server）上，任何修改和数据结构变更的事件，都会被写入到日志文件 bin log 中，从服务器（slave server）读取主服务器上的日志文件中的事件变更，并在本地重放执行。
通过主从复制，能够提高数据库的读性能。主库复制写，从库复制读。
并不适合来扩展写操作。例如在一主多从的架构中，写操作要被执行多次，整个系统的性能会取决于写入最慢的那个。
💡 常见用途：
- 数据备份
- 数据分发
- 提高读性能
- 高可用和故障切换
📖 复制原理
👣 主库中的数据变更会记录到 binlog 中，主库会创建一个 binlog dump thread，将 binlog 传输到从库
👣 从库创建 IO 线程，将主库传来的 binlog 写入到自己的 relay log 中继日志
👣 从库创建 SQL 线程，从 relay log 中读取数据，重放到数据库中
这里的 IO 线程 和 SQL 线程的工作是解耦的，可以独立运行。
🎫 复制格式
MySQL 有三种方式记录 binlog，同样在复制时，也对应有三种复制格式。
💡 如果需要安全的数据复制方法，推荐使用基于行的格式复制，除非某些场景下明确需要临时使用基于语句的格式。
📃 基于语句 statement
通过重新执行主服务器中执行过的 SQL 语句来完成复制的。
优点🙋 是简单紧凑，例如批量更新了 1000 条数据，也只需要一条语句，节约 IO。
缺点🙅♂️ 是在一些情况下，可能导致主从数据不一致（例如使用了 now() 这样的函数）。
📓 基于行 row
基于行的日志中，记录了该行数据发生了什么变化，包含该行修改前和修改后的情况。在执行时，进行解析，找到需要变更的记录进行操作。
优点🙋 是数据具有强确定性。
缺点🙅♂️ 是可能会导致日志中记录大量数据。比如在批量更新时，出现大量的行的修改，但是语句可能只有一条。
🖇️ 混合模式 mix
“试图” 混合模式结合以上两种格式的优点。（可能会有😵不稳定的情况）
默认情况下使用基于语句的格式，在有需要时切换到基于行的格式。在写入事件时，会有很多的判断条件。
🎚️ 复制模式
🌑 异步模式（默认）
主库不会主动推送 binlog 给从库，事务执行完直接返回，不关心从库是否接收到数据，从库通过异步的方式进行主从复制。
🌓 半同步模式
主库执行的事务，等到至少一个从库将日志记录到了 relay log 中之后，再提交（不能保证从库执行完成，只能保证一个从库收到了日志）。
注意：如果从库在超时时间之内没有返回，会退化成异步模式。
🌕 全同步模式
主库执行的事务，等到所有的从库都执行完成之后，主库才会提交，返回成功信息给客户端。
在实际项目中，基本不会使用。会严重影响性能，只要有一个从库发生故障，就会影响业务正常进行。