MySQL主从复制原理和搭建过程
简单介绍
二进制日志 binlog
什么是二进制日志
binlog
?
MySQL
的 binlog
日志是一种二进制格式的日志,记录所有的 DDL
和 DML
语句(不包括数据库查询语句)。不管用什么存储引擎,只要发生了表数据更新,都会产生 binlog
日志。
binlog
的用法
-
数据恢复
因为
binlog
记录了所有修改数据的SQL
,当数据库宕机数据丢失时,可以根据binlog
来回放历史数据。 -
主从复制
做多机备份的业务可以监听当前写库的
binlog
,同步写库的所有更改。
my.cnf
对binlog
的参数控制
# 设置此参数表示启用binlog功能,并制定二进制日志的存储目录
log-bin=/home/mysql/binlog/
# mysql-bin.*日志文件最大字节(单位:字节)
# 设置最大100MB
max_binlog_size=104857600
# 设置了只保留7天BINLOG(单位:天)
expire_logs_days = 7
# binlog日志只记录指定库的更新
#binlog-do-db=db_name
# binlog日志不记录指定库的更新
#binlog-ignore-db=db_name
# 写缓冲多少次,刷一次磁盘,默认0
sync_binlog=0
其中过期删除并不时定时执行的,需要以下事件触发:
- 服务器重启
- 服务器被更新
- 日志达到了最大日志长度
max_binlog_size
- 日志被刷新
binlog
日志格式
针对不同场景,binlog
提供了三种模式来提供不同详细程度的日志内容:
-
Statement
模式:保存每一条修改数据的
SQL
。该模式只保存一条普通的SQL
语句,不涉及到执行的上下文信息。 -
Row
模式:它不保存具体的
SQL
语句,而是记录具体被修改的信息。比如一条
update
语句更新10条数据,如果是Statement
模式那就保存一条SQL
就够,但是Row
模式会保存每一行分别更新了什么,有10条数据。Row
模式保存的时操作的详细信息,但是会带来存储空间的快速消耗。 -
Mixed
模式:根据具体的
SQL
来选择上面的哪种模式。
主从复制原理
什么是主从复制?
主从复制是指一台服务器充当主数据库服务器,另一台或多台服务器充当从数据库服务器,主服务器中的数据自动复制到从服务器之中。
对于多级复制,数据库服务器即可充当主机,也可充当从机。
MySQL
主从复制的基础是主服务器对数据库修改记录二进制日志,从服务器通过主服务器的二进制日志自动执行更新。
主从复制流程
主从复制涉及三个线程:binlog
线程、I/O
线程和 SQL
线程:
-
binlog
线程 :负责将主服务器上的数据更改写入二进制日志中。
-
I/O
线程 :负责从主服务器上读取二进制日志,并写入从服务器的中继日志(
Relay log
)中。
-
SQL
线程 :负责读取中继日志并重放其中的
SQL
语句。
总得来说流程如下:
- 在从节点上执行
start slave
开启主从复制。Slave
上的IO
线程连接上Master
,请求Master
上的binlog
。
Master
接收到来自Slave
的IO
线程的请求后,负责复制的IO
线程(log Dump Thread
)会根据请求信息读取日志指定位置之后的日志信息,返回给Slave
的IO
线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master
端的binlog
文件的名称(Binlog file
)以及binlog
的位置(Binlog position
)。
Slave
的IO
线程接收到信息后,将接收到的日志内容依次添加到Slave
端的relaylog
文件的最末端,并将读取到的Master
端的bin-log
的文件名和位置记录到master-info
文件中,以便在下一次读取的时候能够清楚的告诉Master
从何处开始读取日志。
Slave
的SQL
线程检测到relaylog
中新增加了内容后,会马上解析relaylog
的内容成在Master
端真实执行时候的那些可执行的内容,并在自身执行。
什么是
log dump
线程?
当从节点连接主节点时,主节点会为其创建一个 log dump
线程,用于发送和读取 Binlog
的内容。
在读取 Binlog
中的操作时,log dump
线程会对主节点上的 Binlog
加锁;当读取完成发送给从节点之前,锁会被释放。主节点会为自己的每一个从节点创建一个 log dump
线程。
relay log
如何产生?
从服务器 I/O
线程将主服务器的 binlog
日志读取过来,解析各类 Events
之后记录到从服务器本地文件,这个文件就被称为 relay log
。
然后 SQL
线程会读取 relay log
日志的内容并应用到从服务器,从而使从服务器和主服务器的数据保持一致。
中继日志充当缓冲区,这样 master
就不必等待 slave
执行完成才发送下一个事件。
使用 Docker 搭建主从复制
运行环境
- Ubuntu:20.04.3 LTS
- Docker:20.10.7
- MySQL:8
搭建过程
运行 master 容器
docker run -d --name master -p 3307:3306 -v /opt/mysql/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=123456 mysql
这里 -p
代表端口映射关系,我们将容器的 3306 端口映射到主机的 3307 端口上;-e
代表设置环境变量,通过设置 MYSQL_ROOT_PASSWORD
,我们将 root
用户密码设成 123456
。
进入 master 容器并修改配置
docker exec -it master /bin/bash
进入容器后再进入 MySQL
:
mysql -u root -p123456
创建 master
的复制账号,授予复制的权限:
create user 'pixel'@'%' identified by '123456';
ALTER USER 'pixel'@'%' IDENTIFIED WITH mysql_native_password BY '123456';
grant replication slave on *.* to 'pixel'@'%';
flush privileges; # 刷新权限
授权命令格式:grant 权限 on 数据库名.表名 to 用户@登录主机 identified by "用户密码";
。这里 pixel
为用户名,123456
为密码,@
后面填写从服务器 ip 而 %
表示任意的客户端。
修改 master 配置,开启
binlog
,设置server-id
,server-id
值唯一
[mysqld]
#启用二进制日志
log-bin=mysql-bin
#主服务器唯一ID
server-id=1
#设置logbin格式
binlog_format=STATEMENT
# 设置不要复制的数据库(可设置多个)
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
# 设置需要复制的数据库 需要复制的主数据库名字
binlog-do-db=testdb
配置完成重启容器,进入 MySQL
查看二进制文件名和位置,这个值在从容器上会用到:
Show master status;
到此位置主容器配置完成,接下来运行一个从容器
运行从容器,并且将端口映射到主机的 3308 端口
docker run -d --name slave -p 3308:3306 -v /opt/mysql/slave/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=123456 mysql
修改从容器配置,开启
binlog
:
[mysqld]
#启用中继日志
relay-log=mysql-relay
#从服务器唯一ID
server-id=2
配置完成后重启容器。
在从容器中配置主从关系
查看 master
容器的虚拟 ip 地址
docker inspect master
执行同步 SQL 语句,同步 master
账号信息
CHANGE MASTER TO
MASTER_HOST='172.17.0.2',
MASTER_USER='pixel',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=157;
启动 slave
:
start slave;
执行下面命令,查看 slave
状态
show slave status\G;
下面两个参数都是 Yes
说明主从配置成功!
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
这样一来,我们在主机上创建数据库,创建表,修改表记录的操作都相当于在从机上也执行了一遍。最后达到数据一致的效果!
重置主从关系命令
在 MySQL
控制面板下执行
停止从服务复制功能
stop slave;
重新配置主从(清除先前的主从配置)
stop slave;
reset master;
小结
本篇我们从 MySQL
的二进制日志开始介绍,接着分析了主从复制的原理,并且用 Docker
搭建了主从复制。
本篇参考:
转载自:https://juejin.cn/post/7180987829151858747