DBA-70-day12

5. 主从复制延时

5.1 什么是延时？

主库做的事，从库好久才做。

5.2 如何监控？

5.2.1 传输过程监控

主库：

show master status ;

从库：

show slave status \G

例子：

[root@db01 ~]# mysql -S /tmp/mysql3307.sock -e "show master status;"

+------------------+----------+--------------+------------------+-------------------+

+------------------+----------+--------------+------------------+-------------------+

| mysql-bin.000001 | 154 | | | |

+------------------+----------+--------------+------------------+-------------------+

[root@db01 ~]# mysql -S /tmp/mysql3308.sock -e "show slave status\G"|grep "Read_Master_Log_Pos"

Read_Master_Log_Pos: 154

[root@db01 ~]#

1000以上告警，10000以上紧急

5.2.2 回放是否及时

[root@db01 ~]# mysql -S /tmp/mysql3307.sock -e "show master status;"

+------------------+----------+--------------+------------------+-------------------+

+------------------+----------+--------------+------------------+-------------------+

| mysql-bin.000001 | 154 | | | |

+------------------+----------+--------------+------------------+-------------------+

[root@db01 ~]# mysql -S /tmp/mysql3308.sock -e "show slave status\G"|grep " Exec_Master_Log_Pos"

Exec_Master_Log_Pos: 154

10000以上告警，100000以上紧急

5.3 主从延时的原因

5.3.1 外部因素

网络

主从配置（cpu\mem\io）

参数配置

等。

从库太多

5.3.2 主库方面

# dump线程是串行工作的模式。

5.6以前的版本，只能一个一个事务投递binlog。

5.6+版本以后，出现了group commit;

# binlog落地不及时。

采用ssd专门存储binlog

5.3.3 从库问题

# IO落地relaylog

一般建议采用SSD

# SQL线程

默认情况只有一个SQL线程，只能串行工作。

主库可以并发事务。

高并发场景下，会造成较高延时。

出现大事务的时候，都会造成较高延时。

解决方案：

1. 5.6版本，多SQL线程回放功能。但是只能根据不同库（database）进行回放。

2. 5.7+版本中，加入MTS机制。能够按照group commit 的逻辑时钟，进行并行回放。

# 人的问题

高并发场景下，会造成较高延时。

出现大事务的时候，都会造成较高延时。

锁问题严重。

==============================

第九章主从复制（Source-Replica）-下-高级进阶

1. 延时从库

1.1介绍

是我们认为配置的一种特殊从库.人为配置从库和主库延时N小时.

1.2 为什么要有延时从

什么是数据库损坏？

物理损坏

主从复制非常擅长解决物理损坏.

逻辑损坏

普通主从复制没办法解决逻辑损坏

1.3 配置延时从库

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.4 延时从库应用 *****

1.4.1 故障恢复思路

1主1从,从库延时5分钟,主库误删除1个库

1. 5分钟之内侦测到误删除操作

2. 停从库SQL线程

3. 截取relaylog

起点 :停止SQL线程时,relay最后应用位置

Relay_Log_File: db01-relay-bin.000002

Relay_Log_Pos: 320

终点:误删除之前的position(GTID)

4. 恢复截取的日志到从库

5. 从库身份解除,替代主库工作

1.4.2 故障模拟及恢复

1.主库数据操作

create database relay charset utf8;

use relay

create table t1 (id int);

insert into t1 values(1);

drop database relay;

2. 停止从库SQL线程

stop slave sql_thread;

3. 找relaylog的截取起点和终点

起点:

Relay_Log_File: db01-relay-bin.000002

Relay_Log_Pos: 485

终点:

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

| db01-relay-bin.000002 | 1145 | Query | 7 | 1074 | drop database relay

mysqlbinlog --start-position=485 --stop-position=1145 /data/3308/data/db01-relay-bin.000002>/tmp/relay.sql

从库恢复relaylog

source /tmp/relay.sql

5.从库身份解除

db01 [relay]>stop slave;

db01 [relay]>reset slave all

2. 半同步 ***

解决主从数据一致性问题。

2.1 半同步复制工作原理的变化

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达到了我们预设值的超时时间,半同步复制会切换为原始的异步复制.

2.2 配置半同步复制

加载插件

主:

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';

3 . 过滤复制

3.1 说明

主库：

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:

Replicate_Do_DB:

Replicate_Ignore_DB:

3.2 实现过程

[root@db01 ~]# vim /data/3308/my.cnf

replicate_do_db=ppt

replicate_do_db=word

[root@db01 ~]# systemctl restart mysqld3308

主库：

Master [(none)]>create database word;

Query OK, 1 row affected (0.00 sec)

Master [(none)]>create database ppt;

Query OK, 1 row affected (0.00 sec)

Master [(none)]>create database excel;

Query OK, 1 row affected (0.01 sec)

或者使用以下方法：

mysql> help CHANGE REPLICATION FILTER

4. GTID复制

4.1 GTID引入

4.2 GTID介绍

GTID(Global Transaction ID)是对于一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。

它的官方定义如下：

GTID =server_uuid : transaction_id

7E11FA47-31CA-19E1-9E56-C43AA21293967:29

什么是sever_uuid，和Server-id 区别？

核心特性: 全局唯一,具备幂等性

4.3 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更新是否记入日志

4.4 GTID复制配置过程：

4.4.1 清理环境

pkill mysqld

\rm -rf /data/3306/data/*

\rm -rf /data/binlog/*

\mv /etc/my.cnf /tmp

mkdir -p /data/3306/data /data/binlog/

chown -R mysql.mysql /data/*

4.4.2 准备配置文件

主库db01：

cat > /etc/my.cnf <<EOF

[mysqld]

basedir=/data/app/mysql/

datadir=/data/3306/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)：

cat > /etc/my.cnf <<EOF

[mysqld]

basedir=/data/app/mysql

datadir=/data/3306/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)：

cat > /etc/my.cnf <<EOF

[mysqld]

basedir=/data/app/mysql

datadir=/data/3306/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

4.4.3 初始化数据

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

4.4.4 启动数据库

/etc/init.d/mysqld start

4.4.5 构建主从：

master:51

slave:52,53

51:

mysql -e "grant replication slave on *.* to repl@'10.0.0.%' identified by '123';"

52\53:

change master to

master_host='10.0.0.51',

master_user='repl',

master_password='123' ,

MASTER_AUTO_POSITION=1;

start slave;

5. 主从复制架构演变

5.1 原生态复制结构演变

1主1从、1主N从

多级主从

5.2 扩展架构

读写分离

高可用

分布式架构

=================================

第十章 MySQL高可用及读写分离技术

0. MHA高可用架构介绍及搭建过程

0.1 规划:

主库:

51 node

从库:

52 node

53 node manager

0.2 准备环境

略。1主2从GTID

0.3 配置关键程序软连接

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

ln -s /data/app/mysql/bin/mysql /usr/bin/mysql

0.4 配置各节点互信(各节点之间无密码SSH)

# 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

0.5 安装软件

0.5.1 下载mha软件

mha官网：https://code.google.com/archive/p/mysql-master-ha/

github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

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

yum install perl-DBD-MySQL -y

rpm -ivh mha4mysql-node*.rpm

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

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

0.5.4 Manager软件安装（db03）

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

rpm -ivh mha4mysql-manager*.rpm

0.6 配置文件准备(db03)

0.6.1 创建配置文件目录

mkdir -p /etc/mha

0.6.2 创建日志目录

mkdir -p /var/log/mha/app1

0.6.3 编辑mha配置文件

vim /etc/mha/app1.cnf

[server default]

manager_log=/var/log/mha/app1/manager

manager_workdir=/var/log/mha/app1

master_binlog_dir=/data/binlog/

user=mha

password=mha

ping_interval=2

repl_password=123

repl_user=repl

ssh_user=root

[server1]

hostname=10.0.0.51

port=3306

[server2]

hostname=10.0.0.52

port=3306

[server3]

hostname=10.0.0.53

port=3306

0.7 状态检查

### 互信检查

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

### 主从状态检查

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

0.8 开启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 &

0.9 查看MHA状态

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

1. 什么是高可用?

企业高可用标准：全年无故障时间

无故障时间故障时间

99.9% 0.1% = 525.6 min KA+双主：人为干预

99.99% 0.01% = 52.56 min MHA ：半自动化

99.999% 0.001% = 5.256 min PXC 、 MGR 、MGC

99.9999% 0.0001% = 0.5256 min 自动化、云化、平台化

2. MHA的软件结构

一堆perl写的脚本。

2.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.2 node 组件

save_binary_logs 保存和复制master的二进制日志

apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的

purge_relay_logs 清除中继日志（不会阻塞SQL线程）

3. 站在产品经理角度，评估高可用软件设计

3.1 监控

3.2 选主

3.3 数据补偿

3.4 故障转移

3.5 应用透明

3.6 自动提醒

3.7 自愈

4. MHA FailOver 原理

4.1 监控：

通过 masterha_master_monitor ，每隔ping_interval秒探测一次Master 心跳。

监测不到心跳，一共给4次机会。

4.2 选主

4.2.1 日志量（latest slave）

各个从库的日志量。

无GTID：

[root@db02 ~]# mysql -e "show slave status\G" |grep "Master_Log"

Master_Log_File: mysql-bin.000003

Read_Master_Log_Pos: 194

有GTID：

[root@db02 ~]# mysql -e "show slave status\G" |grep "Executed_Gtid_Set"

Executed_Gtid_Set: 1c35b73a-7321-11ea-8974-000c29248f69:1-6

4.2.2 候选主 candidate master

candidate_master=1 强制某个节点为备选主。如果日志量超过100M差异，放弃掉他。

check_repl_delay=0 不检查日志量的差异。

4.2.3 如果没有权重，从库日志量一样

根据配置文件的先后顺序选择新主。

4.2.4 默认

从库日志量和主库延时100M以上。

4.3 日志补偿

4.3.1 if 主库ssh 能连接

各个从节点，通过save_binary_logs 立即保存缺失部分的binlog到/var/tmp/xxxxx

怎么判断缺失日志？

有GTID？

[root@db01 ~]# mysql -e "show master status;"

[root@db02 ~]# mysql -e "show slave status\G" |grep "Retrieved_Gtid_Set"

4.3.2 eles 主库 ssh 不能连接

从节点调用apply_diff_relay_logs，计算两个从节点的relay-log日志差异。

4.4 故障转移

1. 取消所有节点的从库状态

2. 构建新的主从关系

4.5 自动将故障节点，从配置文件剔除

--remove_dead_master_conf

4.6 自杀

manager自动退出。

4.7 应用透明: vip

4.8 数据补偿补充方案：binlog_server

4.9 切换提醒：send_report

5. 模拟故障并恢复

5.0 工作状态查看

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

app1 (pid:17501) is running(0:PING_OK), master:10.0.0.51

5.1 宕主库测试

[root@db01 ~]# /etc/init.d/mysqld stop

Shutting down MySQL............ SUCCESS!

[root@db01 ~]#

5.2 看日志

[root@db03 app1]# vim /var/log/mha/app1/manager

5.3 恢复

5.3.1 修复故障节点

[root@db01 ~]# /etc/init.d/mysqld start

Starting MySQL.. SUCCESS!

如果生产怎么办？

按实际情况。

5.3.2 恢复主从

change master to

master_host='10.0.0.52',

master_user='repl',

master_password='123' ,

MASTER_AUTO_POSITION=1;

start slave;

5.3.3 修复配置文件

方法一：

vim /etc/mha/app1.cnf

[server1]

hostname=10.0.0.51

port=3306

方法二：

masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --hostname=10.0.0.51 --block=server10 --params="port=3306"

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

5.3.4 预检测脚本

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

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

5.3.5 启动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 ~]# masterha_check_status --conf=/etc/mha/app1.cnf

app1 (pid:24316) is running(0:PING_OK), master:10.0.0.52

[root@db03 ~]#

6. 应用透明---VIP

vip : 10.0.0.55/24

6.1 vip 故障转移脚本

上传mha_script.tar文件到/usr/local/bin 解压

6.2 修改权限

[root@db03 bin]# chmod +x /usr/local/bin/*

6.3 修改内容

[root@db03 bin]# cp master_ip_failover master_ip_failover.bak

my $vip = '10.0.0.55/24';

my $key = '1';

my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";

my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

my $ssh_Bcast_arp= "/sbin/arping -I eth0 -c 3 -A 10.0.0.55";

6.4 修改Manager 配置文件

vim /etc/mha/app1.cnf

master_ip_failover_script=/usr/local/bin/master_ip_failover

6.5 重启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.6 手工在主库添加VIP

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

7. 故障提醒功能

7.1 准备脚本

[root@db03 bin]# cp send_report send_report.bak1

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'];

7.2 修改配置文件

vim /etc/mha/app1.cnf

# 添加一行：

report_script=/usr/local/bin/send_report

7.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 &

7.4 模拟主库宕机

7.4.1 确认主库

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

app1 (pid:27096) is running(0:PING_OK), master:10.0.0.52

7.4.2 宕主库

[root@db02 ~]# /etc/init.d/mysqld stop

Shutting down MySQL............ SUCCESS!

7.4.3 观察 vip 漂移

7.4.4 观察邮件

7.5 修复MHA 架构1主2从

略

8. 日志补偿的冗余方案--binlog_server

8.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"

Master_Log_File: mysql-bin.000008

Read_Master_Log_Pos: 194

Relay_Master_Log_File: mysql-bin.000008

Exec_Master_Log_Pos: 194

[root@db03 ~]#

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

注意：

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

8.2 配置文件设置

vim /etc/mha/app1.cnf

[binlog1]

no_master=1

hostname=10.0.0.53

master_binlog_dir=/data/binlog_server/

8.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 &

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

9.1 只切换角色

masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.0.52 --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

1. 此种方法切换，要注意将原主库，FTWRL，否则会造成主从不一致。

2. 手工切换vip

3. 重新拉去新主库的binlog

9.2 master_ip_online_change_script功能实现

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

9.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";

9.2.2 修改MHA配置文件

vim /etc/mha/app1.cnf

master_ip_online_change_script=/usr/local/bin/master_ip_online_change

9.2.3 停 MHA

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

9.2.4 检查repl

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

9.2.4 在线切换

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

9.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.000005

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.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000009 &

[1] 28534

9.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

MHA 高可用环境搭建

6.1 规划:

主库: 51 node

从库:

52 node

53 node manager

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

6.3 配置关键程序软连接

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

ln -s /data/app/mysql/bin/mysql /usr/bin/mysql

6.4 配置各节点互信(各节点之间无密码SSH)

# 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

6.5 安装软件

6.5.1 下载mha软件

mha官网：https://code.google.com/archive/p/mysql-master-ha/

github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

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

yum install perl-DBD-MySQL -y

rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

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

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

6.5.4 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

6.6 配置文件准备(db03)

6.6.1 创建配置文件目录

mkdir -p /etc/mha

6.6.2 创建日志目录

mkdir -p /var/log/mha/app1

6.6.3 编辑mha配置文件

vim /etc/mha/app1.cnf

[server default]

manager_log=/var/log/mha/app1/manager

manager_workdir=/var/log/mha/app1

master_binlog_dir=/data/3306/binlog

user=mha

password=mha

ping_interval=2

repl_password=123

repl_user=repl

ssh_user=root

[server1]

hostname=10.0.0.51

port=3306

[server2]

hostname=10.0.0.52

port=3306

[server3]

hostname=10.0.0.53

port=3306

6.7 状态检查

### 互信检查

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

### 主从状态检查

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

6.8 开启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 &

6.9 查看MHA状态

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

DBA-70-day12

5. 主从复制延时

5.1 什么是延时？

5.2 如何监控？

5.3 主从延时的原因

第九章 主从复制（Source-Replica）-下-高级进阶

1. 延时从库

1.1介绍

1.2 为什么要有延时从

1.3 配置延时从库

1.4 延时从库应用 *****

2. 半同步 ***

2.1 半同步复制工作原理的变化

2.2 配置半同步复制

3 . 过滤复制

3.1 说明

3.2 实现过程

4. GTID复制

4.1 GTID引入

4.2 GTID介绍

4.3 GTID核心参数

重要参数：

4.4 GTID复制配置过程：

5. 主从复制架构演变

5.1 原生态复制结构演变

5.2 扩展架构

第十章 MySQL高可用及读写分离技术

0. MHA高可用架构介绍及搭建过程

0.1 规划:

0.2 准备环境

0.3 配置关键程序软连接

0.4 配置各节点互信(各节点之间无密码SSH)

0.5 安装软件

0.6 配置文件准备(db03)

0.7 状态检查

0.8 开启MHA(db03)：

0.9 查看MHA状态

1. 什么是高可用?

2. MHA的软件结构

2.1 manager 组件

2.2 node 组件

3. 站在产品经理角度，评估高可用软件设计

3.1 监控

3.2 选主

3.3 数据补偿

3.4 故障转移

3.5 应用透明

3.6 自动提醒

3.7 自愈

4. MHA FailOver 原理

4.1 监控 ：

4.2 选主

4.3 日志补偿

4.4 故障转移

4.5 自动将故障节点，从配置文件剔除

4.6 自杀

4.7 应用透明: vip

4.8 数据补偿补充方案：binlog_server

4.9 切换提醒：send_report

5. 模拟故障并恢复

5.0 工作状态查看

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

5.1 宕主库测试

5.2 看日志

5.3 恢复

6. 应用透明---VIP

6.1 vip 故障转移脚本

6.2 修改权限

6.3 修改内容

6.4 修改Manager 配置文件

6.5 重启MHA

6.6 手工在主库添加VIP

7. 故障提醒功能

7.1 准备脚本

7.2 修改配置文件

7.3 重启MHA

7.4 模拟主库宕机

7.5 修复MHA 架构1主2从

8. 日志补偿的冗余方案--binlog_server

8.1 创建必要目录(db03)

第九章主从复制（Source-Replica）-下-高级进阶

4.1 监控：