【复制系列】基于binlog文件和位置的传统复制

最新推荐文章于 2024-10-17 10:02:06 发布

weixin_34362790

最新推荐文章于 2024-10-17 10:02:06 发布

阅读量90

点赞数

文章标签：数据库 python

原文链接：https://my.oschina.net/starglm/blog/1359333

版权

2019独角兽企业重金招聘Python工程师标准>>>

前言

基于日志文件和位置的传统复制，是根据binlog文件和master_log_position确定复制的。

传统复制的原理

在master上，线程：dump_thread ；日志：binlog。

在slave上，线程：IO_thread 和 SQL_thread；日志：relay log。

1、在主库master中，记录二进制日志

在事务准备提交前，主库将更新的事件记录到binlog中，然后事务提交。注意，在binlog文件记录的事务均是按照事务提交顺序来记录的。

2、从库将主库的binlog复制到自己的relay log中

从库中的IO_thread 与主库建立一个连接，在主库，每当有新事件时，dump_thread会读取该事件，并发送给IO_thread，IO_thread 将接收到的事件记录在从库的relay log中。

3、SQL_thread 执行复制过来的事件

从库中的SQL_thread会执行relay log中记录的事件，以此更新从库的数据。但是，SQL_thread是否会将执行的事件记录到本地的binlog中，由参数log_slave_updates控制。

传统复制的搭建

机器环境：

以一主一从为例。
Master IP: 172.16.100.100
Slave IP: 172.16.100.101
两机器均已安装MySQL。

配置步骤：

# 主库（master）

在 my.cnf 中添加 or 修改：
- server-id=1003306 # IP最后一个字段+端口号
- log-bin=/data/mysql/mysql3306/mysql-bin
- binlog_format = row
在mysql中创建复制使用的账户：
- mysql> create user 'repl'@'172.16.100.101' identified by '123123';
- mysql> grant replication slave on *.* to 'repl'@'172.16.100.101' ;
- mysql> show master status\G

# 从库（slave）

在 my.cnf 中添加 or 修改：
- server-id=1013306 # IP最后一个字段+端口号
- log-bin=/data/mysql/mysql3306/mysql-bin
- binlog_format = row
- log_slave_updates # 使从库产生binlog，若不配置，即使开启log-bin参数，也不会产生binlog，若不需要binlog，则不用配置该参数
使从库指向从库（保证该操作之前复制线程已停止！）
- mysql>change master to master_host='172.16.100.100',master_user='repl',master_password='123123',master_log_file='mysql-bin.000001',master_log_pos=330;

# 开启和关闭复制（在从库操作）

start slave; # 开启复制
show slave status\G # 查看复制情况

解读 show slave status 的主要字段

Master_Log_File：IO thread 当前在读的主库binlog文件
Read_Master_Log_Pos：IO thread 已读到的主库binlog的位置
Relay_Log_File：SQL thread 正在读取的relay log文件
Relay_Log_Pos：SQL thread 已读取的relay log中的位置
Relay_Master_Log_File：SQL thread最近执行的事件所在主库的binlog文件
Slave_IO_Running：IO thread 是否在运行（必须为Yes，否则有问题）
Slave_SQL_Running：SQL thread 是否在运行（必须为Yes，否则有问题）
Replicate_Do(Ignore)_DB：在复制时，复制或忽略复制的库
Last_Errno/Last_Error：错误码/错误说明；通常主从报错时在这里显示错误的原因
Exec_Master_Log_Pos：705904595 # SQL thread已执行事件的主库binlog的位置，也标志将要处理下一个事件或事务的开始；通常这个位置在主库对应binlog文件中是这样的：

……

#170713 15:52:16 server id 1003306  end_log_pos 705904595 CRC32 0xaee2b643    Xid = 5191672348
COMMIT/*!*/;
# at 705904595
#170713 16:02:10 server id 1003306  end_log_pos 705904674 CRC32 0x97e59f40    Query   thread_id=1442126       exec_time=0     error_code=0
SET TIMESTAMP=1499932930/*!*/;
BEGIN     
/*!*/;

……

Seconds_Behind_Master：从库正在处理事件时，此时从库的时间戳与正被处理的事件在主库上记录的时间戳的差值（单位为秒）。实际上，该值测量的是SQL 线程和IO线程之差，在主从的网络很好的情况下，从库的IO线程和主库很接近，SQL线程和IO线程之差也就近似 SQL线程和主库之差（即是第一句的意思），因此，只有在网络很好的情况下，这个值才有参考性；而在网络不好的情况下，即使值为0，也不能说明没有延迟。
Last_IO_Error/Last_SQL_Error：IO thread出错的原因 / SQL thread出错的原因
SQL_Delay：从库必须滞后主库的秒数；因为有时会特意设置一个延迟的从库，用作误操作恢复
Retrieved_Gtid_Set：IO线程从主库所复制事务对应的GITD集合；但若没有开启GTID，则为空
Executed_Gtid_Set：在从库中已写入binlog的GTID集合，也是在从库show master status的Executed_Gtid_Set值；但若没有开启GTID，则为空