mysql

发布日期: 2020-05-19

作者: 小明

文章字数: 5.6k

阅读时长: 26 分

阅读次数:

1-延时从库

1-介绍

QQ图片20200515154534

普通的主从复制，处理物理故障损坏比较擅长。
如果主库出现了DROP DATABASE操作。
延时从库： 主库做了某项操作之后，从库延时多长时间回放（SQL）。可以处理逻辑损坏。

2-配置

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

3- 监控方法

方法一：有没有延时

Seconds_Behind_Master: 0

方法二：主库：

mysql> show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000004 |   151847 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

从库：

[root@db01 data]# mysql -S /tmp/mysql3308.sock -uroot -p123  -e "show slave status \G"|grep "Master_Log"


已经拿到的主库日志量(master.info)：判断传输有没有延时
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 151847

已经执行的主库日质量(relay-log.info): 判断回放有没有延时
Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847


计算主从复制延时日志量。

4-导致延时的主要原因

网络延时  
主从硬件、参数等不一致
从库太多。
主库压力大。

主库 
（1） binlog记录不及时。
mysql> select @@sync_binlog;
+---------------+
| @@sync_binlog |
+---------------+
|             1 |
+---------------+

参数说明： 
       1 ： 每次事务提交都立即刷新binlog到磁盘。 
       0 ： 由操作系统决定，什么刷新磁盘。

（2） DUMP线程串行工作。

大事务、并发事务高、DDL
解决办法： 
    5.6版本加入GTID复制模式，但手工配置。DUMP在传输日志时可以并发。
    5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息。

（3）怎么判断是主库导致的延时？

主库： 
mysql> show master status ;
从库： 
mysql -S /tmp/mysql3308.sock -uroot -p123  -e "show slave status \G"|grep "Master_Log"

从库方面

IO线程： 
从库IO比较慢。relay 落地慢。可以将realy放到 SSD

SQL 线程：串行回放。

主库可以并行事务，从库SQL线程串行回放。
所以：并发事务高、大事务、DDL

解决方法： 
       5.6 版本： 开启GTID后，可以多SQL线程，只能针对不同的库的事务进行并行SQL恢复。
       5.7 版本： 做了增强，基于逻辑时钟的并行回放。MTS。

的从库并发配置方法。开了GTID的前提前面gutid 后面逻辑时钟

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16  #线程数量
master_info_repository=TABLE
relay_log_info_repository=TABLE

已经执行的主库日质量(relay-log.info): 判断回放有没有延时

Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847

5-延时从库的应用-故障模拟

1-配置方法：

mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
·    
change master to master_delay
mysql>start slave;
mysql> show slave status \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL

2-恢复思路

1. 先停业务，挂维护页。    10:10
2. 停从库SQL线程。
   stop slave sql_thread;  10:10
   看relay.info ----> 位置点。
   stop slave ;


   -----------------------
   主库发生了逻辑损坏（DROP，truncate）时，可以使用延时从库快速恢复数据。


    2小时延时  
    10：00  做的drop database A;
1. 及时监控故障： 主库 10:05发现故障，从库此时8:05数据状态
2. 立即将从库的SQL线程关闭。 需要对A业务挂维护页。
3. 停止所有线程。
4. 在延时从。恢复A库数据
   手工模拟SQL线程工作，直到drop之前位置点。
   SQL线程上次执行到的位置------》drop之前
   relay.info   ----> 分析drop位置点   ---》 截取relaylog日志----》 source

3-故障模拟及恢复

故障模拟：   主库
create database delaydb charset utf8mb4;
use delaydb;
create table t1(id int);
insert into t1 values(1),(2),(3);
commit;

drop database delaydb;

4-恢复过程：

==查看日志是否接收完毕==

1. 
从库：  stop slave sql_thread;

2-截取日志：

>show relaylog   events in "db01-relay-bin.000002";

起点: SQL上次执行到的位置点，
Relay_Log_File: db01-relay-bin.000004
Relay_Log_Pos: 320


终点： drop 之前 
>show relaylog   events in "db01-relay-bin.000002";    


db01-relay-bin.000004 | 1006 | Query          |         7 |      152967 | drop databas

[root@db01 tmp]# mysqlbinlog --start-position=320 --stop-position=1006 /data/3309/data/db01-relay-bin.000004 >/tmp/bin.sql

3-从库恢复

mysql> reset slave all;
mysql> set sql_log_bin=0;
mysql> source /tmp/bin.sql;
mysql> set sql_log_bin=1;

mysql> show  tables;
+-------------------+
| Tables_in_delaydb |
+-------------------+
| t1                |
+-------------------+
1 row in set (0.00 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+

2-过滤复制

1-配置方法

主库： 
白名单: 
binlog_do_db=world
黑名单： 
binlog_ignore_db 

从库：
库级别： 
replicate_do_db=world  
replicate_ignore_db=xxxx 

表级别：
replicate_do_table=world.t1
replicate_ignore_table=

表级别： 模糊匹配
replicate_wild_do_table=world.t*  模糊 表
replicate_wild_ignore_table=

例子：  只复制oldboy和oldguo库的数据到3309
vim /data/3309/my.cnf
replicate_do_db=oldguo
replicate_do_db=oldboy
[root@db01 ~]# systemctl restart mysqld3309

mysql> show slave status\G
Replicate_Do_DB: oldguo,oldboy

2-方法一：

修改配置文件并重启
vim /data/3308/my.cnf 
replicate_do_db=world
replicate_do_db=oldboy

systemctl restart mysqld3308

3-方法二：

db01_5.7 [(none)]>help change

STOP SLAVE SQL_THREAD;
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (oldguo, oldboy);
START  SLAVE SQL_THREAD;
-------
stop slave sql_thread;
change replication filter replicate_do_db = (oldguo, oldboy);
start  slave sql_thread;

3-半同步复制

在 Classic replication : 
    传统异步非GTID复制工作模型下，会导致主从数据不一致情况。
5.5 版本为了保证主从数据的一致性问题。加入了半同步复制的组件（插件）    
在主从结构中，都加入了半同步复制的插件。
控制从库IO是否将relaylog落盘，一旦落盘通过插件返回ACK给主库ACK_rec。接受到ACK之后，主库的事务才能
提交成功。在默认情况下，如果超过10秒没有返回ACK，此次复制行为会切换为异步复制。
在 5.6 ，5.7当中也加入了一些比较好的特性（After commit ， after sync ，无损...），
也不能完全保证5个9以上的数据一致。

如果生产业务比较关注主从最终一致（金融类）。我们推荐可以使用MGR的架构，或者PXC等一致性架构。

4-GTID复制

作用： 主要保证主从复制中的高级的特性。
GTID：5.6 版本出现没有默认开启，5.7 中即使不开启也有匿名的GTID记录。
      DUMP传输可以并性，SQL线程并发回放提供了。5.7.17+的版本以后几乎都是GTID模式了。

1-搭建GTID：

准备三台虚拟机
    IP：      51 52 53   
    hostname: db01  db02 db03
    防火墙关闭
    能够实现远程xshell链接

1-清理环境

pkill mysqld
rm -rf /data/mysql/data/* 
rm -rf /data/binlog/* 
mkdir -p /data/mysql/data /data/binlog 


chown -R mysql.mysql /data/*  

2. 清理环境(三个节点都做)

2-生成配置文件

主库db01：
mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=51
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]>
EOF


------------------------------

slave1(db02)：
mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=52
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]>
EOF

slave2(db03)：
mv /etc/my.cnf /tmp
cat > /etc/my.cnf <<EOF
[mysqld]
basedir=/data/app/mysql
datadir=/data/mysql/data
socket=/tmp/mysql.sock
server_id=53
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]>
EOF

3-初始化数据(三个节点都做)

mysqld --initialize-insecure --user=mysql --basedir=/data/app/mysql  --datadir=/data/mysql/data

4-启动数据库

/etc/init.d/mysqld start

5-构建主从：

主库创建用户（db01）
db01 [mysql]>grant replication slave on *.* to repl@'10.1.0.%' identified by '123';

6-从库开启主从

52\53:

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

说明：
gtid的主从复制  ，第一次开启的时候，读取relaylog的最后gtid+读取gtid_purge参数，确认复制起点。

5- MHA高可用技术

数据损坏的类型

物理损坏 ：磁盘、主机、程序、数据文件
逻辑损坏 ：drop ..

2. 高可用解决方案选型依据：全年无故障率

无故障时间           故障时间                     解决方案
99.9%                0.1%     = 525.6  min        KA+双主 ：人为干预 
99.99%               0.01%    = 52.56  min        MHA  ：半自动化  
应用场景：比较适合非金融类互联网公司。 facebook MHA ，淘宝 TMHA  --》polardb。 替代产品：  ORCH go语言。
99.999%              0.001%   = 5.256  min        PXC 、 MGR 、MGC
应用场景： 金融类业务。
99.9999%             0.0001%  = 0.5256 min        自动化、云化、平台化

MHA 软件结构

1-manager 组件

masterha_manger             启动MHA 
masterha_check_ssh          检查MHA的SSH配置状况 
masterha_check_repl         检查MySQL复制状况，配置信息
masterha_master_monitor     检测master是否宕机 
masterha_check_status       检测当前MHA运行状态 
masterha_master_switch      控制故障转移（自动或者手动）
masterha_conf_host          添加或删除配置的server信息

2-node 组件

node 组件
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志（不会阻塞SQL线程）

3-MHA基础架构规划和实施

1-规划:

主库	10.0.1.51	node
从库:	10.0.1.52	node
从库:_兼 _管理节点	10.0.1.53	node manager

==准备环境（略。1主2从GTID）==

2.配置关键程序软连接（所有节点）

ln -s /app/database/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /app/database/mysql/bin/mysql          /usr/bin/mysql

软件写死了必须做软链接

3- 配置各节点互信（密钥对）

db01：
rm -rf /root/.ssh 
ssh-keygen
cd /root/.ssh 
mv id_rsa.pub authorized_keys  #必须全部互信，自己链接自己也可以通
scp  -r  /root/.ssh  10.0.0.52:/root 
scp  -r  /root/.ssh  10.0.0.53:/root 
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

4-安装软件

下载mha软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads


# 说明： 
8.0 的版本: 
1. 密码加密模式 sha2  ---> native 
2. 使用0.58 版本MHA软件

所有节点安装Node软件依赖包

yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

在db01主库中创建mha需要的用户

grant all privileges on *.* to mha@'10.0.1.%' identified by 'mha';

Manager软件安装（db03）

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

Manager配置文件准备(db03)

mkdir -p /etc/mha
#创建日志目录
 mkdir -p /var/log/mha/app1
#编辑mha配置文件
cat > /etc/mha/app1.cnf <<EOF
[server default]
manager_log=/var/log/mha/app1/manager         # MHA的工作日志设置
manager_workdir=/var/log/mha/app1             # MHA工作目录        
master_binlog_dir=/data/binlog                # 主库的binlog目录
user=mha                                      # 监控用户                      
password=mha                                  # 监控密码
ping_interval=2                               # 心跳检测的间隔时间
repl_password=123                             # 复制用户
repl_user=repl                                # 复制密码
ssh_user=root                                 # ssh互信的用户
[server1]                                     # 节点信息....
hostname=10.0.0.51
port=3306  

[server2]            
hostname=10.0.0.52
port=3306
candidate_master=1


[server3]
no_master=1
hostname=10.0.0.53
port=3306
EOF

状态检查（db03）

masterha_check_repl  --conf=/etc/mha/app1.cnf 
masterha_check_ssh   --conf=/etc/mha/app1.cnf

-----------------------------------------------------
masterha_check_ssh   --conf=/etc/mha/app1.cnf 
--------------------------------------------------

Mon May 18 12:45:26 2020 - [debug]   ok.
Mon May 18 12:45:27 2020 - [info] All SSH connection tests passed successfully.
------------------------------------------------------------
masterha_check_repl  --conf=/etc/mha/app1.cnf 
--------------------------------------------------------------------
 +--10.0.1.62(10.0.1.62:3306)
 +--10.0.1.63(10.0.1.63:3306)

Mon May 18 12:45:58 2020 - [info] Checking replication health on 10.0.1.62..
Mon May 18 12:45:58 2020 - [info]  ok.
Mon May 18 12:45:58 2020 - [info] Checking replication health on 10.0.1.63..
Mon May 18 12:45:58 2020 - [info]  ok.
Mon May 18 12:45:58 2020 - [warning] master_ip_failover_script is not defined.
Mon May 18 12:45:58 2020 - [warning] shutdown_script is not defined.
Mon May 18 12:45:58 2020 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

5-开启MHA-manager

![QQ图片20200518150423](tup/QQ%E5%9B%BE%E7%89%8720200518150423.png)开启MHA(db03)：
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

3.3.8 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51

4-MHA工作原理

QQ图片20200518150423

1-MHA的设计原理

 MHA的设计原理（Failover 过程）

# 1. 启动MHA 软件 
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

# 2. 监控  
/usr/bin/masterha_master_monitor ，每隔ping_interval秒探测1次，连续4次还没有，说明主库宕机。

# 3. 选新主
3.1 日志量 latest 

3.2 备选主 pref

3.3 哪些不被选主 bad
no_master=1
log_bin 二进制日志没开
check_slave_delay，如果从库落后主库100M的日志量（可以关闭）

数组： 
alive   : 存活
latest  ：最新
pref    ：备选
bad     ：不选

2-选主判断：

伪代码：
if 情况
=1. 如果pref和bad数组当中slave的个数为0，则选择latest数组当中的第一个slave为master。
db02没有candidate_master，又没有以下bad三种情况，db02恰好是latest。

=2. 循环对比latest数组和perf数组的slave，如果存在相同的slave，并且这个slave不在bad数组当中，该slave会被推选为新的master。
db02 pref , latest  ,又不是bad，会被选主。


=3. 循环对比slaves数组pref数组当中的slave，如果有一个slave相同并且不在bad数组当中，该就会成为新的master。
db02 ,不是latest,不是bad,是pref。会被选择。


=4. 循环latest数组，如果又循环到的slave不在bad数组当中，这个slave就会成为master。
    也就是说就算添加了candidate_master=1，该slave也不一定会成为主库。

    db02 , latest  ,不是bad 
    db03 , pref,不是latest ,不是bad 

=5. 从活着的slave当中进行循环，如果循环到的slave不在bad数组当中，那么这个slave就会成为主库。    
    db02 ，slaves ,不是bad 。

else 如果进行了多次选择都找不到主库，那么主库选择失败，failover失败。

3-数据补偿：

4.1 原主库ssh能连接 
    各个从节点调用： save_binary_logs 脚本，立即保存缺失部分的binlog到各自节点/var/tmp目录。
4.2 原主库ssh不能连接 
    从节点调用apply_diff_relay_logs  ，进行relay-log日志差异补偿。

4.3. 额外数据补偿(主库日志冗余机制)
     binlog_server.

5. 切换 
   所有从库解除主从身份。stop slave ; reset slave;
   重构新的主从关系。change master to 

6. 应用透明(vip)

7. 故障提醒

8. 额外数据补偿


9. 剔除故障节点

10. manager 程序"自杀"

5-应用透明vip功能

5.0 vip 介绍 
#作用网卡：
eth0:1 
ens33:1
# IP
vip :   10.0.0.55/24
一定是一个空闲地址。
一定要和对外提供服务的地址同一网段。
不能跨网段。

5.1 vip 故障转移脚本

脚本——是故障转移切换脚本

上传脚本文件到/usr/local/bin 
[root@db03 mha_script]# \cp -a * /usr/local/bin

5.2 修改权限 
[root@db03 bin]# chmod +x /usr/local/bin/*

5.3 修改内容
[root@db03 bin]#vim  /usr/local/bin/master_ip_failover

需要修改ip已经网卡

my $vip = '10.0.0.55/24';
my $key = '1';
my $if  = 'ens33';
my $ssh_start_vip = "/sbin/ifconfig $if:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig  $if:$key down";
my $ssh_Bcast_arp= "/sbin/arping -I $if -c 3 -A 10.0.0.55";

5.2 修改Manager 配置文件

vim /etc/mha/app1.cnf 

master_ip_failover_script=/usr/local/bin/master_ip_failover

5.3-主库上，手工生成第一个vip地址

[root@db02 ~]# ifconfig eth0:1 10.0.0.55/24

6.故障提醒功能

6.1 准备脚本

[root@db03 bin]# vim  send_report 
my $smtp='smtp.qq.com';             # smtp服务器
my $mail_from='22654481@qq.com';    # 发件箱
my $mail_user='22654481';           # 用户名 QQ号
my $mail_pass='gemghsvgkeyzcagh';   # 授权码
my $mail_to=['22654481@qq.com'];    # 收件箱

#my $mail_to=['to1@qq.com','to2@qq.com']; #多个发送

6.2 修改配置文件

vim /etc/mha/app1.cnf 
# 添加一行： 
report_script=/usr/local/bin/send_report

6.3 重启MHA(db03)

[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

6.4检测状态：

[root@db03 data]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:6640) is running(0:PING_OK), master:10.0.0.51

# 注意：
keepAlive的话 ，需要 candidate_master=1和check_repl_delay=0进行配合。防止vip和主库选择不在一个节点。

6-日志补偿的冗余方案–binlog_server

6.1创建必要目录(db03)

mkdir -p /data/binlog_server/

chown -R mysql.mysql /data/*
cd  /data/binlog_server/

[root@db03 ~]# mysql -e "show slave status \G"|grep "Master_Log"
mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000002 &

cd  /data/binlog_server/   -----》必须进入到自己创建好的目录

注意：
拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点

6.2-配置文件设置

vim /etc/mha/app1.cnf 
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/binlog_server/

6.3 重启MHA

[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf 
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

6.4测试MHA Failover的功能

. 测试MHA Failover的功能
# 宕掉主库测试
测试查看  vip
查看邮件  
故障库是否剔除
切换日志/var/log/mha/app1/manager
主从状态

7. MHA高可用，故障模拟及恢复演练

主库  /etc/initd/mysql stop

1. 排查进程状态

[root@db03 bin]# ps -ef |grep manager
root      13087   2813  0 16:33 pts/1    00:00:00 grep --color=auto manager


[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 is stopped(2:NOT_RUNNING).



[root@db03 /data/binlog_server] # masterha_check_repl --conf=/etc/mha/app1.cnf

2. 检查配置文件中节点

[root@db03 bin]# cat /etc/mha/app1.cnf 
如果节点已经被移除，说明切换过程已经大部分成功。
如果节点还在，证明切换过程在中间卡住。

3. 看日志

vim /var/log/mha/app1/manager

4. 修复故障库

[root@db01 ~]# /etc/init.d/mysqld start
Starting MySQL.. SUCCESS!

5. 修复主从（主从是好的，可略过）

将故障库修好后，手工加入已有的主从中，作为从库。
change master to 
master_host='10.0.1.61',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;
start slave;

6. 将配置文件修复（配置文件节点信息还在，可忽略）

添加: 
[server1]
hostname=10.0.0.61
port=3306

7. 检查ssh互信和repl的主从关系

masterha_check_ssh   --conf=/etc/mha/app1.cnf 
masterha_check_repl  --conf=/etc/mha/app1.cnf

8. 修复binlogserver（注意拉去当前主库）

[root@db03 ~]# cd /data/mysql/binlog/
[root@db03 binlog]# rm -rf *
[root@db03 binlog]# mysqlbinlog  -R --host=10.0.1.61 --user=mha --password=mha --raw  --stop-never mysql-bin.000004 &

9.检查主节点vip的状态

 如果不在，再手工生成一下。

10. 启动MHA

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/mha/app1/manager.log 2>&1 &

[root@db03 binlog]# masterha_check_status --conf=/etc/mha/app1.cnf 
app1 (pid:13189) is running(0:PING_OK), master:10.0.0.52

mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

11.快速恢复

1主2从：
[root@db03 binlog_server]# mysql -e "show slave status\G" |grep "Master_Host"
Master_Host: 10.0.0.52
[root@db01 data]#  mysql -e "show slave status\G" |grep "Master_Host"

修复1主从：
db01: 

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

[root@db01 data]#  mysql -e "show slave status\G" |grep "Master_Host"
                  Master_Host: 10.0.0.52


9.2 检查vip是否在主库
[root@db02 data]# ip a

9.3 检查binlog_server状态 
[root@db03 binlog_server]# ps -ef |grep mysqlbinlog
root      77828  39593  0 17:53 pts/2    00:00:00 grep --color=auto mysqlbinlog
[root@db03 binlog_server]# 

修复binlog_server: 
[root@db03 binlog_server]# rm -rf /data/binlog_server/*

[root@db03 binlog_server]# cd /data/binlog_server/
[root@db03 ~]# mysql -e "show slave status \G"|grep "Master_Log"
[root@db03 ~]# mysqlbinlog  -R --host=10.0.0.52 --user=mha --password=mha --raw  --stop-never mysql-bin.000002 &


9.4 检查配置文件 
三个节点是否存在：
[root@db03 binlog_server]# cat /etc/mha/app1.cnf 

添加新节点到配置文件： 
masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --hostname=10.0.1.62 --block=server1 --params="port=3306"

++++++++
masterha_conf_host --command=delete --conf=/etc/mha/app1.cnf --block=server1
++++++++


9.5 检查ssh互信和repl

[root@db03 ~]# masterha_check_ssh  --conf=/etc/mha/app1.cnf
[root@db03 ~]# masterha_check_repl  --conf=/etc/mha/app1.cnf 


9.6 启动MHA 
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

[root@db03 ~]# masterha_check_status   --conf=/etc/mha/app1.cnf 
app1 (pid:78201) is running(0:PING_OK), master:10.0.0.52
[root@db03 ~]#

8-MHA的维护操作 - 在线切换功能

8.1 只切换角色

masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.1.61 --orig_master_is_new_slave --running_updates_limit=10000

注意： 
master_ip_online_change_script is not defined. If you do not disable writes on the current master manually, applications keep writing on the current master. Is it ok to proceed? (yes/NO): yes

9.6 启动MHA 
[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

此种方法切换，要注意将原主库，FTWRL（Flush table with read lock），否则会造成主从不一致。

手工切换vip

重新拉去新主库的binlog

8.2 master_ip_online_change_script功能实现

功能: 在线切换时，自动锁原主库，VIP自动切换

8.2.1 准备切换脚本

vim /usr/local/bin/master_ip_online_change

my $vip = "10.0.0.55/24";
my $key = "1";
my $ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig ens33:$key $vip down";
my $ssh_Bcast_arp= "/sbin/arping -I ens33 -c 3 -A 10.0.0.55";

8.2.2 修改MHA配置文件

vim /etc/mha/app1.cnf
master_ip_online_change_script=/usr/local/bin/master_ip_online_change

8.2.3 停 MHA

[root@db03 bin]# masterha_stop  --conf=/etc/mha/app1.cnf

8.2.4 检查repl

[root@db03 bin]# masterha_check_repl   --conf=/etc/mha/app1.cnf

8.2.4 在线切换

masterha_master_switch  --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.1.61 --orig_master_is_new_slave --running_updates_limit=10000

8.2.5 重构binlogserver

[root@db03 bin]# ps -ef |grep mysqlbinlog
root      28144  16272  0 17:50 pts/1    00:00:00 mysqlbinlog -R --host=10.0.0.52 --user=mha --password=x x --raw --stop-never mysql-bin.000004
root      28529  16272  0 18:03 pts/1    00:00:00 grep --color=auto mysqlbinlog
[root@db03 bin]# kill -9 28144
[root@db03 bin]# cd /data/binlog_server/
[root@db03 binlog_server]# ll
total 4
-rw-r----- 1 root root 194 Apr  1 17:50 mysql-bin.000005
[root@db03 binlog_server]# rm -rf *
[root@db03 binlog_server]# mysqlbinlog  -R --host=10.0.1.62 --user=mha --password=mha --raw  --stop-never mysql-bin.000004 &
[1] 28534

8.2.6 启动MHA

[root@db03 bin]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

[root@db03 binlog_server]# masterha_check_status   --conf=/etc/mha/app1.cnf 
app1 (pid:28535) is running(0:PING_OK), master:10.0.0.51

9-Atlas读写分离中间件应用

1. 介绍
Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。
它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。
360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。
下载地址
https://github.com/Qihoo360/Atlas/releases

注意：

1、Atlas只能安装运行在64位的系统上
2、Centos 5.X安装 Atlas-XX.el5.x86_64.rpm，Centos 6.X安装Atlas-XX.el6.x86_64.rpm。
3、后端mysql版本应大于5.1，建议使用Mysql 5.6以上

1. 安装

https://github.com/Qihoo360/Atlas/releases

[root@db03 data]# rpm -ivh Atlas-2.2.1.el6.x86_64.rpm 
Preparing...                          ################################# [100%]
Updating / installing...
   1:Atlas-2.2.1-1                    ################################# [100%]
[root@db03 data]#

2. 配置

cd /usr/local/mysql-proxy/conf
mv test.cnf test.cnf.bak
cat > test.cnf <

3-启动atlas

/usr/local/mysql-proxy/bin/mysql-proxyd test restart
ps -ef |grep proxy

2-Atlas功能测试

测试读操作：

mysql -umha -pmha  -h 10.0.0.53 -P 33060 
db03 [(none)]>select @@server_id;

测试写操作：

mysql> begin;select @@server_id;commit;

注意:
DDL建议不要再Atlas触发，最好是到主库触发（Online DDL或者PT-OSC）。
DML建议begin; DML; commit;

3-Atlas 的管理操作

[root@db03 conf]# mysql -uuser -ppwd -h 10.0.0.53 -P2345
db03 [(none)]>select * from help;

查看所有节点

db03 [(none)]>SELECT * FROM backends;
+-------------+----------------+-------+------+
| backend_ndx | address        | state | type |
+-------------+----------------+-------+------+
|           1 | 10.0.0.55:3306 | up    | rw   |
|           2 | 10.0.0.52:3306 | up    | ro   |
|           3 | 10.0.0.53:3306 | up    | ro   |
+-------------+----------------+-------+------+
3 rows in set (0.00 sec)

节点的上线和下线

db03 [(none)]>SET OFFLINE 1;
+-------------+----------------+---------+------+
| backend_ndx | address        | state   | type |
+-------------+----------------+---------+------+
|           1 | 10.0.0.55:3306 | offline | rw   |
+-------------+----------------+---------+------+
1 row in set (0.01 sec)

db03 [(none)]>SELECT * FROM backends;
+-------------+----------------+---------+------+
| backend_ndx | address        | state   | type |
+-------------+----------------+---------+------+
|           1 | 10.0.0.55:3306 | offline | rw   |
|           2 | 10.0.0.52:3306 | up      | ro   |
|           3 | 10.0.0.53:3306 | up      | ro   |
+-------------+----------------+---------+------+

db03 [(none)]>SET ONLINE 1;
+-------------+----------------+---------+------+
| backend_ndx | address        | state   | type |
+-------------+----------------+---------+------+
|           1 | 10.0.0.55:3306 | unknown | rw   |
+-------------+----------------+---------+------+

删除和添加节点

db03 [(none)]>REMOVE BACKEND  3;
db03 [(none)]>ADD SLAVE  10.0.1.63:3306;

用户管理

主库添加跟后台添加

db01 [(none)]>grant all on *.* to oldguo@'10.0.0.%' identified by '123';  
db03 [(none)]>SELECT * FROM pwds;
db03 [(none)]>add pwd oldguo:123;

持久化配置文件

db03 [(none)]>save config;

转载规则

《11-mysql-主从复制高级进阶》由小明采用知识共享署名 4.0 国际许可协议进行许可。

12分布式架构-Mycat

1-分布式架构-Mycat 基础环境准备 1.1 环境准备：两台虚拟机 db01 db02每台创建四个mysql实例：3307 3308 3309 3310 1-搭建开始1.2 删除历史环境： pkill mysqld rm

2020-05-20 mysql

leetcode mysql

10-主从复制（Replication）

10主从复制（Replication）1. 介绍两台或以上数据库实例，通过二进制日志，实现数据的“同步”关系。2-主从复制前提（搭建过程）大家提到的： # 时间同步 # 至少2台以上实例,要有不同角色换分，server_id # 主库开b

2020-05-16 mysql

leetcode mysql

1-延时从库

1-介绍

2-配置

3- 监控方法

方法一： 有没有延时

方法二：主库：

从库：

4-导致延时的主要原因

（2） DUMP线程串行工作。

（3）怎么判断是主库导致的延时？

从库方面

SQL 线程： 串行回放。

的从库并发配置方法。开了GTID的前提 前面gutid 后面逻辑时钟

已经执行的主库日质量(relay-log.info): 判断回放有没有延时

5-延时从库的应用-故障模拟

1-配置方法：

2-恢复思路

3-故障模拟及恢复

4-恢复过程：

2-截取日志：

3-从库恢复

2-过滤复制

1-配置方法

2-方法一：

3-方法二：

3-半同步复制

4-GTID复制

1-搭建GTID：

1-清理环境

2-生成配置文件

3-初始化数据(三个节点都做)

4-启动数据库

5-构建主从：

6-从库开启主从

5- MHA高可用技术

数据损坏的类型

2. 高可用解决方案选型依据： 全年无故障率

1-manager 组件

2-node 组件

3-MHA基础架构规划和实施

1-规划:

2.配置关键程序软连接（所有节点）

3- 配置各节点互信（密钥对）

4-安装软件

所有节点安装Node软件依赖包

在db01主库中创建mha需要的用户

Manager软件安装（db03）

Manager配置文件准备(db03)

状态检查（db03）

5-开启MHA-manager

4-MHA工作原理

1-MHA的设计原理

2-选主判断：

3-数据补偿 ：

5-应用透明vip功能

5.1 vip 故障转移脚本

5.2 修改Manager 配置文件

5.3-主库上，手工生成第一个vip地址

6.故障提醒功能

6.1 准备脚本

6.2 修改配置文件

6.3 重启MHA(db03)

6.4检测状态：

6-日志补偿的冗余方案–binlog_server

6.1创建必要目录(db03)

6.2-配置文件设置

6.3 重启MHA

6.4测试MHA Failover的功能

7. MHA高可用，故障模拟及恢复演练

1. 排查进程状态

2. 检查配置文件中节点

3. 看日志

4. 修复故障库

5. 修复主从（主从是好的，可略过）

6. 将配置文件修复（配置文件节点信息还在，可忽略）

7. 检查ssh互信和repl的主从关系

8. 修复binlogserver（注意拉去当前主库）

9.检查主节点vip的状态

10. 启动MHA

11.快速恢复

方法一：有没有延时

SQL 线程：串行回放。

的从库并发配置方法。开了GTID的前提前面gutid 后面逻辑时钟

2. 高可用解决方案选型依据：全年无故障率

3-数据补偿：