15 主从复制的作用及重要性

## 一、MySQL复制是什么？（WHAT？）

MySQL Replication 是MySQL一个非常重要的功能，主要用于主服务器和从服务器之间的数据复制操作。

复制（replication）功能可以将一个MySQL数据库服务器（主库）中的数据复制到一个或多个MySQL数据库服务器（从库）。默认情况下，复制是异步的，从库不需要永久连接以接收来自主库的更新。我们可以将其配置为复制所有数据库、复制特定的数据库，甚至还可以配置为复制数据库中指定的表。

**1.1 复制的策略**

MySQL复制⽀持多种不同的复制策略，包括同步、半同步、异步和延迟策略等。

同步策略 ：Master要等待所有Slave应答之后才会提交（MySql对DB操作的提交 通常是先对操
作事件进⾏⼆进制⽇志⽂件写⼊然后再进⾏提交）。
半同步策略 ：Master等待⾄少⼀个Slave应答就可以提交。
异步策略 ：Master不需要等待Slave应答就可以提交。
延迟策略 ：Slave要⾄少落后Master指定的时间。

**1.2 复制模式**

根据binlog⽇志格式的不同，MySQL复制同时⽀持多种不同的复制模式：
1、Statement Based Replication（SBR）（基于语句的复制）

```sql
记录每⼀条更改数据的sql。

优点：binlog⽂件较小，节约I/O，性能较⾼。（自从3.23版本就存在，经过长期验证的成熟技术，写入日志文件的数据更少，这意味着更少的文件写入和网络传输消耗，从而整体上可以更快的完成主从复制，提升性能表现。）

缺点：不是所有的数据更改都会写⼊binlog⽂件中，尤其是使⽤MySQL中的⼀些特殊函数（如LOAD_FILE()、UUID()等）和⼀些不确定的语句操作，从⽽导致主从数据⽆法复制的问题。进行数据更新时，需要比基于行的复制更多的行锁，对于先插入后更新式的复杂语句，从节点需要进行整个执行过程的完全重放，中间状态最终会被覆盖，而基于行格式的复制只需要执行终结果即可
```

2、Row Based Replication（RBR）（基于行的复制）

```sql
不记录sql，只记录每⾏数 据的更改细节。

优点：详细的记录了每⼀⾏数据的更改细节，这也意味着不会由于使⽤⼀些特殊函数或其他情况导致不能复制的问题。进行数据更新时，所需要的行锁更少，从而可以获取更高的性能表现。

缺点：由于row格式记录了每⼀行数据的更改细节，会产⽣⼤量的binlog⽇志内 容，性能不佳，并且会增⼤主从同步延迟出现的⼏率。
```

3、混合复制（Mixed）

```sql
⼀般的语句修改使⽤statment格式保存binlog，如⼀些函数，statement⽆法完成主从复制的操作，则采⽤row格式保存binlog，MySQL会根据执⾏的每⼀条具体的sql语句来区分对待记录的⽇志形式，也就是在Statement和Row之间选择⼀种。
```

## 二、MySQL的复制有什么好处？（WHY）

那么，主从复制有什么作用呢？

1. 数据安全性
   做数据的热备，作为后备数据库，主库数据库宕机故障，可以切换到从数据库继续工作，避免数据丢失。

2. 实施读写分离
   读写分离能使得数据库支持更大的并发。一般根据业务量设计，通常是把主库设置写入，从库设置读取，当用户写入数据，读写分离实施之后，只会写入给主库，不会写入给从库，并且把主库写入的数据同步给从库，而主库不负责用户读取数据的操作。而从库通过异步同步，不负责写入数据，只负责用户读取。分工明确，可以极大的降低主库的压力，不会导致数据库宕机。

3.数据库的拆分
前期业务数据量很小，我们经常会把多个数据量很小的库放在一个实例中，后续随着业务量的增长，其中一个库需要做拆分，这时候就可以使用复制功能，将所需拆分的库复制到目标服务器，让业务进行流量切换。

4. 数据库版本升级
   遇到数据库bug时，我们就要考虑进行数据库版本的升级了，那么如何平滑的升级又不影响业务呢？这时也可以利用复制的功能，完成无感的升级。

5. 分析
   在主节点上可以实时创建数据，而对信息的分析可以在从库上进行，不会影响主库的性能。

6.远程数据分发
可以使用复制为远程服务器站点创建本地数据的副本，无需永久访问主库。

## 三、MySQL如何实现主从复制？（HOW）

在进行学习如何实现主从复制之前，我们先来回顾下上节学习到mysql日志——binlog和relay log。

| 日志名称          | 主要作用                  |
| ----------------- | ------------------------- |
| binlog 二进行日志 | 记录DML/DDL语句及数据变化 |
| relay log中继日志 | 主从复制日志              |

**binlog日志**

```sql
1.介绍:
- 最重要Mysql日志.
- 记录了所有的DDL和DML语句(对数据库的改动)
- 数据库的查询select或show等不会被binlog日志记录
- 以事件形式记录(包含语句所执行的消耗的时间，事务安全型的)
- 性能损耗:1%的性能损耗。
- 数据库重启，flushlogs，达到指定大小.

2.作用
- 主从复制:Master端开启binlog==>slaves来达到master-slave数据一致的目的。
- 数据恢复:mysqlbinlog,binlog2sql达到备份+binlog完成任一事务之前的数据恢复
- 数据管道:canle，tapdata
主要作用： 复制和备份

3.binlog格式（5.7.7之前默认STATEMENT,之后默认ROW),
(1)STATEMENT:基于SQL语句复制(statement-based replication, SBR),每条修改数据SQL会
- 优点:不需要记录每一行的变化，减少了binlog日志量，节约了IO, 从而提高了性能；
- 缺点:在某些情况下会导致主从数据不一致，比如执行sysdate()、sleep()等。

(2) ROW:基于行的复制(row-based replication, RBR),仅记录哪条数据被修改了。
- 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正
- 产生大量的日志，尤其是alter table的时候会让日志暴涨

(3) MIXED:基于STATMENT和ROW两种模式的混合复制(mixed-based replication, MBR)，一
- 生产环境中使用ROW,因为一般我们需要binlog来做更多的操作(数据同步,日志解析),Mixed

4. binlog记录内容
# at 235
#211030 22:19:04 server id 1 end_log_pos 318 CRC32 0x149ef4ad Query thre
SET TIMESTAMP=1635603544/*!*/;
#上述内容得知
- position: 位于文件中的位置，即第一行的（# at 211030）,说明该事件记录从文件第21103
timestamp: 事件发生的时间戳，即第二行的（211030 22:19:04）
server id: 服务器标识（1）
end_log_pos 表示下一个事件开始的位置（即当前事件的结束位置+1）
thread_id: 执行该事件的线程id （thread_id=1213168）
exec_time: 事件执行的花费时间
error_code: 错误码，0意味着没有发生错误
type:事件类型Query
```

**relay log**

Relay log，一般叫做中继日志，一般情况下它在MySQL主从同步读写分离集群的从节点才开启。主节点一般不需要这个日志。
从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后SQL线程会读取relay-log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。
接下来我们开始正式进入本节课程的学习了，在本节中，我们将学习GTID、Binlog Event、主
从复制的原理、如何设置传统复制、复制指定的数据和表、设置多源复制、设置链式复制、延迟复制和半同步复制等。
首先，我们先来了解下GTID和Binlog Event，对gtid和binlog event有了深入的了解后，我们再来实现主从复制，这时候肯定会有事半功倍的效果。