第十一篇: mysql主从
作者:互联网
# 第1章 主从复制介绍
## 1.介绍
```
MySQL数据库的主从复制技术与使用scp/rsync等命令进行的异机文件级别复制类似,都是数据的远程传输.
只不过MySQL的主从复制技术是其软件自身携带的功能,无须借助第三方工具.
MySQL的主从复制并不是直接复制数据库磁盘上的文件,而是将逻辑的记录数据库更新的binlog日志发送到需要同步的数据库服务器本地,然后再由本地的数据库线程读取日志中的SQL语句并重新应用到MySQL数据库中,从而即可实现数据库的主从复制。
```
## 2.应用场景
```
1.从服务器作为主服务器的实时数据备份
2.主从服务器实现读写分离,从服务器实现负载均衡
3.根据业务重要性对多个服务器进行拆分
```
# 第2章 主从复制搭建部署
## 1.安装部署mysql实例
```
安装过程略,此处只给出3台实例的配置文件
# db-01配置
cat > /etc/my.cnf<<EOF
[mysqld]
user=mysql
datadir=/data/mysql_3306
basedir=/opt/mysql/
socket=/tmp/mysql.sock
port=3306
log_error=/var/log/mysql/mysql.err
server_id=51
log_bin=/binlog/mysql-bin
[mysql]
socket=/tmp/mysql.sock
[client]
socket=/tmp/mysql.sock
EOF
# db-52配置
cat > /etc/my.cnf<<EOF
[mysqld]
user=mysql
datadir=/data/mysql_3306
basedir=/opt/mysql/
socket=/tmp/mysql.sock
port=3306
log_error=/var/log/mysql/mysql.err
server_id=52
[mysql]
socket=/tmp/mysql.sock
[client]
socket=/tmp/mysql.sock
EOF
# db-53配置
cat > /etc/my.cnf<<EOF
[mysqld]
user=mysql
datadir=/data/mysql_3306
basedir=/opt/mysql/
socket=/tmp/mysql.sock
port=3306
log_error=/var/log/mysql/mysql.err
server_id=53
[mysql]
socket=/tmp/mysql.sock
[client]
socket=/tmp/mysql.sock
EOF
# 初始化
mysqld --initialize-insecure --user=mysql --basedir=/opt/mysql --datadir=/data/mysql_3306/
```
## 2.主库操作
### 2.1 创建复制用户
```
mysql -uroot -p123456 -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123';"
mysql -uroot -p123456 -e "select user,host,plugin from mysql.user;"
```
### 2.2 备份数据并发送到从库
```
mysqldump -uroot -p123456 -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=64M > /data/full.sql
scp /data/full.sql 10.0.0.52:/tmp/
scp /data/full.sql 10.0.0.53:/tmp/
```
## 3.从库操作
### 3.1 查看从库位置点
```
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=444;
```
### 3.2 导入主库数据
```
mysql -uroot -p123456 < /tmp/full.sql
```
### 3.3 配置主从同步信息
```
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;
```
### 3.4 启动线程
```
start slave;
```
## 4.查看复制状态
```
mysql -uroot -p123456 -e "show slave status\G"|grep "Running:"
```
# 第3章 主从复制原理
## 1.涉及到的线程
### 1.1 主库
线程说明:
```
binlog_dump_thread
负责接收slave请求和传送主库binlog给slave
```
查看命令:
```
mysql> show processlist;
+----+------+-----------------+------+-------------+------+---------------------------------------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------------+------+-------------+------+---------------------------------------------------------------+------------------+
| 32 | repl | 10.0.0.53:47726 | NULL | Binlog Dump | 284 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 33 | repl | 10.0.0.52:55250 | NULL | Binlog Dump | 280 | Master has sent all binlog to slave; waiting for more updates | NULL |
| 34 | root | localhost | NULL | Query | 0 | starting | show processlist |
+----+------+-----------------+------+-------------+------+---------------------------------------------------------------+------------------+
```
### 1.2 从库
线程说明:
```
IO线程 :
连接主库DUMP线程,请求Master日志、接收Master日志、存储日志(relay-log)。
SQL线程
回放relaylog
```
查看命令:
```
[root@db-52 ~]# mysql -uroot -p123456 -e "show slave status\G"|grep "Running:"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
```
## 2.涉及到的文件
### 2.1 主库
```
binlog日志文件
```
### 2.2 从库
relay-log 中继日志
```
命名方式:
datadir/HOSTNAME-relay-bin.00000N
作用:
存储获取到的binlog
```
主库信息文件
```
命名方式:
datadir/master.info
作用:
记录主库ip port user password binlog位置点等信息。
```
中继日志应用信息
```
命名方式:
relay-log.info
作用:
记录SQL 线程回放到的位置点信息。
```
## 3.画图说明主从复制原理--必须掌握--面试必问!
文字:
```
S: Change master to IP,Port,USER,PASSWORD,binlog位置信息写入到M.info中,执行Start slave(启动SQL,IO)。
S: 连接主库。
M: 分配Dump_T,专门和S_IO通信。show processlist;
S: IO线程:IO线程请求新日志
M: DUMP_T 接收请求,截取日志,返回给S_IO
S: IO线程接收到binlog,日志放在TCP/IP,此时网络层层面返回ACK给主库。主库工作完成。
S: IO将binlog最终写入到relaylog中,并更新M.info。IO线程工作结束。
S: SQL线程读R.info,获取上次执行到的位置点
S: SQL线程向后执行新的relay-log,再次更新R.info。
```
画图:
![](https://upload-images.jianshu.io/upload_images/14248468-c767332e0d143e91.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
# 第4章 主从复制监控
## 1.主库状态
查看复制线程:
```
[root@db-51 ~]# mysql -uroot -p123456 -e "show processlist" |grep "Dump"
mysql: [Warning] Using a password on the command line interface can be insecure.
32 repl 10.0.0.53:47726 NULL Binlog Dump 568 Master has sent all binlog to slave; waiting for more updates NULL
33 repl 10.0.0.52:55250 NULL Binlog Dump 564 Master has sent all binlog to slave; waiting for more updates NULL
```
查看复制节点信息:
```
[root@db-51 ~]# mysql -uroot -p123456 -e "show slave hosts;"
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID |
+-----------+------+------+-----------+--------------------------------------+
| 53 | | 3306 | 51 | 0f61194b-f733-11ea-8ca6-000c29c20a5d |
| 52 | | 3306 | 51 | 2fbe6b47-f731-11ea-9d25-000c29605eb5 |
+-----------+------+------+-----------+--------------------------------------+
```
## 2.从库状态
查看主从状态:
```
mysql -uroot -p123456 -e "show slave status \G"
```
主库连接信息、binlog位置信息
```
Master_Host: 10.0.0.51
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Read_Master_Log_Pos: 444
Relay_Master_Log_File: mysql-bin.000001
```
从库中relay-log的回放信息
```
Relay_Log_File: db-52-relay-bin.000002
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000001
Exec_Master_Log_Pos: 444
```
线程监控信息:主要用来排查主从故障-重点监控
```
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
```
过滤复制相关信息
```
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
```
落后于主库的秒数-重点监控
```
Seconds_Behind_Master: 0
```
延时从库状态信息
```
SQL_Delay: 0
SQL_Remaining_Delay: NULL
```
GTID复制信息
```
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
```
## 3.位置点信息
IO 已经获取到的主库Binlog的位置点
```
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 444
作用: IO下次请求日志时,起点位置。
```
SQL 回放到的relaylog位置点
```
Relay_Log_File: db01-relay-bin.000006
Relay_Log_Pos: 320
```
SQL回放的realylog位置点,对应的主库binlog的位置点
```
Relay_Master_Log_File: mysql-bin.000001
Exec_Master_Log_Pos: 600
作用: 计算主从复制延时日志量。
```
# 第5章 主从复制故障
## 1.如何监控
```
Slave_IO_Running: Yes # IO线程工作状态: YES、NO、Connecting
Slave_SQL_Running: Yes # SQL线程工作状态:YES、NO
Last_IO_Errno: 0 # IO故障代码:2003,1045,1040,1593,1236
Last_IO_Error: # IO线程报错详细信息
Last_SQL_Errno: 0 # SQL故障代码: 1008,1007
Last_SQL_Error: # IO线程报错详细信息
```
## 2.IO线程故障
### 2.1 正常状态
```
Slave_IO_Running: Yes
```
### 2.2 不正常状态
```
NO
Connecting
```
### 2.3 故障原因
```
1.网络,端口,防火墙
2.用户 ,密码,授权
replication slave
3.主库连接数上限
mysql> select @@max_connections;
4.版本不统一 5.7 native , 8.0 sha2
```
### 2.4 模拟故障
主库操作
```
mysql> start slave; # 启动所有线程
mysql> stop slave; # 关闭所有线程
mysql> start slave sql_thread; #单独启动SQL线程
mysql> start slave io_thread; #单独启动IO线程
mysql> stop slave sql_thread;
mysql> stop slave io_thread;
解除从库身份:
mysql> reset slave all;
mysql> show slave status \G
```
从库操作
```
stop slave;
reset slave all;
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
```
### 2.5 解决思路
```
1.网络是否互通
2.确定复制账号授权是否正确
3.主从的server id是否相同
4.重做从库
```
## 3.SQL线程故障
### 3.1 SQL线程主要工作
```
回放relay-log中的日志。可以理解为执行relay-log SQL
```
### 3.2 故障本质
```
为什么SQL线程执行不了SQL语句
```
### 3.3 故障原因
```
创建的对象已经存在
需要操作的对象不存在
约束冲突。
以上问题: 大几率出现在从库写入或者双主结构中容易出现。
```
### 3.4 故障模拟
```
(1)先在从库 create database oldguo charset=utf8;
(2)在主库 create database oldguo charset=utf8mb4;
(3)检查从库SQL线程状态
Slave_SQL_Running: No
Last_Error: Error 'Can't create database 'oldguo'; database exists' on query. Default database: 'oldguo'. Query: 'create database oldguo'
```
### 3.5 故障处理
思路1: 一切以主库为准
```
在从库上进行反操作一下。重启线程
mysql> drop database oldguo;
mysql> start slave;
```
思路2: 以从库为准,跳过此次复制错误,不建议
```
stop slave;
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个,如果多次不同步,可以重复操作。
start slave;
```
思路3: 暴力方法,遇到自动跳过。
```
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
```
思路4: 重新搭建主从
```
备份恢复+ 重新构建
```
# 第7章 过滤复制
## 1.过滤复制介绍
```
从节点仅仅复制指定的数据库,或指定数据库的指定数据表
```
## 2.主库实现
```
binlog_do_db 白名单
binlog_ignore_db 黑名单
通过是否记录binlog日志来控制过滤
```
## 3.从库实现
实现方法:
```
IO线程不做限制。
SQL线程回放时,选择性回放。
```
配置参数:
```
replicate_do_db=world
replicate_do_db=oldboy
replicate_ignore_db=
replicate_do_table=world.city
replicate_ignore_table=
replicate_wild_do_table=world.t*
replicate_wild_ignore_table=
```
配置方法1: 修改配置文件
```
replicate_do_db=world
replicate_do_db=oldboy
```
配置方法2: 在线热配置
```
STOP SLAVE SQL_THREAD;
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (oldguo, oldboy);
START SLAVE SQL_THREAD;
```
# 第8章 延时从库的应用
## 1.延时从库介绍
```
控制从库的SQL线程执行速度,二进制日志照常去主库取,但是存放到中继日志之后就延迟执行,如果主库被误操作,这时候对中继日志进行处理,就不用根据全备二进制日志恢复,节省了大部分的时间
```
## 2.配置方法
```
stop slave;
CHANGE MASTER TO MASTER_DELAY = 300;
start slave;
```
## 3.查看状态
```
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
```
## 3.故障处理流程
```
1. 及时监控故障: 主库 10:05发现故障,从库此时8:05数据状态
2. 立即将从库的SQL线程关闭。 需要对A业务挂维护页。
3. 停止所有线程。
4. 在延时从。恢复A库数据
手工模拟SQL线程工作,找到drop之前位置点。
SQL线程上次执行到的位置 ----> drop之前
relay.info ----> 分析drop位置点 ----> 截取relaylog日志 ----> source
```
## 4.故障模拟及恢复
主库操作:
```
create database json charset utf8mb4;
use json;
create table t1(id int);
insert into t1 values(1),(2),(3);
commit;
drop database json;
```
从库操作:
```
stop slave sql_thread;
show slave status \G;
```
截取日志:
起点:SQL上次执行到的位置点,
```
Relay_Log_File: db-52-relay-bin.000002
Relay_Log_Pos: 320
```
终点:drop 之前
```
mysql> show relaylog events in 'db-52-relay-bin.000002';
....略
| db-52-relay-bin.000002 | 985 | Query | 51 | 1201 | drop database json
```
截取日志:
```
mysqlbinlog --start-position=320 --stop-position=985 /data/mysql_3306/db-52-relay-bin.000002 >/tmp/bin.sql
```
从库恢复操作:
```
stop slave;
reset slave all;
set sql_log_bin=0;
source /tmp/bin.sql;
set sql_log_bin=1;
```
# 第9章 GTID复制
## 1.GITD复制介绍
```
功能:主从之间自动校验GTID一致性: 主库binlog,从库binlog ,relay-log
没有备份: 自动从主库的第一个gtid对应的pos号开始复制
有备份:
SET @@GLOBAL.GTID_PURGED='2386f449-98a0-11ea-993c-000c298e182d:1-10';
从库会自动从第11个gtid开始复制。
```
## 2.清理环境
```
pkill mysqld
rm -rf /data/mysql_3306/*
rm -rf /binlog/*
mkdir /binlog/
mkdir
```
## 3.准备配置文件
db01配置
```
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/opt/mysql
datadir=/data/mysql_3306
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF
```
db02配置
```
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/opt/mysql
datadir=/data/mysql_3306
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF
```
db03配置
```
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/opt/mysql
datadir=/data/mysql_3306
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF
```
## 4.初始化数据
```
mysqld --initialize-insecure --user=mysql --basedir=/app/database/mysql --datadir=/data/3306
```
## 5.启动数据库
```
/etc/init.d/mysqld start
```
## 6.创建用户
```
grant replication slave on *.* to repl@'10.0.0.%' identified by '123';
```
## 7.构建主从
52和53操作:
```
change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;
```
# 第10章 主从延时问题的原因和处理
## 1.什么是主从延时
```
主库发生了操作,从库'很久'才跟上来,甚至一直追不上
```
## 2.如何监控主从延时
粗略估计:
```
show slave status \G
Seconds_Behind_Master: 0
```
准确计算:
```
日志量:
主库binlog位置点
从relay执行的位置点
```
## 3.如何计算延时的日志量
```
show master status;
cat /data/3308/data/relay-log.info
```
## 4.主从延时的原因
### 4.1 主库可能的原因
```
外部原因:
网络,硬件配置,主库业务繁忙,从库太多
主库业务繁忙 :
1. 拆分业务(分布式): 组件分离 ,垂直 , 水平
2. 大事务的拆分 。比如,1000w 业务 拆分为 20次执行。
内部 :
1. 二进制日志更新问题:
解决方案:
sync_binlog=1
2. 问题: 5.7之前的版本,没有开GTID之前,主库可以并发事务,但是dump传输时是串行。
所以会导致,事务量,大事务时会出现比较严重延时。
解决方案:
5.6+ 版本,手工开启gtid,事务在主从的全局范围内就有了唯一性标志。
5.7+ 版本,无需手工开启,系统会自动生成匿名的GTID信息
有了GTID之后,就可以实现并发传输binlog。
但是,即使有这么多的优秀特性,我们依然需要尽可能的减少大事务,以及锁影响。
```
### 4.2 从库可能的原因
```
外部 :
网络,从库配置低,参数设定。
内部 :
IO线程:
写relay-log --> IO 性能。
SQL线程:
回放 SQL 默认在非GTID模式下是串行的
解决方案:
1. 开启GTID
```
标签:主库,slave,##,mysql,第十一篇,线程,SQL,主从 来源: https://www.cnblogs.com/haiqinai/p/16288180.html