主从复制高级

作者: 挑战_bae7 | 来源:发表于2020-11-26 10:36 被阅读0次

主从复制高级
2018-08-10mongodb聚合+group管道
主从复制-高级进阶
MySQL-lesson10-MHA高可用技术
MySQL-MHA高可用技术
MySQL-lesson10-MHA高可用技术
Redis在项目上的常用操作【二】
2019-04-19-主从复制架构演变-MHA高可用技术
2019-05-10MHA高可用技术
MySQL-MHA高可用技术

主从复制高级

延时从库

是我们认为配置的一种特殊从库.人为配置从库和主库延时N小时.
主要用于逻辑备份

配置
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间

mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300; ## 秒
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL

故障恢复

恢复思路
1主1从,从库延时5分钟,主库误删除1个库
1. 5分钟之内 侦测到误删除操作
2. 停从库SQL线程
3. 截取relaylog
起点 :停止SQL线程时,relay最后应用位置
终点:误删除之前的position(GTID)
4. 恢复截取的日志到从库
5. 从库身份解除,替代主库工作

模拟数据 删除
1.主库数据操作  
db01 [(none)]>create database relay charset utf8;
db01 [(none)]>use relay
db01 [relay]>create table t1 (id int);
db01 [relay]>insert into t1 values(1);
db01 [relay]>drop database relay;
2.从库查看
show binlog events in 'mysql-bin.000001'; ##查看主库的日志
stop slave sql_thread; ##停掉从库的sql线程 stop slave io_thread; ##停掉io线程
show relaylog events in 'db02-relay-bin.000002'；
+-----------------------+------+----------------+-----------+-------------+------------------------------------------------------------------
| Log_name              | Pos  | Event_type     | Server_id | End_log_pos | Info                                                             
+-----------------------+------+----------------+-----------+-------------+------------------------------------------------------------------
| db02-relay-bin.000002 |    4 | Format_desc    |         8 |         123 | Server ver: 5.7.32, Binlog ver: 4                                
| db02-relay-bin.000002 |  123 | Previous_gtids |         8 |         154 |                                                                  
| db02-relay-bin.000002 |  154 | Rotate         |         6 |           0 | mysql-bin.000001;pos=1063                                        
| db02-relay-bin.000002 |  201 | Format_desc    |         6 |           0 | Server ver: 5.7.32-log, Binlog ver: 4                            
| db02-relay-bin.000002 |  320 | Gtid           |         6 |        1128 | SET @@SESSION.GTID_NEXT= '5e873241-2e38-11eb-bd96-5254001adc46:6'
| db02-relay-bin.000002 |  385 | Query          |         6 |        1216 | create database yy                                               
| db02-relay-bin.000002 |  473 | Gtid           |         6 |        1281 | SET @@SESSION.GTID_NEXT= '5e873241-2e38-11eb-bd96-5254001adc46:7'
| db02-relay-bin.000002 |  538 | Query          |         6 |        1391 | create database relay charset utf8                               
| db02-relay-bin.000002 |  648 | Gtid           |         6 |        1456 | SET @@SESSION.GTID_NEXT= '5e873241-2e38-11eb-bd96-5254001adc46:8'
| db02-relay-bin.000002 |  713 | Query          |         6 |        1556 | use `relay`; create table t1 (id int)                            
| db02-relay-bin.000002 |  813 | Gtid           |         6 |        1621 | SET @@SESSION.GTID_NEXT= '5e873241-2e38-11eb-bd96-5254001adc46:9'
| db02-relay-bin.000002 |  878 | Query          |         6 |        1694 | BEGIN                                                            
| db02-relay-bin.000002 |  951 | Table_map      |         6 |        1740 | table_id: 161 (relay.t1)                                         
| db02-relay-bin.000002 |  997 | Write_rows     |         6 |        1790 | table_id: 161 flags: STMT_END_F                                  
| db02-relay-bin.000002 | 1047 | Xid            |         6 |        1821 | COMMIT /* xid=985 */                                             
| db02-relay-bin.000002 | 1078 | Gtid           |         6 |        1886 | SET @@SESSION.GTID_NEXT= '5e873241-2e38-11eb-bd96-5254001adc46:10
| db02-relay-bin.000002 | 1143 | Query          |         6 |        1981 | drop database relay                                              
+-----------------------+------+----------------+-----------+-------------+-----------------------------------------
发现pos 才是从库的中继日志的检查点 
 End_log_pos 是主库的binlog检查点
3306 [(none)]>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.122.103
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 1981
               Relay_Log_File: db02-relay-bin.000002  查看从库的文件及执行点
                Relay_Log_Pos: 473
mysqlbinlog --start-position=473 --stop-position=1143 /data/mysql/db02-relay-bin.000002  >/tmp/relay.log
mysqlbinlog --skip-gtids --include-gtids='5e873241-2e38-11eb-bd96-5254001adc46:7-9' /data/mysql/db02-relay-bin.000002  >/tmp/relay1.log
set sql_log_bin=0;
source /tmp/relay.log
3.解除从库身份
stop slave；
reset slave all;

半同步复制

解决主从数据一致性问题
1. 主库执行新的事务,commit时,更新 show master  status\G ,触发一个信号给
2. binlog dump 接收到主库的 show master status\G信息,通知从库日志更新了
3. 从库IO线程请求新的二进制日志事件
4. 主库会通过dump线程传送新的日志事件,给从库IO线程
5. 从库IO线程接收到binlog日志,当日志写入到磁盘上的relaylog文件时,给主库ACK_receiver线程
6. ACK_receiver线程触发一个事件,告诉主库commit可以成功了
7. 如果ACK达到了我们预设值的超时时间,半同步复制会切换为原始的异步复制.

配置
加载插件
主:
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
从:
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
查看是否加载成功:
show plugins;
启动:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
重启从库上的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;
查看是否在运行
主:
show status like 'Rpl_semi_sync_master_status';
从:
show status like 'Rpl_semi_sync_slave_status';

主从复制过滤

主库：
show master status;  主要记录白名单的二进制日志 不记录黑名单的 有隐患
Binlog_Do_DB  白名单
Binlog_Ignore_DB  黑名单
从库：
show slave status\G
Replicate_Do_DB: 
Replicate_Ignore_DB:  过滤库级别  常用
Replicate_Do_Table: 
Replicate_Ignore_Table:  过滤表级别
Replicate_Wild_Do_Table:  
Replicate_Wild_Ignore_Table:  模糊过滤表 像通配符那种

案例：
搭好主从架构后 从库配置
[root@db01 ~]# vim /etc/my.cnf 
replicate_do_db=ppt   ##注意不能大写 要小写
replicate_do_db=word
systemctl restart mysqld
检验数据

gtid的复制

gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1

gtid-mode=on                        --启用gtid类型，否则就是普通的复制架构
enforce-gtid-consistency=true               --强制GTID的一致性
log-slave-updates=1                 --slave更新是否记入日志 所有从库保持主库的UUID

GTID复制配置过程：为后面MHA做准备
1.配置文件
master
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
user=mysql
server_id=103
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\d]>
[client]
socket=/tmp/mysql.sock
EOF

slave1:
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
user=mysql
server_id=104
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\d]>
[client]
socket=/tmp/mysql.sock
EOF

slave2:
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
user=mysql
server_id=105
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\d]>
[client]
socket=/tmp/mysql.sock
EOF

2.用户
useradd -r -s /sbin/nologin mysql
mkdir /data/{mysql,binlog} -p
mkdir /data/mysql/data -p
chown  -R mysql.mysql /data/*
cat > /etc/profile.d/mysql.sh <<EOF
export PATH=/usr/local/mysql/bin:$PATH
EOF
source  /etc/profile.d/mysql.sh

3. 初始化
mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql  --datadir=/data/mysql/data

4.服务
cat > /etc/systemd/system/mysqld.service  <<EOF
[Unit]
Description=MySQL Server
Documentation=man:mysqld(8)
Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Group=mysql
ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf
LimitNOFILE = 500
EOF
systemctl daemon-reload
systemctl  start  mysqld.service

5.主库授权
grant replication slave on *.* to 'repl'@'192.168.122.%' identified by '123';
新环境 没有备份 如果有数据 就要备份恢复
mysqldump -uroot -p -A  -R  --triggers --set-gtid-purged=ON --master-data=2  --single-transaction >/tmp/sql.sql
set sql_log_bin=0
source /tmp/sql.sql

change master to 
master_host='192.168.122.103',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;

start slave;

故障：

查看监控信息:
Last_SQL_Error: Error 'Can't create database 'oldboy'; database exists' on query. Default database: 'oldboy'. Query: 'create database oldboy'

Retrieved_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3
Executed_Gtid_Set:  71bfa52e-4aae-11e9-ab8c-000c293b577e:1-2,
7ca4a2b7-4aae-11e9-859d-000c298720f6:1

注入空事物的方法：

stop slave;
set gtid_next='99279e1e-61b7-11e9-a9fc-000c2928f5dd:3';
begin;commit;
set gtid_next='AUTOMATIC';
    
这里的xxxxx:N 也就是你的slave sql thread报错的GTID，或者说是你想要跳过的GTID。
最好的解决方案：重新构建主从环境

gtid与普通复制区别
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;

change master to 
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;

（0）在主从复制环境中，主库发生过的事务，在全局都是由唯一GTID记录的，更方便Failover
（1）额外功能参数（3个）
（2）change master to 的时候不再需要binlog 文件名和position号,MASTER_AUTO_POSITION=1;
（3）在复制过程中，从库不再依赖master.info文件，而是直接读取最后一个relaylog的 GTID号
（4） mysqldump备份时，默认会将备份中包含的事务操作，以以下方式
    SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
    告诉从库，我的备份中已经有以上事务，你就不用运行了，直接从下一个GTID开始请求binlog就行。

主从复制高级
主从复制高级延时从库故障恢复半同步复制主从复制过滤 gtid的复制故障：
2018-08-10mongodb聚合+group管道
总论：高级操作讲解关于mongodb的高级操作，包括聚合、主从复制、分片、备份与恢复、MR 完成python与m...
主从复制-高级进阶
1.延时从库 1.1 作用处理逻辑损坏 1.2 怎么实现的 1.3 怎么处理逻辑损坏 drop 操作：（1）感...
MySQL-lesson10-MHA高可用技术
MySQL-lesson10-MHA高可用技术 1. 主从复制架构演变介绍 1.1 基本结构 1.2 高级应用架构...
MySQL-MHA高可用技术
1. 主从复制架构演变介绍 1.1 基本结构 1.2 高级应用架构演变 1.2.1 高性能架构 1.2.2 高可用...
MySQL-lesson10-MHA高可用技术
1. 主从复制架构演变介绍 1.1 基本结构 1.2 高级应用架构演变 1.2.1 高性能架构 1.2.2 高可用...
Redis在项目上的常用操作【二】
Redis的高级用法 redis集群 redis 主从复制概念：持久化保证了即使redis服务重启也不会丢失数据...
2019-04-19-主从复制架构演变-MHA高可用技术
1. 主从复制架构演变介绍 1.1 基本结构 1.2 高级应用架构演变 1.2.1 高性能架构（1）读写分离架构...
2019-05-10MHA高可用技术
1. 主从复制架构演变介绍 1.2 高级应用架构演变 1.2.1 高性能架构 1.2.2 高可用架构 3. 高...
MySQL-MHA高可用技术
主从复制架构演变介绍基本结构 MHA简介： MHA工作原理：高级应用架构演变高可用架构介绍高可用MHA *...