mysql
This commit is contained in:
luoxiang
@ -1,6 +1,54 @@
|
||||
## 一、基于二进制日志的复制
|
||||
# MySQL 复制
|
||||
|
||||
主节点配置：
|
||||
## 一、日志格式
|
||||
|
||||
### 1.1 二进制日志格式
|
||||
|
||||
MySQL 二进制日志是进行主从复制的基础，它记录了所有对 MySQL 数据库的修改事件，包括增删改查和表结构修改。当前 MySQL 一共支持三种二进制日志格式，可以通过 binlog-format 参数来进行控制，其可选值如下：
|
||||
|
||||
+ **STATEMENT**：段格式。是 MySQL 最早支持的二进制日志格式。其记录的是实际执行修改的 SQL 语句，因此在进行批量修改时其所需要记录的数据量比较小，但对于 UUID() 或者其他依赖上下文的执行语句，可能会在主备上产生不一样的结果。
|
||||
+ **ROW**：行格式，是 MySQL 5.7 版本之后默认的二进制日志格式。其记录的是修改前后的数据。因此在批量修改时其需要记录的数据量比较大，因为需要记录每一行语句修改后的结果。但其安全性比较高，不会导致主备出现不一致的情况。同时因为 ROW 格式是在从库上直接应用更改后的数据，其还能减少锁的使用。
|
||||
+ **MIXED**：是以上两种日志的混合方式，默认采用段格式进行记录，当段格式不适用时 (如 UUID() )，则默认采用 ROW 格式。
|
||||
|
||||
通常在主备之间网络情况良好的时，可以优先考虑使用 ROW 格式，此时数据一致性最高，其次是 MIXED 格式。在设置 ROW 格式时，还有一个非常重要的参数 binlog_row_image 。
|
||||
|
||||
### 1.2 binlog_row_image
|
||||
|
||||
binlog_row_image 有以下三个可选值：
|
||||
|
||||
+ **full**：默认值，记录行在修改前后所有列的值。
|
||||
|
||||
+ **minimal**：只记录修改涉及列的值。
|
||||
|
||||
+ **noblob**：与 full 类似，但如果 BLOB 或 TEXT 列没有修改，则不对其进行记录。
|
||||
|
||||
binlog-format 和 binlog_row_image 的默认值可能在不同版本存在差异，可以使用以下命令进行查看。通常情况下，为了减少在主备复制中需要传输的数据量，可以将 binlog_row_image 的值设置为 minimal 或 noblob。
|
||||
|
||||
```sql
|
||||
show variables like 'binlog_format';
|
||||
show variables like 'binlog_row_image';
|
||||
```
|
||||
|
||||
## 二、基于二进制日志的复制
|
||||
|
||||
### 2.1 复制原理
|
||||
|
||||
MySQL 的复制原理如下图所示：
|
||||
|
||||
+ 主库首先将变更写入到自己的二进制日志中；
|
||||
+ 备库会启动一个 IO 线程，然后主动去主库节点上获取变更日志，并写入到自己的中继日志中。
|
||||
+ 之后从中继日志中读取变更事件，在从库上执行变更。
|
||||
+ 当备库与主库数据状态一致，备库的 IO 线程就会进入睡眠。当主库再次发生变更时，其会向备库发出信号，唤醒 IO 线程并再次进行工作。
|
||||
|
||||
如果没有进行任何配置，主库在将变更写入到二进制日志后，就会返回对客户端的响应，因此默认情况下的复制是完全异步进行的，主备之间可能会短暂存在数据不一致的情况。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 2.2 配置步骤
|
||||
|
||||
首先主节点需要开启二进制日志，并且在同一个复制环境下，主备节点的 server-id 需要不一样：
|
||||
|
||||
```properties
|
||||
[mysqld]
|
||||
@ -9,7 +57,7 @@ server-id = 226
|
||||
log-bin=mysql-bin
|
||||
```
|
||||
|
||||
从节点配置：
|
||||
在备份节点配置中继日志：
|
||||
|
||||
```properties
|
||||
[mysqld]
|
||||
@ -18,20 +66,20 @@ server-id = 227
|
||||
relay_log = mysql-relay-bin
|
||||
# 为了保证数据的一致性，从节点应该设置为只读
|
||||
read_only = 1
|
||||
# 以下两个配置代表是否开启二进制日志，如果存在其他节点需要从该从节点上复制数据，则开启，否则不用配置
|
||||
# 以下两个配置代表是否开启二进制日志，如果该从节点还作为其他备库的主节点，则开启，否则不用配置
|
||||
log-bin = mysql-bin
|
||||
# 是否将中继节点收到的复制事件写到自己的二进制日志中
|
||||
log_slave_updates = 1
|
||||
```
|
||||
|
||||
创建复制账号：
|
||||
创建用于进行复制账号，并为其授予权限：
|
||||
|
||||
```shell
|
||||
CREATE USER 'repl'@'192.168.0.%' IDENTIFIED WITH mysql_native_password BY '123456';
|
||||
GRANT REPLICATION SLAVE on *.* TO 'repl'@'192.168.0.%' ;
|
||||
```
|
||||
|
||||
查看主节点日志状态：
|
||||
查看主节点二进制日志的状态：
|
||||
|
||||
```shell
|
||||
mysql> SHOW MASTER STATUS;
|
||||
@ -42,7 +90,7 @@ mysql> SHOW MASTER STATUS;
|
||||
+------------------+----------+--------------+------------------+-------------------+
|
||||
```
|
||||
|
||||
建立复制链路：
|
||||
基于日志和偏移量，建立复制链路：
|
||||
|
||||
```shell
|
||||
CHANGE MASTER TO MASTER_HOST='192.168.0.226',\
|
||||
@ -58,7 +106,7 @@ CHANGE MASTER TO MASTER_HOST='192.168.0.226',\
|
||||
START SLAVE;
|
||||
```
|
||||
|
||||
查看从节点复制状态：
|
||||
查看从节点复制状态，主要参数有 Slave_IO_Running 和 Slave_SQL_Running，其状态都为 Yes 表示用于进行复制的 IO 进程已经开启。Seconds_Behind_Master 参数表示从节点复制的延迟量。此时可以在主库上进行任意更改，并在备库上查看情况。
|
||||
|
||||
```shell
|
||||
mysql> SHOW SLAVE STATUS\G
|
||||
@ -103,7 +151,7 @@ Master_SSL_Verify_Server_Cert: No
|
||||
Last_SQL_Error:
|
||||
Replicate_Ignore_Server_Ids:
|
||||
Master_Server_Id: 226
|
||||
Master_UUID: e1148574-bdd0-11e9-8873-0800273acbfd
|
||||
# Master_UUID: e1148574-bdd0-11e9-8873-0800273acbfd
|
||||
Master_Info_File: mysql.slave_master_info
|
||||
SQL_Delay: 0
|
||||
SQL_Remaining_Delay: NULL
|
||||
@ -126,22 +174,33 @@ Master_SSL_Verify_Server_Cert: No
|
||||
1 row in set (0.00 sec)
|
||||
```
|
||||
|
||||
## 二、基于 GTID 的复制
|
||||
### 2.3 优缺点
|
||||
|
||||
主从服务器均增加以下配置：
|
||||
基于二进制日志的复制是 MySQL 最早使用的复制技术，因此 MySQL 对其的支持比较完善，对执行修改的 SQL 语句几乎没有任何限制。其主要的缺点是在一主多从的高可用复制架构中，如果主库发生宕机，此时想要自动通过从库的日志和偏移量来确定新的主库比较困难。
|
||||
|
||||
## 三、基于 GTID 的复制
|
||||
|
||||
### 2.1 GTID
|
||||
|
||||
MySQL 5.6 版本之后提供了一个新的复制模式：基于 GTID 的复制。GTID 全称为 Global Transaction ID，即全局事务 ID。它由每个服务节点的唯一标识和其上的事务 ID 共同组成，格式为： *server_uuid : transaction_id* 。通过 GTID ，可以保证在主库上的每一个事务都能在备库上得到执行，不会存在任何疏漏。
|
||||
|
||||
### 2.2 配置步骤
|
||||
|
||||
主从服务器均增加以下 GTID 的配置：
|
||||
|
||||
```properties
|
||||
gtid-mode = ON
|
||||
# 防止执行不受支持的语句，下文会有说明
|
||||
enforce-gtid-consistency = ON
|
||||
```
|
||||
|
||||
在从服务器上执行以下命令，关闭原有复制链路：
|
||||
如果配置过上面的基于二进制日志的复制，还需要在从服务器上执行以下命令，关闭原有复制链路：
|
||||
|
||||
```shell
|
||||
STOP SLAVE IO_THREAD FOR CHANNEL '';
|
||||
```
|
||||
|
||||
建立新的 GTID 复制链路：
|
||||
建立新的基于 GTID 复制链路，指定 MASTER_AUTO_POSITION = 1 表示由程序来自动确认开始同步的 GTID 的位置：
|
||||
|
||||
```shell
|
||||
CHANGE MASTER TO MASTER_HOST='192.168.0.226',\
|
||||
@ -156,12 +215,82 @@ CHANGE MASTER TO MASTER_HOST='192.168.0.226',\
|
||||
START SLAVE;
|
||||
```
|
||||
|
||||
查看从节点复制状态：
|
||||
在主节点上执行任意修改操作，并查看从节点状态，关键的输出如下：Retrieved_Gtid_Set 代表从主节点上接收到的两个事务，Executed_Gtid_Set 表示这两个事务已经在从库上得到执行。
|
||||
|
||||
在主节点上执行任意修改操作，查看复制情况：
|
||||
|
||||
```
|
||||
Retrieved_Gtid_Set: e1148574-bdd0-11e9-8873-0800273acbfd:1-2
|
||||
Executed_Gtid_Set: e1148574-bdd0-11e9-8873-0800273acbfd:1-2
|
||||
```sql
|
||||
mysql> SHOW SLAVE STATUS\G
|
||||
....
|
||||
Master_UUID : e1148574-bdd0-11e9-8873-0800273acbfd
|
||||
Retrieved_Gtid_Set : e1148574-bdd0-11e9-8873-0800273acbfd:1-2
|
||||
Executed_Gtid_Set : e1148574-bdd0-11e9-8873-0800273acbfd:1-2
|
||||
.....
|
||||
```
|
||||
|
||||
### 2.3 优缺点
|
||||
|
||||
GTID 复制的优点在于程序可以自动确认开始复制的 GTID 点。但其仍然存在以下限制：
|
||||
|
||||
+ 不支持 CREATE TABLE ... SELECT 语句。 因为在 ROW 格式下，该语句将会被记录为具有不同 GTID 的两个事务，此时从服务器将无法正确处理。
|
||||
|
||||
+ 事务，过程，函数和触发器内部的 CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 语句均不受支持。
|
||||
|
||||
为防止执行不受支持的语句，建议配置和上文配置一样，开启 enforce-gtid-consistency 属性， 开启后在主库上执行以上不受支持的语句都将抛出异常并提示。
|
||||
|
||||
## 四、半同步复制
|
||||
|
||||
|
||||
|
||||
## 五、高可用架构
|
||||
|
||||
不论是主主复制结构，还是一主多从复制结构，单存依靠复制只能解决数据可靠性的问题，并不能解决系统高可用的问题，想要保证高可用，系统必须能够自动进行故障转移，即在主库宕机时，主动将其它备库升级为主库。常用的有以下两种解决方案：
|
||||
|
||||
### 4.1 MMM
|
||||
|
||||
1. Monitor 检测到 Master1 连接失败；
|
||||
2. Monitor 发送 set_offline 指令到 Master1 的 Agent；
|
||||
3. Master1 Agent 如果存活，下线写 VIP，尝试把 Master1 设置为 read_only=1；
|
||||
4. Moniotr 发送 set_online 指令到 Master2；
|
||||
5. Master2 Agent 接收到指令，执行 `select master_pos_wait()` 等待同步完毕；
|
||||
6. Master2 Agent 上线写 VIP，把 Master2 节点设为 read_only=0；
|
||||
7. Monitor 发送更改同步对象的指令到各个 Slave 节点的 Agent；
|
||||
8. 各个 Slave 节点向新 Master 同步数据；
|
||||
|
||||
简单来说，MMM 就是暴力的将 Master1 切换到 Master2 ，它本生不会尝试去补齐丢失的数据。
|
||||
|
||||
### 4.2 MHA
|
||||
|
||||
1. 尝试从宕机 Master 中保存二进制日志；
|
||||
2. 找到含有最新中继日志的 Slave；
|
||||
3. 把最新中继日志应用到其他实例，实现各实例数据一致；
|
||||
4. 应用从 Master 保存的二进制日志事件；
|
||||
5. 提升一个 Slave 为 Master ；
|
||||
6. 其他 Slave 向该新 Master 同步。
|
||||
|
||||
当 Master 宕机后， MHA 会尝试保存宕机 Master 的二进制日志，然后自动判断 MySQL 集群中哪个实例的中继日志是最新的，并将有最新日志的实例的差异日志传到其他实例补齐，从而实现所有实例数据一致。然后把宕机 Master 的二进制日志应用到选定节点，并提升为 Master 。
|
||||
|
||||
从切换流程流程可以看到，如果宕机 Master 主机无法 SSH 登录，那么第一步就没办法实现，对于 MySQL5.5 以前的版本，数据还是有丢失的风险。对于 5.5 后的版本，开启**半同步复制**后，真正有助于避免数据丢失，半同步复制保证至少一个 （不是所有）slave 在 master 提交时接收到二进制日志事件。因此，对于可以处理一致性问题的 MHA 可以实现"几乎没有数据丢失"和"从属一致性"。
|
||||
|
||||
### 优点
|
||||
|
||||
- 开源，用 Perl 编写
|
||||
- 方案成熟，故障切换时，MHA 会做日志补齐操作，尽可能减少数据丢失，保证数据一
|
||||
- 部署不需要改变现有架构
|
||||
|
||||
### 限制
|
||||
|
||||
- 各个节点要打通 SSH 信任，有一定的安全隐患
|
||||
- 没有 Slave 的高可用
|
||||
- 自带的脚本不足，例如虚IP配置需要自己写命令或者依赖其他软件
|
||||
- 需要手动清理中继日志
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 参考资料
|
||||
|
||||
+ [MHA高可用架构](https://segmentfault.com/a/1190000017486693)
|
||||
|
||||
+ [MMM高可用架构](https://segmentfault.com/a/1190000017286307)
|
||||
|
||||
+
|
||||
Reference in New Issue
Block a user