SRE实战之运筹帷幄

MySQL 高可用架构之 MHA (Centos 7.5 MySQL 5.7.18 MHA 0.58)

Mon, 20 Apr 2020 20:24:39 +0800

简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。

在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：

MHA Manager（管理节点）
MHA Node（数据节点）

MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。

MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。

整个故障转移过程对应用程序完全透明。

可以将MHA工作原理总结为如下

从宕机崩溃的master保存二进制日志事件（binlog events）
识别含有最新更新的slave
应用差异的中继日志（relay log）到其他的slave；
应用从master保存的二进制日志事件（binlog events）；
提升一个slave为新的master；
使其他的slave连接新的master进行复制；

Manager工具包

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

Node工具包

这些工具通常由MHA Manager的脚本触发，无需人为操作

组件名称	组件说明
save_binary_logs	保存和复制master的二进制日志
apply_diff_relay_logs	识别差异的中继日志事件并将其差异的事件应用于其他的slave
filter_mysqlbinlog	去除不必要的ROLLBACK事件（MHA已不再使用这个工具）
purge_relay_logs	清除中继日志（不会阻塞SQL线程）

注意：

为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制。关于半同步复制原理各位自己进行查阅。（不是必须）

环境准备

操作系统	内核版本	主机名	MySQL 版本	ip地址	角色
centos 7.5	5.1.3-1.el7	manager.mha	MySQL 5.7.18	10.0.20.200	Manager
centos 7.5	5.1.3-1.el7	node01.mha	MySQL 5.7.18	10.0.20.201	node01 mysql-master
centos 7.5	5.1.3-1.el7	node02.mha	MySQL 5.7.18	10.0.20.202	node02 mysql-slave
centos 7.5	5.1.3-1.el7	node03.mha	MySQL 5.7.18	10.0.20.203	node03 mysql-slave
centos 7.5	5.1.3-1.el7	node04.mha	MySQL 5.7.18	10.0.20.204	node04 mysql-slave

MHA Manager 版本	GitHub下载地址	百度网盘下载地址
v0.58	GitHub下载地址	百度网盘地址提取码：lzb0

MHA Node 版本	GitHub下载地址	百度网盘下载地址
v0.58	GitHub下载地址	百度网盘地址提取码：4e6h

秘钥互信

配置所有机器相互之间root用户秘钥互信

在所有机器上执行:

生成密钥对

ssh-keygen -t dsa -f ~/.ssh/id_rsa -P ""

推送公钥

ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.20.200
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.20.201
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.20.202
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.20.203
ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.20.204

此时所有的机器之间以完成互信，无需密码等即可ssh登陆

安装基础依赖包

在所有机器上执行:

yum install -y perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

安装MHA组件

安装 MHA Node组件

在所有节点上执行

[root@node01 ~]# cd /opt/soft
[root@node01 soft]# ll
total 639152
-rw-r--r-- 1 root root     56220 Jun 12 17:59 mha4mysql-node-0.58.tar.gz
-rw-r--r-- 1 root root 654430368 Jun 11 11:21 mysql-5.7.18-linux-glibc2.5-x86_64.tar.gz

解压安装

具体命令执行输出就不复制出来了

[root@node01 soft]# tar xf mha4mysql-node-0.58.tar.gz
[root@node01 soft]# cd mha4mysql-node-0.58
[root@node01 mha4mysql-node-0.58]# perl Makefile.PL
[root@node01 mha4mysql-node-0.58]# make && make install

Node安装完成后会得到四个工具

[root@node01 mha4mysql-node-0.58]# ll /usr/local/bin/
total 48
-r-xr-xr-x 1 root root 17639 Jun 13 15:00 apply_diff_relay_logs
-r-xr-xr-x 1 root root  4807 Jun 13 15:00 filter_mysqlbinlog
-r-xr-xr-x 1 root root  8337 Jun 13 15:00 purge_relay_logs
-r-xr-xr-x 1 root root  7525 Jun 13 15:00 save_binary_logs

安装 MHA Manager 组件

在 Manager 节点执行安装

不用在Node节点上安装

[root@manager soft]# tar xf mha4mysql-manager-0.58.tar.gz 
[root@manager soft]# cd mha4mysql-manager-0.58
[root@manager mha4mysql-manager-0.58]# ls
AUTHORS  bin  COPYING  debian  inc  lib  Makefile.PL  MANIFEST  META.yml  README  rpm  samples  t  tests
[root@manager mha4mysql-manager-0.58]# perl Makefile.PL
[root@manager mha4mysql-manager-0.58]# make && make install

查看 Manager 工具

[root@manager mha4mysql-manager-0.58]# ll /usr/local/bin/
total 88
-r-xr-xr-x 1 root root 17639 Jun 13 15:10 apply_diff_relay_logs
-r-xr-xr-x 1 root root  4807 Jun 13 15:10 filter_mysqlbinlog
-r-xr-xr-x 1 root root  1995 Jun 13 15:13 masterha_check_repl
-r-xr-xr-x 1 root root  1779 Jun 13 15:13 masterha_check_ssh
-r-xr-xr-x 1 root root  1865 Jun 13 15:13 masterha_check_status
-r-xr-xr-x 1 root root  3201 Jun 13 15:13 masterha_conf_host
-r-xr-xr-x 1 root root  2517 Jun 13 15:13 masterha_manager
-r-xr-xr-x 1 root root  2165 Jun 13 15:13 masterha_master_monitor
-r-xr-xr-x 1 root root  2373 Jun 13 15:13 masterha_master_switch
-r-xr-xr-x 1 root root  5172 Jun 13 15:13 masterha_secondary_check
-r-xr-xr-x 1 root root  1739 Jun 13 15:13 masterha_stop
-r-xr-xr-x 1 root root  8337 Jun 13 15:10 purge_relay_logs
-r-xr-xr-x 1 root root  7525 Jun 13 15:10 save_binary_logs

建立 MySQL 一主三从

本文章主要实现是MHA集群，MySQL集群直接贴命令和my.cnf配置

在四台 Node 节点上，实现，node01 为 master，剩下三个 node 为 slave 。

[root@node01 mysql-5.7]# rpm -qa |grep mariadb | xargs rpm -e --nodeps
[root@node01 soft]# useradd -s /sbin/nologin -M mysql
[root@node01 soft]# tar xf mysql-5.7.18-linux-glibc2.5-x86_64.tar.gz
[root@node01 soft]# mv mysql-5.7.18-linux-glibc2.5-x86_64 mysql-5.7
[root@node01 soft]# mv mysql-5.7 /usr/local/
[root@node01 soft]# ln -s /usr/local/mysql-5.7 /usr/local/mysql
[root@node01 soft]# cd /usr/local/mysql-5.7
[root@node01 mysql-5.7]# echo 'export PATH=$PATH:/usr/local/mysql-5.7/bin' >> /etc/profile
[root@node01 mysql-5.7]# source /etc/profile
[root@node01 mysql-5.7]# mysql -V
mysql  Ver 14.14 Distrib 5.7.18, for linux-glibc2.5 (x86_64) using  EditLine wrapper
[root@node01 mysql-5.7]# cp support-files/mysql.server /etc/init.d/mysqld
[root@node01 mysql-5.7]# sed -i 's@/etc/my.cnf@/usr/local/mysql-5.7/my.cnf@g' /etc/init.d/mysqld
[root@node01 mysql-5.7]# sed -i 's@/usr/local/mysql/data@/opt/mysql_data@g' /etc/init.d/mysqld
[root@node01 mysql-5.7]# chkconfig mysqld on
[root@node01 mysql-5.7]# mkdir /opt/mysql_data
[root@node01 mysql-5.7]# chown -R mysql.mysql /usr/local/mysql-5.7
[root@node01 mysql-5.7]# chown -R mysql.mysql /opt/mysql_data
[root@node01 mysql-5.7]#ln -s /usr/local/mysql/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
[root@node01 mysql-5.7]#ln -s /usr/local/mysql/bin/mysql /usr/local/bin/mysql

my.cnf 配置文件

注意需要把my.cnf 中的server-id的的值四台node不能重复，否则主从会建立失败。

[root@node04 mysql-5.7]# cat my.cnf 
[client]
socket = /tmp/mysql.sock
port=3306

[mysql]
default-character-set=utf8
socket = /tmp/mysql.sock

[mysqld]
socket = /tmp/mysql.sock
character-set-server=utf8
basedir=/usr/local/mysql-5.7
datadir=/opt/mysql_data
port=3306
pid-file=/opt/mysql_data/mysqld.pid

# 四台node不可重复
server-id=204

skip-name-resolve

default-storage-engine=INNODB
explicit_defaults_for_timestamp = true

gtid_mode = on	
enforce_gtid_consistency = 1
log_slave_updates = 1

plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 5000


relay-log = mysql-relay-bin
replicate-wild-ignore-table=mysql.%
replicate-wild-ignore-table=test.%
replicate-wild-ignore-table=information_schema.%

max_connections=2000
query_cache_size=0
table_open_cache=2000
tmp_table_size=246M
thread_cache_size=300
thread_stack = 192k
key_buffer_size=512M
read_buffer_size=4M
read_rnd_buffer_size=32M


innodb_data_home_dir = /opt/mysql_data
innodb_flush_log_at_trx_commit=0
innodb_log_buffer_size=16M

# 此选项修改为实际运行mysql机器内存的%60 - %80
innodb_buffer_pool_size=13G

innodb_log_file_size=128M
innodb_thread_concurrency=128
innodb_autoextend_increment=1000
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0

back_log = 80
flush_time = 0
join_buffer_size = 128M
max_allowed_packet = 1024M
max_connect_errors = 2000
open_files_limit = 4161
query_cache_type = 0
sort_buffer_size = 32M
table_definition_cache = 1400
binlog_row_event_max_size = 8K
sync_master_info = 10000
sync_relay_log = 10000
sync_relay_log_info = 10000
bulk_insert_buffer_size = 64M
interactive_timeout = 120
wait_timeout = 120
log-bin-trust-function-creators=1
sql_mode = NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES 

[mysqld_safe]
log-error = /opt/mysql_data/error.log
pid-file = /opt/mysql_data/mysqld.pid

初始化 MySQL

node01

[root@node01 mysql-5.7]# mysqld --initialize  --user=mysql --basedir=/usr/local/mysql-5.7 --datadir=/opt/mysql_data
2019-06-13T07:59:00.947482Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-06-13T07:59:01.056859Z 0 [Warning] InnoDB: New log files created, LSN=45790
2019-06-13T07:59:01.076218Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2019-06-13T07:59:01.129463Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 1ae29152-8db1-11e9-9d54-005056990727.
2019-06-13T07:59:01.129873Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2019-06-13T07:59:01.130247Z 1 [Note] A temporary password is generated for root@localhost: 1qGoEiI7ga#U

node02

[root@node02 mysql-5.7]# mysqld --initialize  --user=mysql --basedir=/usr/local/mysql-5.7 --datadir=/opt/mysql_data
2019-06-13T07:59:00.952176Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-06-13T07:59:01.092736Z 0 [Warning] InnoDB: New log files created, LSN=45790
2019-06-13T07:59:01.116696Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2019-06-13T07:59:01.171324Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 1ae8f47b-8db1-11e9-b8bb-0050569972c0.
2019-06-13T07:59:01.171711Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2019-06-13T07:59:01.172126Z 1 [Note] A temporary password is generated for root@localhost: qTwtKAOue7:o

node03

[root@node03 mysql-5.7]# mysqld --initialize  --user=mysql --basedir=/usr/local/mysql-5.7 --datadir=/opt/mysql_data
2019-06-13T07:59:00.949924Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-06-13T07:59:01.090890Z 0 [Warning] InnoDB: New log files created, LSN=45790
2019-06-13T07:59:01.116166Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2019-06-13T07:59:01.171335Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 1ae8f4ef-8db1-11e9-b6ae-0050569975f7.
2019-06-13T07:59:01.171753Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2019-06-13T07:59:01.172159Z 1 [Note] A temporary password is generated for root@localhost: XIu,h#*HQ5&M

node04

2019-06-13T07:59:00.955598Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2019-06-13T07:59:01.090420Z 0 [Warning] InnoDB: New log files created, LSN=45790
2019-06-13T07:59:01.113972Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2019-06-13T07:59:01.166754Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 1ae84210-8db1-11e9-b6fe-005056992c6b.
2019-06-13T07:59:01.167145Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2019-06-13T07:59:01.167537Z 1 [Note] A temporary password is generated for root@localhost: 26jvaV)XAy>G

执行完初始化操作后，最后会给予root的默认密码，使用此密码登陆后，要第一时间修改root密码，否则不允许操作数据库；

alter user 'root'@'localhost' identified by '123456';

启动MySQL 并简单配置

# /etc/init.d/mysqld start
Starting MySQL.Logging to '/opt/mysql_data/error.log'.
.. SUCCESS!

登陆MySQL 并修改密码

[root@node01 mysql-5.7]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.18

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> alter user user() identified by "123456";
Query OK, 0 rows affected (0.00 sec)

所有mysql增加主从用户

mysql> grant replication slave on *.* to 'repl'@'10.0.20.%' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> grant all on *.* to 'root'@'%' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

建立一主三从

node01 的MySQL执行

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

node02、node03、node04 都执行下列语句

change master to master_host='10.0.20.201',master_user='repl',master_password='123456',master_log_file='mysql-bin.000002',master_log_pos=463;

show slave status\G; #查看slave IO和slave sql是否都正常

特别说明

下面开始配置Manager机器，本人的所有机器，均做了bond网卡绑定，所有机器的网卡名都为bond0，大家根据自己的网卡名称自行修改，还有发送邮件的邮箱以及微信公众号的相关配置，均需要修改为自己的。

本次是用vip 是: 10.0.20.199

大家根据自己的情况，做出对应的修改。

MHA Manager 配置

下面配置，均在manager机器上操作。

# 创建MHA配置文件目录
mkdir /etc/mha
# 创建MHA脚本目录
mkdir /etc/mha/scripts
# 创建MHA日志目录
mkdir /var/log/mha/
# 创建日志目录
mkdir /var/log/mha/app1 -p
# 创建日志文件
touch /var/log/mha/app1/manager.log

MHA 配置文件

[root@manager mha]# cat /etc/masterha_default.cnf 

[server default]
user=root
password=SIjiayong.123

repl_user=repl
repl_password=SIjiayong.123

ssh_user=root

ping_interval=1
master_binlog_dir=/opt/mysql_data

manager_workdir=/var/log/mha/app1.log
manager_log=/var/log/mha/manager.log
master_ip_failover_script="/etc/mha/scripts/master_ip_failover"
master_ip_online_change_script="/etc/mha/scripts/master_ip_online_change"
report_script="/etc/mha/scripts/send_report"
remote_workdir=/tmp
secondary_check_script= /usr/local/bin/masterha_secondary_check -s 10.0.20.201 -s 10.0.20.202 -s 10.0.20.203 -s 10.0.20.204
shutdown_script=""

[root@manager ~]# cat /etc/mha/app1.cnf 
[server1]
hostname=10.0.20.201
port=3306

[server2]
hostname=10.0.20.202
port=3306
candidate_master=1
check_repl_delay=0

[server3]
hostname=10.0.20.203
port=3306

[server4]
hostname=10.0.20.204
port=3306

配置文件说明

MHA主要配置文件说明

manager_workdir=/var/log/masterha/app1.log：设置manager的工作目录
manager_log=/var/log/masterha/app1/manager.log：设置manager的日志文件
master_binlog_dir=/data/mysql：设置master 保存binlog的位置，以便MHA可以找到master的日志
master_ip_failover_script= /usr/local/bin/master_ip_failover：设置自动failover时候的切换脚本
master_ip_online_change_script= /usr/local/bin/master_ip_online_change：设置手动切换时候的切换脚本
user=root：设置监控mysql的用户
password=dayi123：设置监控mysql的用户，需要授权能够在manager节点远程登录
ping_interval=1：设置监控主库，发送ping包的时间间隔，默认是3秒，尝试三次没有回应的时候自动进行railover
remote_workdir=/tmp：设置远端mysql在发生切换时binlog的保存位置
repl_user=repl ：设置mysql中用于复制的用户密码
repl_password=replication：设置mysql中用于复制的用户
report_script=/usr/local/send_report：设置发生切换后发送的报警的脚本
shutdown_script=""：设置故障发生后关闭故障主机脚本（该脚本的主要作用是关闭主机放在发生脑裂,这里没有使用）
ssh_user=root //设置ssh的登录用户名
candidate_master=1：在节点下设置，设置当前节点为候选的master
slave check_repl_delay=0 :在节点配置下设置，默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master；这个选项对于对于设置了candidate_master=1的主机非常有用

脚本配置

自动 VIP 管理配置

#为了防止脑裂发生,推荐生产环境采用脚本的方式来管理虚拟 ip,而不是使用 keepalived来完成

vim /etc/mha/scripts/master_ip_failover

#!/usr/bin/env perl

use strict;
use warnings FATAL => 'all';

use Getopt::Long;

my (
    $command,          $ssh_user,        $orig_master_host, $orig_master_ip,
    $orig_master_port, $new_master_host, $new_master_ip,    $new_master_port
);

my $vip = '10.0.20.199/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig bond0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig bond0:$key down";

GetOptions(
    'command=s'          => \$command,
    'ssh_user=s'         => \$ssh_user,
    'orig_master_host=s' => \$orig_master_host,
    'orig_master_ip=s'   => \$orig_master_ip,
    'orig_master_port=i' => \$orig_master_port,
    'new_master_host=s'  => \$new_master_host,
    'new_master_ip=s'    => \$new_master_ip,
    'new_master_port=i'  => \$new_master_port,
);

exit &main();

sub main {

    print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";

    if ( $command eq "stop" || $command eq "stopssh" ) {

        my $exit_code = 1;
        eval {
            print "Disabling the VIP on old master: $orig_master_host \n";
            &stop_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn "Got Error: $@\n";
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "start" ) {

        my $exit_code = 10;
        eval {
            print "Enabling the VIP - $vip on the new master - $new_master_host \n";
            &start_vip();
            $exit_code = 0;
        };
        if ($@) {
            warn $@;
            exit $exit_code;
        }
        exit $exit_code;
    }
    elsif ( $command eq "status" ) {
        print "Checking the Status of the script.. OK \n";
        exit 0;
    }
    else {
        &usage();
        exit 1;
    }
}

sub start_vip() {
    `ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
sub stop_vip() {
     return 0  unless  ($ssh_user);
    `ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

sub usage {
    print
    "Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

配置邮件和微信报警脚本

# 安装发送邮件的工具
yum install mailx -y

mail邮件发送程序，需要先配置好发送这信息

vim /etc/mail.rc

set from=*****@163.com
set smtp=smtp.163.com
set smtp-auth-user=*****
#拿163邮箱来说这个不是密码，而是授权码
set smtp-auth-password=*****
set smtp-auth=login

这是具体的邮件和微信发送脚本

vim /etc/mha/scripts/send_report

#!/bin/bash
source /root/.bash_profile
# 解析变量
orig_master_host=`echo "$1" | awk -F = '{print $2}'`
new_master_host=`echo "$2" | awk -F = '{print $2}'`
new_slave_hosts=`echo "$3" | awk -F = '{print $2}'`
subject=`echo "$4" | awk -F = '{print $2}'`
body=`echo "$5" | awk -F = '{print $2}'`
#定义收件人地址
email="***@***.com"

# 下面这俩个需要微信公众号中自行获取
CropID='******************'
Secret='***************************************'

GURL="https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CropID&corpsecret=$Secret"
Gtoken=$(/usr/bin/curl -s -G $GURL | awk -F\" '{print $10}')

PURL="https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=$Gtoken"

function body() {
        #企业号中的应用id
        local int AppID=1000002
        #部门成员id，
        local UserID=$1
        #部门id，定义了范围，组内成员都可接收到消息
        local PartyID='2|3'
        #过滤出zabbix传递的第三个参数
        local Msg=$(echo "$@" | cut -d" " -f3-)
        printf '{\n'
        printf '\t"touser": "'"$UserID"\"",\n"
        printf '\t"toparty": "'"$PartyID"\"",\n"
        printf '\t"msgtype": "text",\n'
        printf '\t"agentid": "'" $AppID "\"",\n"
        printf '\t"text": {\n'
        printf '\t\t"content": "'"$Msg"\""\n"
        printf '\t},\n'
        printf '\t"safe":"0"\n'
        printf '}\n'
}






tac /var/log/mha/app1/manager.log | sed -n 2p | grep 'successfully' > /dev/null
if [ $? -eq 0 ]
	then
	messages=`echo -e "MHA $subject 主从切换成功\n master:$orig_master_host --> $new_master_host \n $body \n 当前从库:$new_slave_hosts"` 
	echo "$messages" | mail -s "Mysql 实例宕掉，MHA $subject 切换成功" $email >>/tmp/mailx.log 2>&1 
        /usr/bin/curl --data-ascii "$(body 1 1 ${messages})" ${PURL}
	else
	messages=`echo -e "MHA $subject 主从切换失败\n master:$orig_master_host --> $new_master_host \n $body" `
	echo "$messages" | mail -s ""Mysql 实例宕掉，MHA $subject 切换失败"" $email >>/tmp/mailx.log 2>&1  
        /usr/bin/curl --data-ascii "$(body 1 1 ${messages})" ${PURL}
fi

手动 VIP 管理配置脚本

vim /etc/mha/scripts/master_ip_online_change

#!/bin/bash
source /root/.bash_profile

vip=`echo '10.0.20.199/24'`  #设置VIP
key=`echo '1'`

command=`echo "$1" | awk -F = '{print $2}'`
orig_master_host=`echo "$2" | awk -F = '{print $2}'`
new_master_host=`echo "$7" | awk -F = '{print $2}'`
orig_master_ssh_user=`echo "${12}" | awk -F = '{print $2}'`
new_master_ssh_user=`echo "${13}" | awk -F = '{print $2}'`

#要求服务的网卡识别名一样
stop_vip=`echo "ssh root@$orig_master_host /usr/sbin/ifconfig bond0:$key down"`
start_vip=`echo "ssh root@$new_master_host /usr/sbin/ifconfig bond0:$key $vip"`

if [ $command = 'stop' ]
  then
    echo -e "\n\n\n****************************\n"
    echo -e "Disabled thi VIP - $vip on old master: $orig_master_host \n"
    $stop_vip
    if [ $? -eq 0 ]
      then
	echo "Disabled the VIP successfully"
      else
	echo "Disabled the VIP failed"
    fi
    echo -e "***************************\n\n\n"
  fi

if [ $command = 'start' -o $command = 'status' ]
  then
    echo -e "\n\n\n*************************\n"
    echo -e "Enabling the VIP - $vip on new master: $new_master_host \n"
    $start_vip
    if [ $? -eq 0 ]
      then
	echo "Enabled the VIP successfully"
      else
	echo "Enabled the VIP failed"
    fi
    echo -e "***************************\n\n\n"
fi

赋权

最后给刚刚配置的三个脚本增加执行权限

chmod +x /etc/mha/scripts/master_ip_failover 
chmod +x /etc/mha/scripts/master_ip_online_change 
chmod +x /etc/mha/scripts/send_report

验证 MHA 相关操作

验证 ssh 信任登录是否成功

通过 masterha_check_ssh 命令验证

[root@manager scripts]# masterha_check_ssh --conf=/etc/mha/app1.cnf
# 最后出现以下提示，则表示通过
Thu Jun 13 17:19:34 2019 - [info] All SSH connection tests passed successfully.

验证 mysql 主从复制是否成功

通过 masterha_check_repl 命令验证

[root@manager mha]# masterha_check_repl --conf=/etc/masterha_default.cnf
# 最后出现以下提示，则表示通过
MySQL Replication Health is OK.

启动 MHA

手动第一次添加vip

本次在node01 上操作

先在node01 的 MySQL master上绑定vip，只需要在master绑定这一次，以后会自动切换

[root@node01 mysql-5.7]# /usr/sbin/ifconfig bond0:1 10.0.20.199/24
[root@node01 mysql-5.7]# ip a | grep 20
    inet 10.0.20.201/24 brd 10.0.20.255 scope global bond0
    inet 10.0.20.199/24 brd 10.0.20.255 scope global secondary bond0:1

启动

这一步在manager上操作

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 &

检查 MHA 状态

[root@manager mha]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4745) is running(0:PING_OK), master:10.0.20.201

MHA 的日志保存在/var/log/masterha/app1/manager.log 下

[root@manager mha]# tailf /var/log/mha/manager.log
#如果最后一行是如下，表明启动成功
Thu Jun 13 17:31:41 2019 - [info] Starting ping health check on 10.0.20.201(10.0.20.201:3306)..
Thu Jun 13 17:31:41 2019 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..

关闭

若已处于监控状态，需要停掉它

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

模拟宕机测试

手动停止node01 的 MySQL master，然后查看其它节点情况。

[root@node01 ~]# /etc/init.d/mysqld  stop
Shutting down MySQL............ SUCCESS!
[root@node01 ~]# ip a | grep 20
    inet 10.0.20.201/24 brd 10.0.20.255 scope global bond0

在node02 上查看VIP

[root@node02 ~]# ip a | grep 20
    inet 10.0.20.202/24 brd 10.0.20.255 scope global bond0
    inet 10.0.20.199/24 brd 10.0.20.255 scope global secondary bond0:1

在node03 上查看主从同步状态和地址

[root@node03 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.202
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

在node04 上查看主从同步状态和地址

[root@node04 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.202
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

查看Manager日志

[root@manager mha]# tailf manager.log
Fri Jun 14 10:01:03 2019 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)
Fri Jun 14 10:01:03 2019 - [info] Executing SSH check script: exit 0
Fri Jun 14 10:01:03 2019 - [info] Executing secondary network check script: /usr/local/bin/masterha_secondary_check -s 10.0.20.201 -s 10.0.20.202 -s 10.0.20.203 -s 10.0.20.204  --user=root  --master_host=10.0.20.201  --master_ip=10.0.20.201  --master_port=3306 --master_user=root --master_password=123456 --ping_type=SELECT
Fri Jun 14 10:01:03 2019 - [info] HealthCheck: SSH to 10.0.20.201 is reachable.
Monitoring server 10.0.20.201 is reachable, Master is not reachable from 10.0.20.201. OK.
Monitoring server 10.0.20.202 is reachable, Master is not reachable from 10.0.20.202. OK.
Monitoring server 10.0.20.203 is reachable, Master is not reachable from 10.0.20.203. OK.
Fri Jun 14 10:01:04 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.0.20.201' (111))
Fri Jun 14 10:01:04 2019 - [warning] Connection failed 2 time(s)..
Monitoring server 10.0.20.204 is reachable, Master is not reachable from 10.0.20.204. OK.
Fri Jun 14 10:01:04 2019 - [info] Master is not reachable from all other monitoring servers. Failover should start.
Fri Jun 14 10:01:05 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.0.20.201' (111))
Fri Jun 14 10:01:05 2019 - [warning] Connection failed 3 time(s)..
Fri Jun 14 10:01:06 2019 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '10.0.20.201' (111))
Fri Jun 14 10:01:06 2019 - [warning] Connection failed 4 time(s)..
Fri Jun 14 10:01:06 2019 - [warning] Master is not reachable from health checker!
Fri Jun 14 10:01:06 2019 - [warning] Master 10.0.20.201(10.0.20.201:3306) is not reachable!
Fri Jun 14 10:01:06 2019 - [warning] SSH is reachable.
Fri Jun 14 10:01:06 2019 - [info] Connecting to a master server failed. Reading configuration file /etc/masterha_default.cnf and /etc/mha/app1.cnf again, and trying to connect to all servers to check server status..
Fri Jun 14 10:01:06 2019 - [info] Reading default configuration from /etc/masterha_default.cnf..
Fri Jun 14 10:01:06 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Jun 14 10:01:06 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Jun 14 10:01:07 2019 - [info] GTID failover mode = 1
Fri Jun 14 10:01:07 2019 - [info] Dead Servers:
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:07 2019 - [info] Alive Servers:
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.202(10.0.20.202:3306)
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.203(10.0.20.203:3306)
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.204(10.0.20.204:3306)
Fri Jun 14 10:01:07 2019 - [info] Alive Slaves:
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.202(10.0.20.202:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:07 2019 - [info]     GTID ON
Fri Jun 14 10:01:07 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:07 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.203(10.0.20.203:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:07 2019 - [info]     GTID ON
Fri Jun 14 10:01:07 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:07 2019 - [info]   10.0.20.204(10.0.20.204:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:07 2019 - [info]     GTID ON
Fri Jun 14 10:01:07 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:07 2019 - [info] Checking slave configurations..
Fri Jun 14 10:01:07 2019 - [info]  read_only=1 is not set on slave 10.0.20.202(10.0.20.202:3306).
Fri Jun 14 10:01:07 2019 - [info]  read_only=1 is not set on slave 10.0.20.203(10.0.20.203:3306).
Fri Jun 14 10:01:07 2019 - [info]  read_only=1 is not set on slave 10.0.20.204(10.0.20.204:3306).
Fri Jun 14 10:01:07 2019 - [info] Checking replication filtering settings..
Fri Jun 14 10:01:07 2019 - [info]  Replication filtering check ok.
Fri Jun 14 10:01:07 2019 - [info] Master is down!
Fri Jun 14 10:01:07 2019 - [info] Terminating monitoring script.
Fri Jun 14 10:01:07 2019 - [info] Got exit code 20 (Master dead).
Fri Jun 14 10:01:07 2019 - [info] MHA::MasterFailover version 0.58.
Fri Jun 14 10:01:07 2019 - [info] Starting master failover.
Fri Jun 14 10:01:07 2019 - [info] 
Fri Jun 14 10:01:07 2019 - [info] * Phase 1: Configuration Check Phase..
Fri Jun 14 10:01:07 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] GTID failover mode = 1
Fri Jun 14 10:01:08 2019 - [info] Dead Servers:
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info] Checking master reachability via MySQL(double check)...
Fri Jun 14 10:01:08 2019 - [info]  ok.
Fri Jun 14 10:01:08 2019 - [info] Alive Servers:
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.202(10.0.20.202:3306)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.203(10.0.20.203:3306)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.204(10.0.20.204:3306)
Fri Jun 14 10:01:08 2019 - [info] Alive Slaves:
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.202(10.0.20.202:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.203(10.0.20.203:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.204(10.0.20.204:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info] Starting GTID based failover.
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] ** Phase 1: Configuration Check Phase completed.
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 2: Dead Master Shutdown Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] Forcing shutdown so that applications never connect to the current master..
Fri Jun 14 10:01:08 2019 - [info] Executing master IP deactivation script:
Fri Jun 14 10:01:08 2019 - [info]   /etc/mha/scripts/master_ip_failover --orig_master_host=10.0.20.201 --orig_master_ip=10.0.20.201 --orig_master_port=3306 --command=stopssh --ssh_user=root  


IN SCRIPT TEST====/sbin/ifconfig bond0:1 down==/sbin/ifconfig bond0:1 10.0.20.199/24===

Disabling the VIP on old master: 10.0.20.201 
Fri Jun 14 10:01:08 2019 - [info]  done.
Fri Jun 14 10:01:08 2019 - [warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.
Fri Jun 14 10:01:08 2019 - [info] * Phase 2: Dead Master Shutdown Phase completed.
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 3: Master Recovery Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 3.1: Getting Latest Slaves Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] The latest binary log file/position on all slaves is mysql-bin.000004:194
Fri Jun 14 10:01:08 2019 - [info] Retrieved Gtid Set: 6211616e-8db3-11e9-be15-005056990727:3-5
Fri Jun 14 10:01:08 2019 - [info] Latest slaves (Slaves that received relay log files to the latest):
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.202(10.0.20.202:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.203(10.0.20.203:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.204(10.0.20.204:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info] The oldest binary log file/position on all slaves is mysql-bin.000004:194
Fri Jun 14 10:01:08 2019 - [info] Retrieved Gtid Set: 6211616e-8db3-11e9-be15-005056990727:3-5
Fri Jun 14 10:01:08 2019 - [info] Oldest slaves:
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.202(10.0.20.202:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.203(10.0.20.203:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.204(10.0.20.204:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 3.3: Determining New Master Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] Searching new master from slaves..
Fri Jun 14 10:01:08 2019 - [info]  Candidate masters from the configuration file:
Fri Jun 14 10:01:08 2019 - [info]   10.0.20.202(10.0.20.202:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 10:01:08 2019 - [info]     GTID ON
Fri Jun 14 10:01:08 2019 - [info]     Replicating from 10.0.20.201(10.0.20.201:3306)
Fri Jun 14 10:01:08 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 10:01:08 2019 - [info]  Non-candidate masters:
Fri Jun 14 10:01:08 2019 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
Fri Jun 14 10:01:08 2019 - [info] New master is 10.0.20.202(10.0.20.202:3306)
Fri Jun 14 10:01:08 2019 - [info] Starting master failover..
Fri Jun 14 10:01:08 2019 - [info] 
From:
10.0.20.201(10.0.20.201:3306) (current master)
 +--10.0.20.202(10.0.20.202:3306)
 +--10.0.20.203(10.0.20.203:3306)
 +--10.0.20.204(10.0.20.204:3306)

To:
10.0.20.202(10.0.20.202:3306) (new master)
 +--10.0.20.203(10.0.20.203:3306)
 +--10.0.20.204(10.0.20.204:3306)
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 3.3: New Master Recovery Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info]  Waiting all logs to be applied.. 
Fri Jun 14 10:01:08 2019 - [info]   done.
Fri Jun 14 10:01:08 2019 - [info] Getting new master's binlog name and position..
Fri Jun 14 10:01:08 2019 - [info]  mysql-bin.000002:194
Fri Jun 14 10:01:08 2019 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.20.202', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';
Fri Jun 14 10:01:08 2019 - [info] Master Recovery succeeded. File:Pos:Exec_Gtid_Set: mysql-bin.000002, 194, 6211616e-8db3-11e9-be15-005056990727:4-5
Fri Jun 14 10:01:08 2019 - [info] Executing master IP activate script:
Fri Jun 14 10:01:08 2019 - [info]   /etc/mha/scripts/master_ip_failover --command=start --ssh_user=root --orig_master_host=10.0.20.201 --orig_master_ip=10.0.20.201 --orig_master_port=3306 --new_master_host=10.0.20.202 --new_master_ip=10.0.20.202 --new_master_port=3306 --new_master_user='root'   --new_master_password=xxx
Unknown option: new_master_user
Unknown option: new_master_password


IN SCRIPT TEST====/sbin/ifconfig bond0:1 down==/sbin/ifconfig bond0:1 10.0.20.199/24===

Enabling the VIP - 10.0.20.199/24 on the new master - 10.0.20.202 
Fri Jun 14 10:01:08 2019 - [info]  OK.
Fri Jun 14 10:01:08 2019 - [info] ** Finished master recovery successfully.
Fri Jun 14 10:01:08 2019 - [info] * Phase 3: Master Recovery Phase completed.
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 4: Slaves Recovery Phase..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] * Phase 4.1: Starting Slaves in parallel..
Fri Jun 14 10:01:08 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info] -- Slave recovery on host 10.0.20.203(10.0.20.203:3306) started, pid: 2838. Check tmp log /var/log/mha/10.0.20.203_3306_20190614100107.log if it takes time..
Fri Jun 14 10:01:08 2019 - [info] -- Slave recovery on host 10.0.20.204(10.0.20.204:3306) started, pid: 2839. Check tmp log /var/log/mha/10.0.20.204_3306_20190614100107.log if it takes time..
Fri Jun 14 10:01:09 2019 - [info] 
Fri Jun 14 10:01:09 2019 - [info] Log messages from 10.0.20.204 ...
Fri Jun 14 10:01:09 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info]  Resetting slave 10.0.20.204(10.0.20.204:3306) and starting replication from the new master 10.0.20.202(10.0.20.202:3306)..
Fri Jun 14 10:01:08 2019 - [info]  Executed CHANGE MASTER.
Fri Jun 14 10:01:08 2019 - [info]  Slave started.
Fri Jun 14 10:01:08 2019 - [info]  gtid_wait(6211616e-8db3-11e9-be15-005056990727:4-5) completed on 10.0.20.204(10.0.20.204:3306). Executed 0 events.
Fri Jun 14 10:01:09 2019 - [info] End of log messages from 10.0.20.204.
Fri Jun 14 10:01:09 2019 - [info] -- Slave on host 10.0.20.204(10.0.20.204:3306) started.
Fri Jun 14 10:01:10 2019 - [info] 
Fri Jun 14 10:01:10 2019 - [info] Log messages from 10.0.20.203 ...
Fri Jun 14 10:01:10 2019 - [info] 
Fri Jun 14 10:01:08 2019 - [info]  Resetting slave 10.0.20.203(10.0.20.203:3306) and starting replication from the new master 10.0.20.202(10.0.20.202:3306)..
Fri Jun 14 10:01:08 2019 - [info]  Executed CHANGE MASTER.
Fri Jun 14 10:01:09 2019 - [info]  Slave started.
Fri Jun 14 10:01:09 2019 - [info]  gtid_wait(6211616e-8db3-11e9-be15-005056990727:4-5) completed on 10.0.20.203(10.0.20.203:3306). Executed 0 events.
Fri Jun 14 10:01:10 2019 - [info] End of log messages from 10.0.20.203.
Fri Jun 14 10:01:10 2019 - [info] -- Slave on host 10.0.20.203(10.0.20.203:3306) started.
Fri Jun 14 10:01:10 2019 - [info] All new slave servers recovered successfully.
Fri Jun 14 10:01:10 2019 - [info] 
Fri Jun 14 10:01:10 2019 - [info] * Phase 5: New master cleanup phase..
Fri Jun 14 10:01:10 2019 - [info] 
Fri Jun 14 10:01:10 2019 - [info] Resetting slave info on the new master..
Fri Jun 14 10:01:10 2019 - [info]  10.0.20.202: Resetting slave info succeeded.
Fri Jun 14 10:01:10 2019 - [info] Master failover to 10.0.20.202(10.0.20.202:3306) completed successfully.
Fri Jun 14 10:01:10 2019 - [info] Deleted server1 entry from /etc/mha/app1.cnf .
Fri Jun 14 10:01:10 2019 - [info] 

----- Failover Report -----

app1: MySQL Master failover 10.0.20.201(10.0.20.201:3306) to 10.0.20.202(10.0.20.202:3306) succeeded

Master 10.0.20.201(10.0.20.201:3306) is down!

Check MHA Manager logs at manager.mha:/var/log/mha/manager.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 10.0.20.201(10.0.20.201:3306)
Selected 10.0.20.202(10.0.20.202:3306) as a new master.
10.0.20.202(10.0.20.202:3306): OK: Applying all logs succeeded.
10.0.20.202(10.0.20.202:3306): OK: Activated master IP address.
10.0.20.204(10.0.20.204:3306): OK: Slave started, replicating from 10.0.20.202(10.0.20.202:3306)
10.0.20.203(10.0.20.203:3306): OK: Slave started, replicating from 10.0.20.202(10.0.20.202:3306)
10.0.20.202(10.0.20.202:3306): Resetting slave info succeeded.
Master failover to 10.0.20.202(10.0.20.202:3306) completed successfully.
Fri Jun 14 10:01:10 2019 - [info] Sending mail..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   347  100    45  100   302    133    897 --:--:-- --:--:-- --:--:--   898

由上面的日志以及各节点状态看出，vip已经自动漂移到node02的服务器上，并且node02自动提升为主库，node03 和 node04 自动同步node02的库。

同时也收到了微信和邮件告警。

自动切换步骤

从上面的输出可以看出整个 MHA 的切换过程,共包括以下的步骤：

配置文件检查阶段,这个阶段会检查整个集群配置文件配置
宕机的 master 处理,这个阶段包括虚拟 ip 摘除操作,主机关机操作（由于没有定义power_manager脚本，不会关机）
复制 dead maste 和最新 slave 相差的 relay log,并保存到 MHA Manger 具体的目录下
识别含有最新更新的 slave
应用从 master 保存的二进制日志事件(binlog events)（这点信息对于将故障master修复后加入集群很重要）
提升一个 slave 为新的 master 进行复制
使其他的 slave 连接新的 master 进行复制

修复后重新加入集群

切换完成后,关注如下变化:

vip 自动从原来的 master 切换到新的 master,同时,manager 节点的监控进程自动退出。
在日志目录(/var/log/mha/app1)产生一个 app1.failover.complete 文件
/etc/mha/app1.cnf 配置文件中原来老的 master 配置被删除。

模拟宕机的时候，停止了MySQL进程，现在重新启动MySQL，并加入到Node02 的从库中

node02 操作

[root@node02 ~]# mysql -uroot -p123456 -e 'show master status\G'
mysql: [Warning] Using a password on the command line interface can be insecure.
*************************** 1. row ***************************
             File: mysql-bin.000002
         Position: 194
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 6211616e-8db3-11e9-be15-005056990727:4-5

node01 操作

mysql> change master to master_host='10.0.20.202',master_user='repl',master_password='123456',master_log_file='mysql-bin.000002',master_log_pos=194;
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
[root@node01 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.202
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

manager 操作

需要注意的是，当发生宕机切换后，manager中的MHA进程会自动停止，在修复后，需要手动再次启动

当发生宕机切换，MHA会自动把宕机的信息从app1.cnf配置文件中删除，修复后机器，要把信息重新写入到app1.cnf中。

修改前

[root@manager mha]# pwd
/etc/mha
[root@manager mha]# cat app1.cnf 
[server2]
candidate_master=1
check_repl_delay=0
hostname=10.0.20.202
port=3306

[server3]
hostname=10.0.20.203
port=3306

[server4]
hostname=10.0.20.204
port=3306

修改后

[root@manager mha]# cat app1.cnf 
[server1]
candidate_master=1
check_repl_delay=0
hostname=10.0.20.201

[server2]
hostname=10.0.20.202
port=3306

[server3]
hostname=10.0.20.203
port=3306

[server4]
hostname=10.0.20.204
port=3306

重新启动MHA

修改好配置文件后，再次启动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 &

此时修复完成。

在线进行切换

在许多情况下，需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障，RAID 控制卡需要重建，将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降，导致停机时间至少无法写入数据。另外，阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。 MHA 提供快速切换和优雅的阻塞写入，这个切换过程只需要 0.5-2s 的时间，这段时间内数据是无法写入的。在很多情况下，0.5-2s 的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口。

MHA在线切换的大概过程：

检测复制设置和确定当前主服务器
确定新的主服务器
阻塞写入到当前主服务器
等待所有从服务器赶上复制
授予写入到新的主服务器
重新设置从服务器

注意，在线切换的时候应用架构需要考虑以下两个问题：

自动识别master和slave的问题（master的机器可能会切换），如果采用了vip的方式，基本可以解决这个问题。
负载均衡的问题（可以定义大概的读写比例，每台机器可承担的负载比例，当有机器离开集群时，需要考虑这个问题）

为了保证数据完全一致性，在最快的时间内完成切换，MHA的在线切换必须满足以下条件才会切换成功，否则会切换失败。

所有slave的IO线程都在运行
所有slave的SQL线程都在运行
所有的show slave status的输出中Seconds_Behind_Master参数小于或者等于running_updates_limit秒，如果在切换过程中不指定running_updates_limit,那么默认情况下running_updates_limit为1秒。
在master端，通过show processlist输出，没有一个更新花费的时间大于running_updates_limit秒。

停止MHA 的manager 监控

[root@manager mha]# masterha_stop --conf=/etc/mha/app1.cnf
Stopped app1 successfully.
[1]+  Exit 1                  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

执行切换命令

进行在线切换操作

模拟在线切换主库操作，原主库10.0.20.202变为slave，10.0.20.201提升为新的主库

上一次进行了模拟宕机测试，最开始的主库是201，切换到了202位主库了

[root@manager mha]# masterha_master_switch --conf=/etc/mha/app1.cnf --master_state=alive --new_master_host=10.0.20.201 --orig_master_is_new_slave --running_updates_limit=10000 --interactive=0

执行后输出的日志如下：

Fri Jun 14 11:30:26 2019 - [info] MHA::MasterRotate version 0.58.
Fri Jun 14 11:30:26 2019 - [info] Starting online master switch..
Fri Jun 14 11:30:26 2019 - [info] 
Fri Jun 14 11:30:26 2019 - [info] * Phase 1: Configuration Check Phase..
Fri Jun 14 11:30:26 2019 - [info] 
Fri Jun 14 11:30:26 2019 - [info] Reading default configuration from /etc/masterha_default.cnf..
Fri Jun 14 11:30:26 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Jun 14 11:30:26 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Jun 14 11:30:27 2019 - [info] GTID failover mode = 1
Fri Jun 14 11:30:27 2019 - [info] Current Alive Master: 10.0.20.202(10.0.20.202:3306)
Fri Jun 14 11:30:27 2019 - [info] Alive Slaves:
Fri Jun 14 11:30:27 2019 - [info]   10.0.20.201(10.0.20.201:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 11:30:27 2019 - [info]     GTID ON
Fri Jun 14 11:30:27 2019 - [info]     Replicating from 10.0.20.202(10.0.20.202:3306)
Fri Jun 14 11:30:27 2019 - [info]     Primary candidate for the new Master (candidate_master is set)
Fri Jun 14 11:30:27 2019 - [info]   10.0.20.203(10.0.20.203:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 11:30:27 2019 - [info]     GTID ON
Fri Jun 14 11:30:27 2019 - [info]     Replicating from 10.0.20.202(10.0.20.202:3306)
Fri Jun 14 11:30:27 2019 - [info]   10.0.20.204(10.0.20.204:3306)  Version=5.7.18-log (oldest major version between slaves) log-bin:enabled
Fri Jun 14 11:30:27 2019 - [info]     GTID ON
Fri Jun 14 11:30:27 2019 - [info]     Replicating from 10.0.20.202(10.0.20.202:3306)
Fri Jun 14 11:30:27 2019 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] Checking MHA is not monitoring or doing failover..
Fri Jun 14 11:30:27 2019 - [info] Checking replication health on 10.0.20.201..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] Checking replication health on 10.0.20.203..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] Checking replication health on 10.0.20.204..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] 10.0.20.201 can be new master.
Fri Jun 14 11:30:27 2019 - [info] 
From:
10.0.20.202(10.0.20.202:3306) (current master)
 +--10.0.20.201(10.0.20.201:3306)
 +--10.0.20.203(10.0.20.203:3306)
 +--10.0.20.204(10.0.20.204:3306)

To:
10.0.20.201(10.0.20.201:3306) (new master)
 +--10.0.20.203(10.0.20.203:3306)
 +--10.0.20.204(10.0.20.204:3306)
 +--10.0.20.202(10.0.20.202:3306)
Fri Jun 14 11:30:27 2019 - [info] Checking whether 10.0.20.201(10.0.20.201:3306) is ok for the new master..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] 10.0.20.202(10.0.20.202:3306): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.
Fri Jun 14 11:30:27 2019 - [info] 10.0.20.202(10.0.20.202:3306): Resetting slave pointing to the dummy host.
Fri Jun 14 11:30:27 2019 - [info] ** Phase 1: Configuration Check Phase completed.
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info] * Phase 2: Rejecting updates Phase..
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info] Executing master ip online change script to disable write on the current master:
Fri Jun 14 11:30:27 2019 - [info]   /etc/mha/scripts/master_ip_online_change --command=stop --orig_master_host=10.0.20.202 --orig_master_ip=10.0.20.202 --orig_master_port=3306 --orig_master_user='root' --new_master_host=10.0.20.201 --new_master_ip=10.0.20.201 --new_master_port=3306 --new_master_user='root' --orig_master_ssh_user=root --new_master_ssh_user=root   --orig_master_is_new_slave --orig_master_password=xxx --new_master_password=xxx



****************************

Disabled thi VIP - 10.0.20.199/24 on old master: 10.0.20.202 

Disabled the VIP successfully
***************************



Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] Locking all tables on the orig master to reject updates from everybody (including root):
Fri Jun 14 11:30:27 2019 - [info] Executing FLUSH TABLES WITH READ LOCK..
Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] Orig master binlog:pos is mysql-bin.000002:194.
Fri Jun 14 11:30:27 2019 - [info]  Waiting to execute all relay logs on 10.0.20.201(10.0.20.201:3306)..
Fri Jun 14 11:30:27 2019 - [info]  master_pos_wait(mysql-bin.000002:194) completed on 10.0.20.201(10.0.20.201:3306). Executed 0 events.
Fri Jun 14 11:30:27 2019 - [info]   done.
Fri Jun 14 11:30:27 2019 - [info] Getting new master's binlog name and position..
Fri Jun 14 11:30:27 2019 - [info]  mysql-bin.000005:194
Fri Jun 14 11:30:27 2019 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='10.0.20.201', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='xxx';
Fri Jun 14 11:30:27 2019 - [info] Executing master ip online change script to allow write on the new master:
Fri Jun 14 11:30:27 2019 - [info]   /etc/mha/scripts/master_ip_online_change --command=start --orig_master_host=10.0.20.202 --orig_master_ip=10.0.20.202 --orig_master_port=3306 --orig_master_user='root' --new_master_host=10.0.20.201 --new_master_ip=10.0.20.201 --new_master_port=3306 --new_master_user='root' --orig_master_ssh_user=root --new_master_ssh_user=root   --orig_master_is_new_slave --orig_master_password=xxx --new_master_password=xxx



*************************

Enabling the VIP - 10.0.20.199/24 on new master: 10.0.20.201 

Enabled the VIP successfully
***************************



Fri Jun 14 11:30:27 2019 - [info]  ok.
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info] * Switching slaves in parallel..
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info] -- Slave switch on host 10.0.20.203(10.0.20.203:3306) started, pid: 7081
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info] -- Slave switch on host 10.0.20.204(10.0.20.204:3306) started, pid: 7082
Fri Jun 14 11:30:27 2019 - [info] 
Fri Jun 14 11:30:29 2019 - [info] Log messages from 10.0.20.203 ...
Fri Jun 14 11:30:29 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info]  Waiting to execute all relay logs on 10.0.20.203(10.0.20.203:3306)..
Fri Jun 14 11:30:27 2019 - [info]  master_pos_wait(mysql-bin.000002:194) completed on 10.0.20.203(10.0.20.203:3306). Executed 0 events.
Fri Jun 14 11:30:27 2019 - [info]   done.
Fri Jun 14 11:30:27 2019 - [info]  Resetting slave 10.0.20.203(10.0.20.203:3306) and starting replication from the new master 10.0.20.201(10.0.20.201:3306)..
Fri Jun 14 11:30:27 2019 - [info]  Executed CHANGE MASTER.
Fri Jun 14 11:30:28 2019 - [info]  Slave started.
Fri Jun 14 11:30:29 2019 - [info] End of log messages from 10.0.20.203 ...
Fri Jun 14 11:30:29 2019 - [info] 
Fri Jun 14 11:30:29 2019 - [info] -- Slave switch on host 10.0.20.203(10.0.20.203:3306) succeeded.
Fri Jun 14 11:30:29 2019 - [info] Log messages from 10.0.20.204 ...
Fri Jun 14 11:30:29 2019 - [info] 
Fri Jun 14 11:30:27 2019 - [info]  Waiting to execute all relay logs on 10.0.20.204(10.0.20.204:3306)..
Fri Jun 14 11:30:27 2019 - [info]  master_pos_wait(mysql-bin.000002:194) completed on 10.0.20.204(10.0.20.204:3306). Executed 0 events.
Fri Jun 14 11:30:27 2019 - [info]   done.
Fri Jun 14 11:30:27 2019 - [info]  Resetting slave 10.0.20.204(10.0.20.204:3306) and starting replication from the new master 10.0.20.201(10.0.20.201:3306)..
Fri Jun 14 11:30:27 2019 - [info]  Executed CHANGE MASTER.
Fri Jun 14 11:30:28 2019 - [info]  Slave started.
Fri Jun 14 11:30:29 2019 - [info] End of log messages from 10.0.20.204 ...
Fri Jun 14 11:30:29 2019 - [info] 
Fri Jun 14 11:30:29 2019 - [info] -- Slave switch on host 10.0.20.204(10.0.20.204:3306) succeeded.
Fri Jun 14 11:30:29 2019 - [info] Unlocking all tables on the orig master:
Fri Jun 14 11:30:29 2019 - [info] Executing UNLOCK TABLES..
Fri Jun 14 11:30:29 2019 - [info]  ok.
Fri Jun 14 11:30:29 2019 - [info] Starting orig master as a new slave..
Fri Jun 14 11:30:29 2019 - [info]  Resetting slave 10.0.20.202(10.0.20.202:3306) and starting replication from the new master 10.0.20.201(10.0.20.201:3306)..
Fri Jun 14 11:30:29 2019 - [info]  Executed CHANGE MASTER.
Fri Jun 14 11:30:30 2019 - [info]  Slave started.
Fri Jun 14 11:30:30 2019 - [info] All new slave servers switched successfully.
Fri Jun 14 11:30:30 2019 - [info] 
Fri Jun 14 11:30:30 2019 - [info] * Phase 5: New master cleanup phase..
Fri Jun 14 11:30:30 2019 - [info] 
Fri Jun 14 11:30:30 2019 - [info]  10.0.20.201: Resetting slave info succeeded.
Fri Jun 14 11:30:30 2019 - [info] Switching master to 10.0.20.201(10.0.20.201:3306) completed successfully.

查看状态

node01

[root@node01 ~]# mysql -uroot -p123456 -e 'show slave status\G'
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@node01 ~]# ip a | grep 20
    inet 10.0.20.201/24 brd 10.0.20.255 scope global bond0
    inet 10.0.20.199/24 brd 10.0.20.255 scope global secondary bond0:1

node02

[root@node02 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.201
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
[root@node02 ~]# ip a | grep 20
    inet 10.0.20.202/24 brd 10.0.20.255 scope global bond0

node03

[root@node03 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.201
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

node04

[root@node04 ~]# mysql -uroot -p123456 -e "show slave status\G" | egrep 'Master_Host|Slave_IO_Running|Slave_SQL_Running'
mysql: [Warning] Using a password on the command line interface can be insecure.
                  Master_Host: 10.0.20.201
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

从上面各个数据库的状态可以看出来，主库已经变成了node01了，并且vip也漂移到node01的机器上了。

报错解决

报错一、

报错信息：

Can't locate Parallel/ForkManager.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/share/perl5/MHA/SSHCheck.pm line 31.
BEGIN failed--compilation aborted at /usr/local/share/perl5/MHA/SSHCheck.pm line 31.
Compilation failed in require at /usr/local/bin/masterha_check_ssh line 25.
BEGIN failed--compilation aborted at /usr/local/bin/masterha_check_ssh line 25.

解决：

yum install cpan

cpan Module::Build

# 上面的命令执行完成后，需要重新解压 mha-manager 的包
再次执行 

perl Makefile.PL

make
# 这一步中 会提示 输入，都输入yes 回车

make install

滴滴开源夜莺Nightingale：企业级监控解决方案

Mon, 13 Apr 2020 23:33:04 +0800

夜莺（Nightingale）是滴滴基础平台联合滴滴云研发和开源的企业级监控解决方案。旨在满足云原生时代企业级的监控需求。Nightingale 在产品完成度、系统高可用、以及用户体验方面，达到了企业级的要求，可满足不同规模用户的场景，小到几台机器，大到数十万都可以完美支撑。兼顾云原生和裸金属，支持应用监控和系统监控，插件机制灵活，插件丰富完善，具有高度的灵活性和可扩展性。

GitHub 地址：https://github.com/didi/nightingale

Nightingale 在 Open-Falcon 的基础上，结合滴滴内部的最佳实践，在性能、可维护性、易用性方面做了大量的改进，作为集团统一的监控解决方案，支撑了滴滴内部数十亿监控指标，覆盖了从系统、容器、到应用等各层面的监控需求，周活跃用户数千。五年磨一剑，取之开源，回馈开源。

Nightingale 采用树状节点导航，我们称之为对象树。对象树本质上是一种对监控对象的分组管理机制，方便查找和查看监控对象，以及对监控对象设置监控策略等管理动作。一棵典型的树可从上到下描述为组织架构关系、产品服务模块关系、机房和机器挂载关系，该导航树可根据用户需求自行灵活定制。

监控策略应用到某个节点后，该节点下的所有子节点挂载的所有的机器都会应用这个策略，任何一台机器触发相关阈值都会产生告警。

监控大盘的定制做了大幅易用性改进，支持了图表阈值，支持了图表分类，新增图表和排序管理都是可见即所得的方式，巡检大盘的定制从此不再是困难。

Nightingale 是在 Open-Falcon 的基础上衍化发展而来，Open-Falcon 作为国内使用最广泛的监控解决方案之一，为 Nightingale 的设计开发提供了大量的借鉴意义。

与Open-Falcon的不同点

告警引擎重构：Open-Falcon 的告警策略，在监控数据推送上来的同时会触发策略判断，这种「推」的模式优势是策略的判断时效性非常高，但是不利于更高级的告警策略的支持和扩展，比如多条件的组合报警就很难支持。Nightingale 转为推拉结合模式，通过推模式保证大部分策略判断的效率，通过拉模式支持了与条件告警和 nodata 告警；
引入了导航对象树：将 Open-Falcon 采用的扁平 HostGroup，转为 Nightingale 的导航对象树，对象树本质上是一种对监控对象的分组管理机制，方便查找和查看监控对象，以及对监控对象设置监控策略等管理动作。同时在 Nightingale 中，去除了告警模板的概念，告警策略直接与树节点绑定，简化设计，大幅提升灵活度和易用性；
索引模块升级换代：Open-Falcon 使用 MySQL 存储 metrics 的索引数据，在扩展性和灵活性上存在瓶颈。Nightingale 根据监控需求，设计开发了全新的内存索引模块 index，查询方式更多样，查询效率更高，避免了原来 MySQL 索引数据达到亿级别时面临的维护优化工作；
时序数据库优化：在 Open-Falcon 存储模块 Graph 的基础上，引入 Facebook 的 Gorilla 压缩方案，近期几个小时的数据采用内存存储，大幅提升数据查询效率，长期数据仍然使用 rrdtool 数据格式存储在硬盘上。同时进一步完善了时序数据库的性能和稳定性；
告警引擎高可用改进：告警引擎 judge 模块通过心跳机制做到了故障自动摘除，再也不用担心单个 judge 宕机导致部分策略失效，需要人工介入的问题，index 模块也是采用类似方式保证可用性；
原生内置日志监控功能：Nightingale 客户端原生内置了日志匹配和指标抽取能力，在 web 控制台页面上支持了日志匹配规则的配置，同时也支持读取目标机器特定目录下的配置文件的方式，让业务指标监控更为易用；
可运维性增强：将 portal（falcon-plus 中的API）、uic、dashboard、hbs、alarm 合并为一个模块：monapi，简化了系统整体部署难度，原来的部分模块间调用变成进程内方法调用，性能更高；
配置文件中心化：配置文件做了易用性改造，抽取数据库通用配置到 mysql.yml，抽取端口实例地址等关联配置到 address.yml，大批配置在代码里给了默认值，使得配置文件更清晰，易于维护。

与Open-Falcon的相同点

数据模型没有变化，仍然是 metric、endpoint、tags 的组织方式，agent 基本是可以复用的，Nightingale 中的 agent 叫 collector，融合了原来 Open-Falcon 的 agent 和 falcon-log-agent 的逻辑，各种监控插件也都是可以复用的。

数据流向和整体处理逻辑是类似的，仍然使用灵活的推模型，分为数据存储和告警判断两条链路。

Nightingale架构

collector 即 agent，可以采集机器常见指标，原生支持日志监控，支持插件机制，支持业务通过接口直接上报数据；
transfer 提供 rpc 接口接收 collector 上报的数据，然后通过一致性哈希，将数据转发给多台 tsdb 和多台 judge；
tsdb 即 open-falcon 中的 graph 组件，用于存储历史数据，支持配置为双写模式提升系统容灾能力，tsdb 会把监控数据转发一份给 index 建索引；
index 是内存索引模块，替换原来的 MySQL 方案，在内存里构建索引，便于后续数据检索，在检索的灵活性和检索性能方面大幅提升；
judge 是告警引擎，从 monapi（portal）同步监控策略，然后对接收到的数据做告警判断，如满足阈值，则生成告警事件推送到 Redis 队列；
monapi（alarm）从 Redis 队列中读取 judge 生成的事件，进行二次处理，补充一些元信息，生成告警消息，重新推送回 Redis 队列；
各发送组件，比如 mail-sender、sms-sender 等，从 Redis 读取告警消息，发送告警，抽象出各类 sender 是为了后续定制方便；
monapi 集成了原来多个模块的功能，提供接口给 js 调用，api 前缀为 /api/portal，数据查询走 transfer，去除了 open-falcon 中原来的 query 组件，api 前缀为 /api/transfer，索引查询的 api 前缀 /api/index，于是，在前端统一搭建 nginx，即可通过不同 location 将请求转发到不同后端；
数据库仍然使用 MySQL，主要存储的内容包括：用户信息、团队信息、树节点信息、告警策略、监控大盘、屏蔽策略、采集策略、部分组件心跳信息等。

仍在进行中的工作

提供监控指标聚合组件，现在的架构可以解决机器级、模块级的监控，但是集群维度的监控指标，是需要聚合整个集群的所有模块、机器的指标，做一些加和、求平均之类的操作，相关聚合组件，我们在紧锣密鼓的开源过程中；
与 Kubernetes 无缝集成的工作，也在进行之中；
完善更多监控插件，之前 Open-Falcon 社区里的很多插件都是可以直接用的，我们会尽量补充社区没有的插件，并对社区已有的插件，进行二次整理和维护，让 Nightingale 周边更完善。

基于 Prometheus 构建高大上的 MySQL 监控平台

Mon, 13 Apr 2020 23:09:20 +0800

概述

对于MySQL的监控平台，相信大家实现起来有很多了：基于天兔的监控，还有基于zabbix相关的二次开发。相信很多同行都应该已经开始玩起来了。我这边的选型是prometheus + granafa 的实现方式。简而言之就是我现在的生产环境使用的是prometheus，还有就是 granafa 满足的我的日常工作需要。

1、首先看下我们的监控效果

2、MySQL状态：

exporter 相关部署

安装exporter：

[root@controller2 opt]# https://github.com/prometheus/mysqld_exporter/releases/download/v0.10.0/mysqld_exporter-0.10.0.linux-amd64.tar.gz
[root@controller2 opt]# tar -xf mysqld_exporter-0.10.0.linux-amd64.tar.gz

2、添加mysql 账户：

GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT, RELOAD ON *.* TO 'exporter'@'%' IDENTIFIED BY 'localhost';
flush privileges;

3、编辑配置文件：

[root@controller2 mysqld_exporter-0.10.0.linux-amd64]# cat /opt/mysqld_exporter-0.10.0.linux-amd64/.my.cnf
[client]
user=exporter
password=123456

4、设置配置文件：

[root@controller2 mysqld_exporter-0.10.0.linux-amd64]# cat /etc/systemd/system/mysql_exporter.service
[Unit]
Description=mysql Monitoring System
Documentation=mysql Monitoring System

[Service]
ExecStart=/opt/mysqld_exporter-0.10.0.linux-amd64/mysqld_exporter \
         -collect.info_schema.processlist \
         -collect.info_schema.innodb_tablespaces \
         -collect.info_schema.innodb_metrics  \
         -collect.perf_schema.tableiowaits \
         -collect.perf_schema.indexiowaits \
         -collect.perf_schema.tablelocks \
         -collect.engine_innodb_status \
         -collect.perf_schema.file_events \
         -collect.info_schema.processlist \
         -collect.binlog_size \
         -collect.info_schema.clientstats \
         -collect.perf_schema.eventswaits \
         -config.my-cnf=/opt/mysqld_exporter-0.10.0.linux-amd64/.my.cnf

[Install]
WantedBy=multi-user.target

5、添加配置到prometheus server

 - job_name: 'mysql'
    static_configs:
     - targets: ['192.168.1.11:9104','192.168.1.12:9104']

6、测试看有没有返回数值：

http://192.168.1.12:9104/metrics

正常我们通过mysql_up可以查询倒mysql监控是否已经生效，是否起起来

#HELP mysql_up Whether the MySQL server is up.
#TYPE mysql_up gauge
mysql_up 1

监控相关指标

在做任何一个东西监控的时候，我们要时刻明白我们要监控的是什么，指标是啥才能更好的去监控我们的服务，在mysql里面我们通常可以通过一下指标去衡量mysql的运行情况：mysql主从运行情况、查询吞吐量、慢查询情况、连接数情况、缓冲池使用情况以及查询执行性能等。

主从复制运行指标：

1、主从复制线程监控：

大部分情况下，很多企业使用的都是主从复制的环境，监控两个线程是非常重要的，在mysql里面我们通常是通过命令：

MariaDB [(none)]> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.16.1.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000045
          Read_Master_Log_Pos: 72904854
               Relay_Log_File: mariadb-relay-bin.000127
                Relay_Log_Pos: 72905142
        Relay_Master_Log_File: mysql-bin.000045
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

Slave_IO_Running、Slave_SQL_Running两个线程正常那么说明我们的复制集群是健康状态的。

MySQLD Exporter中返回的样本数据中通过mysql_slave_status_slave_sql_running来获取主从集群的健康状况。

# HELP mysql_slave_status_slave_sql_running Generic metric from SHOW SLAVE STATUS.
# TYPE mysql_slave_status_slave_sql_running untyped
mysql_slave_status_slave_sql_running{channel_name="",connection_name="",master_host="172.16.1.1",master_uuid=""} 1

2、主从复制落后时间：

在使用show slave status 里面还有一个关键的参数Seconds_Behind_Master。Seconds_Behind_Master表示slave上SQL thread与IO thread之间的延迟，我们都知道在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO thread），然后通过SQL thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被执行完的那部分的差值。所以如果slave拉取到本地的relaylog（实际上就是binlog，只是在slave上习惯称呼relaylog而已）都执行完，此时通过show slave status看到的会是0

Seconds_Behind_Master: 0

MySQLD Exporter中返回的样本数据中通过mysql_slave_status_seconds_behind_master 来获取相关状态。

# HELP mysql_slave_status_seconds_behind_master Generic metric from SHOW SLAVE STATUS.
# TYPE mysql_slave_status_seconds_behind_master untyped
mysql_slave_status_seconds_behind_master{channel_name="",connection_name="",master_host="172.16.1.1",master_uuid=""} 0

查询吞吐量：

说到吞吐量，那么我们如何从那方面来衡量呢？

通常来说我们可以根据mysql 的插入、查询、删除、更新等操作来

为了获取吞吐量，MySQL 有一个名为 Questions 的内部计数器（根据 MySQL 用语，这是一个服务器状态变量），客户端每发送一个查询语句，其值就会加一。由 Questions 指标带来的以客户端为中心的视角常常比相关的Queries 计数器更容易解释。作为存储程序的一部分，后者也会计算已执行语句的数量，以及诸如PREPARE 和 DEALLOCATE PREPARE 指令运行的次数，作为服务器端预处理语句的一部分。可以通过命令来查询：

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Questions";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions     | 15071 |
+---------------+-------+

MySQLD Exporter 中返回的样本数据中通过 mysql_global_status_questions反映当前Questions计数器的大小：

# HELP mysql_global_status_questions Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_questions untyped
mysql_global_status_questions 13253

当然由于prometheus 具有非常丰富的查询语言，我们可以通过这个累加的计数器来查询某一短时间内的查询增长率情况，可以做相关的阈值告警处理、例如一下查询2分钟时间内的查询情况：

rate(mysql_global_status_questions[2m])

当然上面是总量，我们可以分别从监控读、写指令的分解情况，从而更好地理解数据库的工作负载、找到可能的瓶颈。通常，通常，读取查询会由 Com_select 指标抓取，而写入查询则可能增加三个状态变量中某一个的值，这取决于具体的指令：

Writes = Com_insert + Com_update + Com_delete

下面我们通过命令获取插入的情况：

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Com_insert";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_insert    | 10578 |
+---------------+-------+

从MySQLD Exporter的/metrics返回的监控样本中，可以通过global_status_commands_total获取当前实例各类指令执行的次数：

# HELP mysql_global_status_commands_total Total number of executed MySQL commands.
# TYPE mysql_global_status_commands_total counter
mysql_global_status_commands_total{command="create_trigger"} 0
mysql_global_status_commands_total{command="create_udf"} 0
mysql_global_status_commands_total{command="create_user"} 1
mysql_global_status_commands_total{command="create_view"} 0
mysql_global_status_commands_total{command="dealloc_sql"} 0
mysql_global_status_commands_total{command="delete"} 3369
mysql_global_status_commands_total{command="delete_multi"} 0

慢查询性能

查询性能方面，慢查询也是查询告警的一个重要的指标。MySQL还提供了一个Slow_queries的计数器，当查询的执行时间超过long_query_time的值后，计数器就会+1，其默认值为10秒，可以通过以下指令在MySQL中查询当前long_query_time的设置：

MariaDB [(none)]> SHOW VARIABLES LIKE 'long_query_time';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)

当然我们也可以修改时间

MariaDB [(none)]> SET GLOBAL long_query_time = 5;
Query OK, 0 rows affected (0.00 sec)

然后我们而已通过sql语言查询 MySQL 实例中 Slow_queries 的数量：

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Slow_queries";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries  | 0     |
+---------------+-------+
1 row in set (0.00 sec)

MySQLD Exporter返回的样本数据中，通过mysql_global_status_slow_queries指标展示当前的Slow_queries的值：

# HELP mysql_global_status_slow_queries Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_slow_queries untyped
mysql_global_status_slow_queries 0

同样的，更具根据 Prometheus 慢查询语句我们也可以查询到他某段时间内的增长率：

rate(mysql_global_status_slow_queries[5m])

连接数监控

监控客户端连接情况相当重要，因为一旦可用连接耗尽，新的客户端连接就会遭到拒绝。MySQL 默认的连接数限制为 151。

MariaDB [(none)]> SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+

当然我们可以修改配置文件的形式来增加这个数值。与之对应的就是当前连接数量，当我们当前连接出来超过系统设置的最大值之后常会出现我们看到的Too many connections(连接数过多)，下面我查找一下当前连接数：

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Threads_connected";
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 41     |
+-------------------+-------

当然 mysql 还提供 Threads_running 这个指标，帮助你分隔在任意时间正在积极处理查询的线程与那些虽然可用但是闲置的连接。

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Threads_running";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Threads_running | 10     |
+-----------------+-------+

如果服务器真的达到 max_connections 限制，它就会开始拒绝新的连接。在这种情况下，Connection_errors_max_connections 指标就会开始增加，同时，追踪所有失败连接尝试的Aborted_connects 指标也会开始增加。

MySQLD Exporter返回的样本数据中:

# HELP mysql_global_variables_max_connections Generic gauge metric from SHOW GLOBAL VARIABLES.
# TYPE mysql_global_variables_max_connections gauge
mysql_global_variables_max_connections 151

表示最大连接数

# HELP mysql_global_status_threads_connected Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_threads_connected untyped
mysql_global_status_threads_connected 41

表示当前的连接数

# HELP mysql_global_status_threads_running Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_threads_running untyped
mysql_global_status_threads_running 1

表示当前活跃的连接数

# HELP mysql_global_status_aborted_connects Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_aborted_connects untyped
mysql_global_status_aborted_connects 31

累计所有的连接数

# HELP mysql_global_status_connection_errors_total Total number of MySQL connection errors.
# TYPE mysql_global_status_connection_errors_total counter
mysql_global_status_connection_errors_total{error="internal"} 0
#服务器内部引起的错误、如内存硬盘等
mysql_global_status_connection_errors_total{error="max_connections"} 0
#超出连接处引起的错误

当然根据 prom 表达式，我们可以查询当前剩余可用的连接数：

mysql_global_variables_max_connections - mysql_global_status_threads_connected

查询 MySQL 拒绝连接数

mysql_global_status_aborted_connects

缓冲池情况：

MySQL 默认的存储引擎 InnoDB 使用了一片称为缓冲池的内存区域，用于缓存数据表与索引的数据。缓冲池指标属于资源指标，而非工作指标，前者更多地用于调查（而非检测）性能问题。如果数据库性能开始下滑，而磁盘 I/O 在不断攀升，扩大缓冲池往往能带来性能回升。

默认设置下，缓冲池的大小通常相对较小，为 128MiB。不过，MySQL 建议可将其扩大至专用数据库服务器物理内存的 80% 大小。我们可以查看一下：

MariaDB [(none)]> show global variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+

MySQLD Exporter 返回的样本数据中，使用mysql_global_variables_innodb_buffer_pool_size来表示。

# HELP mysql_global_variables_innodb_buffer_pool_size Generic gauge metric from SHOW GLOBAL VARIABLES.
# TYPE mysql_global_variables_innodb_buffer_pool_size gauge
mysql_global_variables_innodb_buffer_pool_size 1.34217728e+08

Innodb_buffer_pool_read_requests记录了正常从缓冲池读取数据的请求数量。可以通过以下指令查看

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Innodb_buffer_pool_read_requests";
+----------------------------------+-------------+
| Variable_name                    | Value       |
+----------------------------------+-------------+
| Innodb_buffer_pool_read_requests | 38465 |
+----------------------------------+-------------+

MySQLD Exporter返回的样本数据中，使用mysql_global_status_innodb_buffer_pool_read_requests来表示。

# HELP mysql_global_status_innodb_buffer_pool_read_requests Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_innodb_buffer_pool_read_requests untyped
mysql_global_status_innodb_buffer_pool_read_requests 2.7711547168e+10

当缓冲池无法满足时，MySQL只能从磁盘中读取数据。Innodb_buffer_pool_reads即记录了从磁盘读取数据的请求数量。通常来说从内存中读取数据的速度要比从磁盘中读取快很多，因此，如果Innodb_buffer_pool_reads的值开始增加，可能意味着数据库的性能有问题。可以通过以下只能查看Innodb_buffer_pool_reads的数量

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE "Innodb_buffer_pool_reads";
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Innodb_buffer_pool_reads | 138  |
+--------------------------+-------+
1 row in set (0.00 sec)

MySQLD Exporter 返回的样本数据中，使用 mysql_global_status_innodb_buffer_pool_read_requests 来表示。

# HELP mysql_global_status_innodb_buffer_pool_reads Generic metric from SHOW GLOBAL STATUS.
# TYPE mysql_global_status_innodb_buffer_pool_reads untyped
mysql_global_status_innodb_buffer_pool_reads 138

通过以上监控指标，以及实际监控的场景，我们可以利用PromQL快速建立多个监控项。可以查看两分钟内读取磁盘的增长率的增长率：

rate(mysql_global_status_innodb_buffer_pool_reads[2m])

官方模板 ID

上面是我们简单列举的一些指标，下面我们使用granafa给 MySQLD_Exporter添加监控图表：

主从主群监控(模板7371)：
相关 MySQL 状态监控7362：
缓冲池状态 7365：

简单的告警规则

除了相关模板之外，没有告警规则那么我们的监控就是不完美的，下面列一下我们的监控告警规则。

groups:
- name: MySQL-rules
  rules:
  - alert: MySQL Status
    expr: up == 0
    for: 5s
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: MySQL has stop !!!"
      description: "检测MySQL数据库运行状态"

  - alert: MySQL Slave IO Thread Status
    expr: mysql_slave_status_slave_io_running == 0
    for: 5s
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: MySQL Slave IO Thread has stop !!!"
      description: "检测MySQL主从IO线程运行状态"

  - alert: MySQL Slave SQL Thread Status
    expr: mysql_slave_status_slave_sql_running == 0
    for: 5s
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: MySQL Slave SQL Thread has stop !!!"
      description: "检测MySQL主从SQL线程运行状态"

  - alert: MySQL Slave Delay Status
    expr: mysql_slave_status_sql_delay == 30
    for: 5s
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: MySQL Slave Delay has more than 30s !!!"
      description: "检测MySQL主从延时状态"

  - alert: Mysql_Too_Many_Connections
    expr: rate(mysql_global_status_threads_connected[5m]) > 200
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: 连接数过多"
      description: "{{$labels.instance}}: 连接数过多，请处理 ,(current value is: {{ $value }})"

  - alert: Mysql_Too_Many_slow_queries
    expr: rate(mysql_global_status_slow_queries[5m]) > 3
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: 慢查询有点多，请检查处理"
      description: "{{$labels.instance}}: Mysql slow_queries is more than 3 per second ,(current value is: {{ $value }})"

2、添加规则到 prometheus：

rule_files:
  - "rules/*.yml"

3、打开web ui我们可以看到规则生效了：

总结

到处监控 MySQL 的相关状态已经完成，大家可以根据 MySQL 更多的监控指标去完善自己的监控，当然这一套就是我用在线上环境的，可以参考参考

详解Mysql的锁机制

Mon, 13 Apr 2020 22:45:29 +0800

一、Mysql为什么要加锁

锁机制用于管理对共享资源的并发访问，是对数据库的一种保护机制，也是数据库在事务操作中保证事务数据一致性和完整性的一种机制。当有多个用户并发的去存取数据时，在数据库中就可能会产生多个事务同时去操作一行数据的情况，如果我们不对此类并发操作不加以控制的话，就可能会读取和存储不正确的数据，最终破坏了数据的一致性；下面请看一种典型的并发更新数据所产生的数据丢失更新问题：

| 事务A |事务B  |
|--|--|
| begin A |  |
||begin B|
|select salary form tb where id=1(查询结果为1000)||
||select salary form tb where id=1(查询结果为1000)|
|update tb set salary=1100 where id=1||
||update tb set salary=1200 where id=1|
|commit A||
||commit B|

异常结果：表中salary字段id为1员工的工资更新为了1200，但是实际上针对该员工的工资进行了两次的修改操作，由于事务B在事务A之后提交，所以首先提交的事务A的更新操作被丢失了，所以我们就需要锁机制来保证这种情况不会发生，保证事务中数据的一致性。

二、锁类型

表锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突概率高，并发度最低；

行锁：开销大，加锁慢；会出现死锁；锁定粒度小；发生锁冲突的概率低，并发度高；

三、MyISAM存储引擎：

表级锁的锁模式：　　　　

表级锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）；对于MyISAM表的读操作，不会阻塞其他用户对同一个表的读请求，但是会阻塞对同一个表的写请求；对MyISAM表的写操作，则会阻塞其他用户对同一个表的读和写操作；MyISAM表的读操作与写操作之间，以及写操作与写操作之间时串行的。

并发插入（Concurrent Inserts）：　　　　

MyISAM表的读和写是串行的，但这是就总体而言的，在一定的条件下，MyISAM表也可以支持查询和插入操作的并发进行；MyISAM存储引擎有一个系统变量concurrent_insert，专门用以控制其并发插入的行为，其值分为可以为0、1/2。当concurrent_insert设置为0时，则不允许并发插入；当concurrent_insert设置为1时，如果MyISAM表中没有空洞（即表的中间没有被删除的行），MyISAM允许在一个进程读表的同时，另一个进程从表尾插入记录，这也是MySQL的默认设置；当concurrent_insert设置为2时，无论MyISAM表中有没有空洞，都允许在表尾并发插入记录。可以利用MyISAM存储引擎此并发插入特性，来解决应用中对同一个表查询和插入的锁争用。例如：将concurrent_insert变量的值设为2，总是允许并发插入操作，同时通过定期在系统空闲时段执行OPTIMIZE TABLE语句来整理空间碎片，回收因删除记录而产生的中间空洞。

MyISAM引擎的锁调度：　　　　

MyISAM存储引擎的读锁和写锁是互斥的，读写操作时串行的。一个进程请求某个MyISAM表的读锁，同时另一个进程也请求同一个表的写锁，写的优先级比读的优先级更高，所以写进程会先获得锁，即使读请求先到锁的等待队列中，写请求后到锁的等待队列中，写锁页回插入到读锁请求之前执行；我们可以通过一些设置来调节MyISAM的调度行为，通过指定启动参数low-priority-updates，使MyISAM引擎默认给予读请求以优先的权利；通过执行命令SET LOW_PRIORITY_UPDATE=1，使该连接发出的更新请求优先级降低；通过指定INSERT、UPDATE、DELETE语句的LOW_PRIORITY属性，降低该语句的优先级。另外，MySQL也提供了一种折中的办法来调节读写冲突，即给系统参数max_write_lock_count设置一个合适的值，当一个表的读锁达到这个值后，MySQL就暂时将写请求的优先级降低，给读进程一定的获得锁的机会。

四、InnoDB存储引擎：

乐观锁与悲观锁是两种并发控制的思想，可用于解决丢失更新的问题：　　　　

乐观锁会"乐观的"假定大概率不会发生并发更新冲突，访问、处理数据过程中不加锁，只在更新数据时再根据版本号或时间戳判断是否有冲突，有则处理，无则提交事务；悲观锁会"悲观的"假定大概率会发生并发更新冲突，访问、处理数据前就加排他锁，在整个数据处理过程中锁定数据，事务提交或回滚后才释放锁；

InnoDB存储引擎标准的行级锁：　　　　

共享锁(S Lock)：读锁，允许事务读一行数据；　　　　

排他锁(X Lock)：写锁，允许事务删除或更新一行数据；

## 事务1
MariaDB [test]> show variables  like "autocommit";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> update tb1  set   name="aaa"  where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> commit;
Query OK, 0 rows affected (0.00 sec)



## 事务2：
MariaDB [test]> show variables like "autocommit";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> update tb1  set  name="haha"  where id=1;
Query OK, 1 row affected (12.89 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> rollback;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select *   from     tb1 where id=1;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
+----+------+
1 row in set (0.00 sec)

InnoDB行锁的实现方式：　　

InnoDB行锁是通过给索引上的索引项加锁的，InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则InnoDB将使用表锁。在不通过索引条件查询的时候，InnoDB确实是使用表锁而不是行锁；由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的；当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，无论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁；即便是在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁而不是行锁。

意向锁：　　　　

意向共享锁(IS Lock)：事务想要获得一张表中某几行的共享锁；　　　　

意向排他锁(IX Lock)：事务想要获得一张表中某几行的排它锁；　　　　

查看InnoDB存储引擎的锁信息：

MariaDB [test]> show  engine innodb status\G;
MariaDB [test]> show full processlist;
MariaDB [test]> select * from information_schema.innodb_trx\G;
*************************** 1. row ***************************
                    trx_id: 1266629
                 trx_state: RUNNING
               trx_started: 2020-01-08 16:24:50
     trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 0
       trx_mysql_thread_id: 36696
                 trx_query: select * from information_schema.innodb_trx
       trx_operation_state: NULL
         trx_tables_in_use: 0
         trx_tables_locked: 0
          trx_lock_structs: 0
     trx_lock_memory_bytes: 376
           trx_rows_locked: 0
         trx_rows_modified: 0
   trx_concurrency_tickets: 0
       trx_isolation_level: REPEATABLE READ
         trx_unique_checks: 1
    trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_adaptive_hash_latched: 0
 trx_adaptive_hash_timeout: 10000
1 row in set (0.00 sec)

MariaDB [test]> select * from information_schema.innodb_lock_waits\G;
Empty set (0.00 sec)

一致性的非锁定读(Consistent Nonlocking Read): 　　是指InnoDB存储引擎通过很多个版本控制(multi versioning)的方式来读取当前执行时间数据库中的行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此去等待行上的锁的释放；相反，InnoDB存储引擎会去读取行的一个快照数据，快照数据是指该行的之前的版本的数据，该实现是通过undo段来完成的。而undo用来事务中国回滚数据，因此快照数据本身是没有额外的开销。此外，读取快照数据是不需要上锁的，因为没有事务需要对历史数据进行修改操作。然而在不同的事务隔离级别下，对于快照数据，非一致性读总是读取被锁定行的最新一份快照数据，而在REPEATABLE READ事务隔离级别下，对于快照数据，非一致性读总是读取事务开始时的行数据版本。

一致性的锁定读：　　

显示地对数据库读取操作进行加锁以保证数据逻辑的一致性；　　

SELECT ... FOR UPDATE：对读取的行记录加一个X锁，其他事务不能对已锁定的行加任何的锁；　　

SELECT ... LOCK IN SHARE MODE：对读取的行记录加一个S锁，其他事务可以向被锁定的行加S锁，但是如果加X锁，则会被阻塞；

## 事务1
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select  * from   tb1 where id=1 for update;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
+----+------+
1 row in set (0.00 sec)

MariaDB [test]> rollback;
Query OK, 0 rows affected (0.00 sec)



## 事务2
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from tb1 where id=1 lock in share mode;
+----+------+
| id | name |
+----+------+
|  1 | aaa  |
+----+------+
1 row in set (11.55 sec)

MariaDB [test]> rollback;
Query OK, 0 rows affected (0.00 sec)

锁算法：

五、死锁

死锁是指两个或两个以上的事务在执行过程中，因争夺资源而造成的一种互相等待的现象；MyISAM表锁是Deadlock Free的，这时因为MyISAM总是一次获得所需的全部锁，要么全部满足，要么等待，因此不会出现死锁。但在InnoDB中，除单个SQL组成的事务外，锁是逐步获得的，这就决定了在InnoDB中发生死锁是可能的。发生死锁后，InnoDB一般都能自动检测到，并使一个事务释放锁并回退，另外一个事务获得锁，继续完成事务。但在涉及外部锁，或涉及表锁的情况下，InnoDB并不能完全自动检测到死锁，这需要通过设置锁等待超时参数innodb_lock_wait_timeout来解决，需要说明的是，这个参数并不是用来解决死锁问题，在并发访问比较高的情况下，如果大量事务因无法立即获得所需的锁而挂起，会占用大量计算机资源，造成严重性能问题，甚至拖垮数据库。我们通过设置合适的锁等待超时阈值，可以避免这种情况的发生。

## 事务1
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> update tb1  set   name="jyy"  where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> update tb1  set   name="xixi"  where id=2;
Query OK, 1 row affected (8.25 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> commit;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from    tb1  where id in(1,2);
+----+------+
| id | name |
+----+------+
|  1 | jyy  |
|  2 | xixi |
+----+------+
2 rows in set (0.00 sec)


## 事务2
MariaDB [test]> begin;
Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> update tb1  set  name="haha"  where id=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB [test]> update tb1  set  name="heihei"  where id=1;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

避免死锁的常用方法：　　

1）在应用中，如果不同的程序会并发存取多个表，应该尽量约定以相同的顺序来访问表，这样可以大大降低产生死锁的机会。在上面的例子中，由于两个session访问表的顺序不同，发生死锁的机会就非常高，但是如果以相同的顺序来访问，死锁就可以避免；　　

2）在程序以批量方式处理数据的时候，如果事先对数据排序，保证每个线程按固定的顺序来处理记录，也可以大大降低出现死锁的可能；　　

3）在事务中，如果要更新记录，应该直接申请足够级别的锁，即排他锁，而不应该先申请共享锁，从而造成锁冲突，甚至死锁；　　

4）在REPEATABLE-READ隔离级别下，如果两个线程同时对相同条件记录用SELECT...FOR UPDATE加排他锁，在没有符合该条件记录情况下，两个线程都会加锁成功。程序发现记录尚不存在，就试图插入一条记录，如果两个线程都这么做，就会出现死锁，这种情况下，将隔离级别READ COMMITTED就可以避免问题；　　

5）当隔离级别为READ COMMITTED时，如果两个线程都先执行SELECT...FOR UPDATE，判断是否存在符合条件的记录，如果没有，就插入记录。此时，只有一个线程能插入成功，另外一个线程就会出现锁等待，当第一个线程提交后，第二个线程会因为主键冲突出错，但虽然这个线程出错了，却会获得一个排他锁，这时如果有第三个线程又来申请排它锁，也会出现死锁。

6）如果出现了死锁，可以使用上面的检查锁信息的SQL命令来确定最后一个死锁产生的原因。返回结果中国包括死锁相关的事务的详细信息，如引发死锁的SQL语句，事务已经获得的锁，正在等待什么锁，以及被回滚的事务等。据此可以分析死锁产生的原因和改进措施。

网站排名文章编辑技巧之七条SEO优化建议

Mon, 13 Apr 2020 22:39:10 +0800

SEO优化可能是老生常谈的问题了，想要做好网站的排名和收录，不得不说到网站内容中原创文章的重要性了。那么本文将围绕文章编辑技巧，列出几点有助于SEO优化的建议，仅供参考。希望对大家有所帮助~

1、文章的原创性
1)修改文章的标题，尽可能的选择新颖的，符合用户搜索习惯的标题。
2)修改首段内容或自己动手来添加首段文字信息。
3)文章中图片ALT属性的修改和添加。
4)在不影响阅读的情况下，适当的调整文章的段落顺序。
5)可以在末段加上一小段含有关键字的总结。

2、文章标题规范
1)对于转载的文章，在修改标题前，要确定当前文章最主要的关键词。
2)尽量将主关键安排在标题的前半部分。
3)文章标题应该简洁明了，以不超过15个汉字为宜，最长不得超过30个汉字。
4)由两部分组成的标题，中间可以用空格隔开，而不是其他符号。
5)如果文章内含有图片，可以在标题后附上(图)。

3、页面关键词选择规范
1)页面关键词只涉及到当前页面的内容，而不去涉及整个网站、所在频道等内容。
2)在关键词选择上，可以采取具体关键词+主关键词的形式，在某种情况下，标题也可以作为一个比较具体的关键词。
3)站在受众的角度考虑，结合用户的一些搜索习惯，来填写适当的关键词。
4)不同的关键词一定要用英文下的逗号隔开，关键词以3-5个为宜。

4、文章摘要规范
1)文章的摘要里必须包含页面关键词，多个页面的关键词要尽量全部在摘要中出现。
2)文章摘要要尽可能的重复页面关键词，但不要堆砌，一般来说重复三遍没有问题，重复关键词也有一定的技巧。
3)文章的摘要没有严格的字数要求，两句话三句话就可以，以80-100字为宜。
4)文章的摘要不是关键词的堆砌或罗列，而是概括了文章的主要内容，从而引导用户继续读下去。
5)文章的内容不易过长，如果过长可截为几篇文章，并在文章内建立起阅读指示。

5、文本规范
1)文章的首段一定要出现页面关键词，并且可以把首段出现的部分页面关键词加粗。
2)文章的末段也要出现页面关键词，尽可能的将页面关键词安排在文章的结尾部分。
3)页面关键词在文章的正文中要有一定的比例分布，也就是关键字密度，一般情况下是2-8%，在不影响阅读的前提下，一些词都可以用页面关键词来代替。
4)页面关键词在一篇文章中表达要统一。

6、图片的规范
1)所有上传的图片都应该加上ALT属性，并且ALT属性必须符合图片本身的内容，同时也要尽可能的包含页面关键词。
2)每副图片下都应该配有适当的文字说明，并且文字说明中要包含页面关键词。
3)对于含有文本的文章来说，尽量不要在文章开头就显示图片。

7、内外链接的建设
要想收录后排名好，除了做好以上工作，还要针对热点关键词做好内链建设。所谓内链建设，就是在文章中所涉及的核心关键词上，加上该文章的超链。比如这篇文章是关于SEO编辑技巧的，那么就把SEO这几个词都加上该篇文章的URL，这样不但利于百度和其他搜索引擎的收录，也能帮助该文章获得更好的排名。当然条件允许，单独给文章做一些外部链接也是非常必要的，质量好的外链能够帮助搜索引擎更快更好的收录你的文章。

OpenTSDB/HBase的调优过程整理

Sun, 12 Apr 2020 01:19:06 +0800

背景

过年前，寂寞哥给我三台机器，说搞个新的openTSDB集群。机器硬件是8核16G内存、3个146G磁盘做数据盘。

我说这太抠了，寂寞哥说之前的TSDB集群运行了两年，4台同样配置的机器，目前hdfs才用了40%，所以前期先用着这三台机器，不够再加。

于是我只好默默地搭好了CDH5、openTSDB(2.1版本，请注意此版本号)、bosun，并在20台左右的机器上部署了scollector用来测试，然后将dfs.replication改为了2，一切正常。

过完年回来后，开始批量在主要业务机器上部署scollector，大概增加到了160台左右。运行了一个星期后，正在添加各种grafana dashboard的时候，就开始发现各种异常了。

这篇文章主要是总结了处理openTSDB各种状况的过程。需要注意的是，这是个持续的过程，中间修改了非常多的参数，有些问题是做了某项修改后，有很明显的改善，而有些问题的解决其实回头看的时候并不能知道究竟是哪些修改解决了问题，也还没有时间重新去修改验证。因此，本文并不能作为一份解决问题的FAQ文档，纯当本人处理问题的记录罢了。

打开文件数

首先是发现了无法打开master:4242页面了，查看了openTSDB的日志，很显眼的too many open file，于是检查了ulimit，还是默认的1024，这肯定不够用的。需要修改系统的资源限制：

首先是/etc/security/limits.conf

# 添加 * soft nofile 102400 * hard nofile 102400

然后是/etc/profile

# 文件末尾添加 ulimit -HSn 102400

重新登录，重启openTSDB，然后检查进程的打开文件数：

# cat /proc/$(ps -ef | /bin/grep 'opentsd[b]' | awk '{print $2}')/limits | /bin/grep 'open files' Max open files 102400 102400 files

修改已生效，打开文件数的问题解决了。

内核参数

接着没过1小时，就出现了查询非常久都出不来的情况，于是就注意观察openTSDB的打开文件数，然而只有1500左右，怀疑可能是并发数和backlog的问题，检查了连接数以及当前的内核参数，发现此时连接数并没有超过内核设置。不过本着尽量排除影响的原则，还是改大了这两个内核参数：

net.ipv4.tcp_max_syn_backlog = 16384 net.core.somaxconn = 65535

没有什么新的线索的情况下，只好又重启了TSDB。重启后又恢复正常了。于是用watch命令持续盯着openTSDB的连接数，一边用grafana每30秒刷新页面。发现正常情况时，连接数大概是900以下，而出现问题时(grafana刷不出来图时)，连接数突然就上升到1200以上，然后1分钟内蹦到了2900。赶紧使用netstat看下是什么状态的连接数上涨了，发现是TIME-WAIT。检查net.ipv4.tcp_tw_reuse已经是1了，然后这天由于有别的事情要忙，就暂时没再看了。

regionserver java堆栈大小

第二天早上的时候发现又是grafana刷新不出图，后来上CDH管理页面才发现是其中有一个regionserver(tsdb3)挂了：经大数据组大神提醒，多半是GC导致regionserver挂了。查看果然有个小时级别的GC：查看了HBase Regionserver java堆栈大小，原来才设置为2.44G。请教了大神，说是因为我部署的这个CDH集群，除了HBase之外还有其他的其实对于openTSDB没有用的Hive、Hue、Oozie、Sqoop2等，所以CDH会根据角色的情况分配java堆栈大小，但是我们完全可以将这些没有用到的服务关掉，手动将HBase Regionserver java堆栈大小设置为物理内存的一半，也就是8G。

改完配置重启了HBase，貌似一切又正常了。而且，由于有更重要的问题要处理，因此就先暂时放一放了。

HBase表压缩

那件更重要的事情，就是磁盘空间用得太快了。才160台机器一星期的数据，磁盘空间就才90%下降到80%，我一开始觉得不可能，之前的旧集群，用了两年才用了40%，新的怎么一星期就用了10%呢，这么下去难道只能用10个星期？后来看了下CDH的图，每秒datanode写入都有1M左右，146G的硬盘前途堪忧啊！原来是旧的tcollector是自己写的收集脚本，一台机器收集的metric平均才30来个，而scollector不算自己写的外部脚本，本身就提供了上百个metric，再加上自己写的外部收集脚本，这么下来两者的数据根本就不是一个数量级了。

想起之前在初始化TSDB的HBase的时候，没有采用压缩：

env COMPRESSION=NONE HBASE_HOME=/usr/lib/hbase /usr/share/opentsdb/tools/create_table.sh

不知道现在还能不能开启表压缩，赶紧去请教大神。大神甩给我一个文档：

# hbase shell
# 查看表是否启用压缩
# describe "tsdb"  
# 暂停对外服务，将指定的HBase表disable
# disable "tsdb"  
# 更改压缩类型
# alter 'tsdb', NAME => 't', COMPRESSION => 'gz'  
# 重新启用表
# enable "tsdb"
# 确认是否开启了压缩
# describe "tsdb"
# 使压缩在全站生效
# major_compact "tsdb"
# disable "tsdb"
# 更改压缩类型
# alter 'tsdb', NAME => 't', COMPRESSION => 'NONE'
# 重新启用表
# enable "tsdb"
# 确认是否开启了压缩
# describe "tsdb"
# 使压缩在全站生效
# major_compact "tsdb"

需要注意的是，千万不要在表繁忙期间执行大合并操作

我说，用gz压缩是不是对性能影响大啊，不是很多地方都在用snappy吗？大神解释说，gz是压缩比最高的，只对CPU资源有所损耗；按你这个集群的情况，CPU还有负载，都还是比较闲的，加上磁盘资源又这么紧张，最好还是用gz吧，如果有影响，再改为snappy呗。

我想也是，于是就开启了表压缩，磁盘空间问题解决了：从上图可以很明显地看到开启压缩前后的对比。

HBase memstore flush and store files compaction

解决完压缩问题后，回头来再看openTSDB查询偶尔没有及时响应的问题。通过查看bosun的Errors页面，经常会出现net/http: request canceled的报错，这是因为我设置了bosun每分钟检查一次某些metric作为报警的来源，这些报错是因为读取数据时候超时了，那么应该重点看下openTSDB为何反应慢。看了下TSDB的日志，并没有发现什么异常，于是把目光集中在了HBase上。

Google了一下tsdb hbase performance，发现了这篇文章，里面的这张图(以下简称为cycle图)总结得很好：
那么HBase反应慢，应该是这两种情况：

1->8->9
1->2->3->4->5

可以看到memstore flush很明显在这张图中处于一个核心地位，那么减少memstore flush是否可以改善呢？于是将hbase.hregion.memstore.flush.size从默认的128M改大为1G。

CDH中的hbase.hregion.memstore.flush.size作用解释如下：如memstore大小超过此值（字节数），Memstore将刷新到磁盘。通过运行由hbase.server.thread.wakefrequency指定的频率的线程检查此值。

但是这样修改后有个很严重的副作用：GC时间更长了(箭头指向为修改前后的比较)：后来就把这个参数恢复为128M这个默认值了。

至于compaction方面的参数，看着解释貌似不好修改，于是就没有改了：

HBase GC 调优

再来看下GC的时间规律，发现都是集中在一个小时的0分左右。查看了scollector自带的hbase.region.gc.CollectionTime这个指标值，确实在一个小时的0分左右就有一个GC的高峰：(红线为ParNew，而蓝线为ConcurrentMarkSweep)大神一看，说每小时开始的时候集群网络IO会飙高，问我TSDB这时候在干什么。于是我在发生问题的时候用iftop -NP检查网络IO，发现基本上都是60020和50010端口之间的流量：看不出来openTSDB在做什么，之前用的TSDB都不用怎么改配置直接用默认值的。

大神沉思下，说我还有办法可以优化下GC时间，优化调整的目的应该是削平GC的波峰，让整个系统的正常服务时间最大化。大神在HBase RegionServer 的 Java 配置选项加上以下参数：

-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/data/logs/gc.log

接着修改了以下HBase参数：

HBase Server 线程唤醒步骤 (hbase.server.thread.wakefrequency)：该值决定了Hbase Memstore刷新的检测频率，该值默认值为10s，在数据高峰时，每秒写入的数据达到20M左右，调整该值到5s，来帮助尽量使得MemStore的值不超过128M。
RegionServer 中所有 Memstore 的最大大小 (hbase.regionserver.global.memstore.upperLimit)：该值是小数形式的百分比，默认为0.4，该值与Hfile缓存块大小的总和不能超过0.8，不然会造成HBase启动失败，其目的是为了在Memstore占用的内存达到Java堆栈的该百分比时强制执行刷新数据到磁盘的操作，这里我们将Memstore的百分比设置为0.5，目的是为了尽量避免强制刷新。还有一个最小大小的值(hbase.regionserver.global.memstore.lowerLimit)为0.38，表示要刷新到0.38才结束刷新，未做修改，后续可以调整。
HFile 块缓存大小 (hfile.block.cache.size)：该值默认值为0.4，调整为0表示Hbase的磁盘写入不使用内存缓存，测试发现调整为0后性能有一定的退化，尤其是在数据刷新操作的过程中消耗的时间有所上升，这里我们把该值调整为0.3(因为hbase.regionserver.global.memstore.upperLimit已改为了0.5)。
HStore 阻塞存储文件 (hbase.hstore.blockingStoreFiles)：该值默认为10，如在任意 HStore 中有超过此数量的 HStoreFiles，则会阻止对此 HRegion 的更新，直到完成压缩或直到超过为 'hbase.hstore.blockingWaitTime' 指定的值。将该值改大到100，就是为了减少cycle图中的第9步。

然后根据GC打印日志的分析，还修改了HBase RegionServer的Java配置选项：

默认情况下Hbase在新代中采用的GC方式是UseParNewGC，在老代中采用的GC方式为UseConcMarkSweepGC，这两种GC方法都支持多线程的方法，CMS的GC耗费的时间比新代中的GC长，同时如果内存占满还会触发Full GC，我们的优化方向是让GC尽量在新代中进行，通过GC日志发现新代的内存大小只有600M，而总的Java堆栈大小为8G，官方的推荐是新代内存占用为总堆栈的3/8，于是在这里增加参数-Xmn3000m，来扩大新代的大小。

经过大神的一番调优后，可以明显看到GC时间明显下降了：

文件系统读写优化

考虑到是写入数据太多，查看系统的磁盘所有写所消耗的时间确实都比较高，尝试了以下优化方案：(以sdb为例)

ext4挂载参数：

mount -o remount,noatime,nodelalloc,barrier=0 /dev/sdb1

调度电梯算法改为deadline

echo "deadline" > /sys/block/sdb/queue/scheduler

开启文件系统的预读缓存

blockdev --setra 32768 /dev/sdb

经过一番修改后，linux.disk.msec_write(Total number of ms spent by all writes) 这个指标值大幅下降，但不清楚是GC调优还是文件系统读写优化的效果，但根据经验，ext4性能相比ext3是有所回退的，这么改动应该是有效果的，但barrier=0这个挂载参数需谨慎使用。

增加机器/hotspotting

虽然GC时间下降了，但是还是在挺高的数值上，而且bosun的Errors还是偶尔出现，为此我增加了bosun的Errors监控指标，通过bosun的api，专门监控bosun出现request canceled的情况：可以看到出现此类错误的时候，基本都是在每个小时的0分附近。

反反复复试过了很多HBase调优之后，依然有偶尔出现request canceled的问题，且每到整点左右时，用grafana查询也是要1到2分钟才将一个dashboard刷新完，就是说1/30的时间是不可服务的。

既然之前搜到的那篇文章中有提到最好的方式是增加机器了，刚好旧的TSDB集群刚好也压缩过了，用两个regionserver就可以了，于是将剩下的第三台机器加到了新的TSDB集群中来。

新的regioserver加进来后，发现情况还是不是太好，依旧是每到一小时的0分附近就是各种slow response。查看了master:60010页面，各regionserver之间的request分配并不平均，通常是新加入的regionserver只是旧的两台的30%不到，这可能会导致大量的写入集中在两台旧的regionserver上，因而造成slow response。所以先尝试手动平衡下region。

比如从master:60010上看数据，发现这个region的request比较多，因此决定将它手动迁移到新的tsdb4(tsdb4.domain.com,60020,1457011734982)

tsdb,\x00\x00\xF5V\xA6\x9A\xE0\x00\x00\x01\x00\x00\xDA\x00\x00\x13\x00\x00c\x00\x00\x15\x00\x00\xDE,1454242184814.29987604fab49d4fd4a0313c6cf3b1b6.

操作如下：

# hbase shell move "29987604fab49d4fd4a0313c6cf3b1b6" "tsdb4.domain.com,60020,1457011734982" balance_switch false

记得关闭balance，否则过5分钟，被移动的region又自动回来了

可以看到修改完后，3个regionserver的writeRequestCount比之前平均多了:

增加内存

每到整点就是各种slow response的问题依然存在。没办法之下只好给regionserver增加内存进行测试了。将3台regionserver的内存都增加到了32G，然后将java堆栈大小改为16G。

其他优化

主要参考了这个slide和这个slide

另外看到bosun的Errors里还出现了10000 RPCs waiting on ... to come back online，怀疑可能是处理程序计数不足，于是调大了这两个参数：

最终解？TSDB compaction

各种方法都试过的情况下，还是出现这个“每到整点左右就是各种slow response的问题”。

既然系统、hadoop、HBase方面都调整过了，最后只能找openTSDB和bosun下手了。看到scollector已经提供了相当多的tsd指标值，于是增加了一个TSDB的grafana dashboard把所有的相关指标值都显示出来，看看每个小时0分的时候是否有些蛛丝马迹可循。

最明显的一个指标值就是tsd.hbase.rpcs，每到整点的时候才出现这些delete、get操作，平时都是0，那么100%可以确定这些操作是有关联的：

直接上Google搜tsdb delete，结果都是问怎么从TSDB中删除数据的。

回过头来再看其他的指标值，发现tsd.compaction.count也是在整点的时候特别高：需要注意的是TSDB的compaction和HBase的compaction其实不是同一个概念。

然后用tsdb compaction作为关键词一搜，出来了官网的文档，仔细看下这一段：

是不是很符合我们的情况，确实是compaction在前而delete在后。原来是TSDB在每小时整点的时候将上个小时的数据读出来(get)，然后compact成一个row，写入(put)到HBase，然后删除(delete)原始数据，所以我们看整点时的RPC请求，这些操作都会出现个凸起。

接着在这个链接(貌似都是小集群容易出现这个问题)里看到开发者的讨论：

于是看下openTSDB的配置文档，果然发现了相关配置：都是在openTSDB-2.2才新增的配置，赶紧升级了openTSDB。

那么将tsdb的compaction给关闭了有什么副作用呢？这个链接中开发者解释了有两点坏处：

磁盘使用率会增加5到10倍；
读操作会变慢。

这两点显然都是不可取的，而采用修改compaction间隔等效果并不明显，最后采用了tsd.storage.enable_appends = true的方式，终于将此问题解决了：

看下修改前后的性能比较：GC时间下降明显。

memstore变化平缓多了。

slow put 也不再出现了。

在整点的时候经常出现的request cancle不再出现了，整点时使用grafana也不会出现转圈圈到timeout的情况了。

不过值得注意的是，磁盘容量也有所下降(bosun图的时间是UTC时区)：

经验总结

整理信息的时候偶然Google发现了这篇2014年的文章，其实是一样的问题，这次虽然经历了很多波折，但是也是一个难得的学习机会。虽然作为运维，我们能接触到大量优秀的开源产品，但有多少是能仔细看完一个开源产品的文档的？一个软件，不同的情景下面就有不同的表现，不能一概而论。直到遇到坑才去填，明显是本末倒置的行为，以后要戒掉这种浮躁的心态，同一份配置不要以为之前没有问题就能一直用。

HBase数据压缩编码探索

Sun, 12 Apr 2020 01:18:29 +0800

摘要：本文主要介绍了hbase对数据压缩，编码的支持，以及云hbase在社区基础上对数据压缩率和访问速度上了进行的改进。

前言

你可曾遇到这种需求，只有几百qps的冷数据缓存，却因为存储水位要浪费几十台服务器？你可曾遇到这种需求，几百G的表，必须纯cache命中，性能才能满足业务需求？你可曾遇到，几十M的小表，由于qps过高，必须不停的split，balance，利用多台服务器来抗热点？
面对繁杂的场景，Ali-HBase团队一直致力于为业务提供更多的选择和更低的成本。本文主要介绍了hbase目前两种提高压缩率的主要方法：压缩和DataBlockEncoding。

无损压缩:更小，更快，更省资源

通用压缩作为数据库解决存储的重要手段，通常数据库都存在数据块的概念，针对每个块做压缩和解压。块越大，压缩率越高，scan throughput增加；块越小，随机读IO压力较小，读latency越小。作为一种Tradeoff，线上hbase通常采用64K块大小，在cache中不做压缩，仅在落盘和读盘时做压缩和解压操作。

开源hbase通常使用的LZO压缩或者Snappy压缩。这两种压缩的共同特点是都追求较高的压缩解压速度，并实现合理的数据压缩率。然而，随着业务的快速增涨，越来越多的业务因为因为存储水位问题而扩容。hbase针对这一情况，采用了基于跨集群分区恢复技术的副本数优化、机型升级等方法，但依然无法满足存储量的快速膨胀，因此我们一直致力于寻找压缩更高的压缩方式。

新压缩（zstd、lz4）上线

Zstandard（缩写为Zstd）是一种新的无损压缩算法，旨在提供快速压缩，并实现高压缩比。它既不像LZMA和ZPAQ那样追求尽可能高的压缩比，也不像LZ4那样追求极致的压缩速度。这种算法的压缩速度超过200MB/s, 解压速度超过400MB/s（实验室数据），基本可以满足目前hbase对吞吐量的需求。经验证，Zstd的数据压缩率相对于Lzo基本可以提高25%-30%，对于存储型业务，这就意味着三分之一到四分之一的的成本减少。

而在另一种情况下，部分表存储量较小，但qps大，对rt要求极高。针对这种场景，我们引入了lz4压缩，其解压速度在部分场景下可以达到lzo的两倍以上。一旦读操作落盘需要解压缩，lz4解压的rt和cpu开销都明显小于lzo压缩。

我们先通过一张图片直观的展示各种压缩算法的性能:

以线上几种典型数据场景为例，看看几种压缩的实际压缩率和单核解压速度（以下数据均来自于实际应用）

业务类型	无压缩表大小	LZO（压缩率/解压速度MB/s）	ZSTD（压缩率/解压速度MB/s）	LZ4（压缩率/解压速度MB/s）
监控类	419.75T	5.82/372	13.09/256	5.19/463.8
日志类	77.26T	4.11/333	6.0/287	4.16/ 496.1
风控类	147.83T	4.29/297.7	5.93/270	4.19/441.38
消费类	108.04T	5.93/316.8	10.51/288.3	5.55/520.3

目前，2017年双11，ZSTD已经在线上全面铺开，已累计优化存储数PB。LZ4也已经在部分读要求较高业务上线。
下图为某监控类应用zstd压缩算法后，集群整体存储量的下降情况。数据量由100+T减少到75T。

编码技术：针对结构化数据的即查即解压

hbase作为一种schema free的数据库，相当于传统的关系型数据库更加灵活，用户无需设计好表的结构，也可以在同一张表内写入不同schema的数据。然而，由于缺少数据结构的支持，hbase需要很多额外的数据结构来标注长度信息，且无法针对不同的数据类型采用不同的压缩方式。针对这一问题，hbase提出了编码功能，用来降低存储开销。由于编码对cpu开销较小，且效果较好，通常cache中也会开启编码功能。

旧DIFF Encoding介绍

hbase很早就支持了DataBlockEncoding，也就是是通过减少hbase keyvalue中重复的部分来压缩数据。以线上最常见的DIFF算法为例，某kv压缩之后的结果：

一个字节的flag（这个flag的作用后面解释）
如果和上个KV的键长不一样，则写入1~5个字节的长度
如果和上个KV的值长不一样，则写入1~5个字节的长度
记录和上个KV键相同的前缀长度，1~5个字节
非前缀部分的row key
如果是第一条KV,写入列族名
非前缀部分的的列名
写入1~8字节的timestamp或者与上个KV的timestamp的差(是原值还是写与上个KV的差，取决于哪个字节更小)
如果和上个KV的type不一样，则写入1字节的type（Put，Delete）
Value内容

那么在解压缩时，怎么判断和上个KV的键长是否一样，值长是否一样，写入的时间戳究竟是是原值还是差值呢？这些都是通过最早写入的1个字节的flag来实现的，
这个字节中的8位bit，含义是：

第0位，如果为1，键长与上个kv相等
第1位，如果为1，值长与上个kv相等
第2位，如果为1，type与上个kv一样
第3位，如果为1，则写入的timestamp是差值，否则为原值
第456位，这3位组合起来的值（能表示0~7），表示写入的时间戳的长度
第7位，如果为1，表示写入的timestamp差值为负数，取了绝对值。

DIFF 编码之后，对某个文件的seek包含以下两步：

通过index key找到对应的datablock
从第一个完整KV开始，顺序查找，不断decode下一个kv，直到找到目标kv为止。

DIFF encoding对小kv场景使用效果较好，可以减少2-5倍的数据量。

新Indexable Delta Encoding上线

从性能角度考虑，hbase通常需要将Meta信息装载进block cache。如果将block大小较小，Meta信息较多，会出现Meta无法完全装入Cache的情况, 性能下降。如果block大小较大，DIFF Encoding顺序查询的性能会成为随机读的性能瓶颈。针对这一情况，我们开发了Indexable Delta Encoding，在block内部也可以通过索引进行快速查询，seek性能有了较大提高。Indexable Delta Encoding原理如图所示：

在通过BlockIndex找到对应的数据块后，我们从数据块末尾找到每个完整KV的offset，并利用二分查找快速定位到符合查询条件的完整kv，再顺序decode每一个Diff kv，直到找到目标kv位置。

通过Indexable Delta Encoding， HFile的随机seek性能相对于使用之前翻了一倍，以64K block为例，在全cache命中的随机Get场景下，相对于Diff encoding rt下降50%，但存储开销仅仅提高3-5%。Indexable Delta Encoding目前已在线上多个场景应用，经受了双十一的考验，整体平均读rt减少10%-15%。

云端使用

阿里HBase目前已经在阿里云提供商业化服务，任何有需求的用户都可以在阿里云端使用深入改进的、一站式的HBase服务。云HBase版本与自建HBase相比在运维、可靠性、性能、稳定性、安全、成本等方面均有很多的改进，更多内容欢迎大家关注 https://www.aliyun.com/product/hbase

HDFS的元数据文件fsimage和编辑日志edits

Sun, 12 Apr 2020 01:17:17 +0800

在HDFS中，fsimage和eidts是NameNode两个非常重要的文件。

其中，fsimage是HDFS文件系统存于硬盘中的元数据检查点，里面记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息；而edits保存了自最后一次检查点之后所有针对HDFS文件系统的操作，比如：增加文件、重命名文件、删除目录等等。

在NameNode启动时候，会先将fsimage中的文件系统元数据信息加载到内存，然后根据eidts中的记录将内存中的元数据同步至最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。

这两种文件存放在${dfs.namenode.name.dir}/current/目录下，文件名以edits_和fsimage_命名，该目录为NameNode上的本地目录。为了保证这两种元数据文件的高可用性，一般的做法，将dfs.namenode.name.dir设置成以逗号分隔的多个目录，这多个目录至少不要在一块磁盘上，最好放在不同的机器上，比如：挂载一个共享文件系统。

类似于数据库中的检查点，为了避免edits日志过大，在Hadoop1.X中，SecondaryNameNode会按照时间阈值（比如24小时）或者edits大小阈值（比如1G），周期性的将fsimage和edits的合并，然后将最新的fsimage推送给NameNode。而在Hadoop2.X中，这个动作是由Standby NameNode来完成。

其他更详细的关于fsimage和edits的介绍，请参考官方文档或网上资料，很多。这里主要来介绍一下如何查看这两种文件，由于这两种文件时经过序列化的，非文本的，因此无法直接查看，Hadoop2.X中，hdfs提供了查看这两种文件的工具。

HDFS查看fsimage

命令hdfs oiv用于将fsimage文件转换成其他格式的，如文本文件、XML文件。

该命令需要以下参数：

必须参数：

-i,–inputFile <arg> 输入FSImage文件.

-o,–outputFile <arg> 输出转换后的文件，如果存在，则会覆盖

可选参数：

-p,–processor <arg> 将FSImage文件转换成哪种格式： (Ls|XML|FileDistribution).默认为Ls.

-h,–help 显示帮助信息

例子1：

hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt

执行后查看more /home/Hadoop/fsimage.txt

由于未指定-p选项，默认为Ls，出来的结果和执行hadoop fs –ls –R一样。

例子2：

hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.xml -p XML

指定-p XML，将fsimage文件转换成XML格式，查看fsimage.xml

XML文件中包含了fsimage中的所有信息，比如inodeid、type、name、修改时间、权限、大小等等。

例子3：

FileDistribution是分析命名空间中文件大小的工具。为了运行该工具需要通过指定最大文件大小和段数定义一个整数范围[0,maxSize]，该整数范围根据段数分割为若干段[0, s[1], …, s[n-1], maxSize]，处理器计算有多少文件落入每个段中（[s[i-1], s[i]），大于maxSize的文件总是落入最后的段中，即s[n-1], maxSize。输出文件被格式化为由tab分隔的包含Size列和NumFiles列的表，其中Size表示段的起始，NumFiles表示文件大小落入该段的文件数量。在使用FileDistribution处理器时还需要指定该处理器的参数maxSize和step，若未指定默认为0。示例如下：

hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.fd -p FileDistribution maxSize 1000 step 5

查看结果文件fsimage.fd:

head -10 fsimage.fd 

Processed 0 inodes.
Size    	NumFiles
0       	8302
2097152 	474984
4194304 	10995
6291456 	6608
8388608 	4452
10485760        5865
12582912        4747
14680064        2965

tail -10 fsimage.fd

29725032448     1
33241956352     1
58212745216     1
58265174016     1
62084087808     1
totalFiles = 605087
totalDirectories = 100070
totalBlocks = 725265
totalSpace = 42583680916192
maxFileSize = 62083011560

下一篇文章中将介绍HDFS编辑日志edits的查看方式，请关注我的博客。

Shodan互联网上最可怕的搜索引擎

Sun, 12 Apr 2020 01:15:23 +0800

1.暗黑谷歌的由来

有这么一款搜索引擎，它一刻不停的在寻找着所有和互联网关联的PLC、摄像头、红绿灯、打印机、路由器、交换机、服务器、数据库等等各种软硬件服务设施。

它就是shodan，那么shodan到底是什么呢？怎么会有如此大的魔力？首先，Shodan 是一个搜索引擎，但它与 Google 这种搜索网址的搜索引擎不同，Shodan不是在网上搜索网址，而是直接进入互联网探索其背后的信息。

Shodan真正值得注意的能力就是能找到几乎所有和互联网相关联的东西。其中最受欢迎的搜索内容是：webcam，linksys，cisco，netgear，SCADA等等。

配合其组合参数，可以做到以下功能：

批量搜索现有漏洞主机
统计感染某木马的主机数量
批量扫描登录入口，并使用弱口令字典进行爆破
批量抓取shell
使用自己的0day打遍天下

写这篇文章是希望能够将这款工具的用途、使用方法、利用技巧进行实战应用。以便使用Shodan搜索引擎进行相关搜索，并利用Shodan的API编写Python脚本，进行批量扫描，将技术应用到渗透测试和安全攻防中，最大限度做好安全防御。

2.Shodan的工作原理

Shodan每隔一段时间就会对全球大约8亿主机进行扫描，通过对返回Banner信息的处理，识别特定主机，并进行分类储存。为了避免因政治、技术等原因导致的扫描信息误差（比如某墙或某些老美服务商对大陆羊毛党的屏蔽等），Shodan的扫描主机至少遍布在全球的8个国家和地区。

当我们发出一条搜索请求，其背后的逻辑是这样的

那Banner是什么呢？
在探测端口时数据包里存在Banner信息

HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Sat, 18 May 2019 06:56:30 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive

这是一个普通的HTTP Banner，可以从上获知服务端使用的是1.16.0版本的nginx。

西门子S7-300工控协议的Banner：

Reserved for operating system: 
Serial number of memory card: SD D45C6213
Location designation of a module: 
Module type: CPU 315-2 PN/DP
PLC name: S7-300 station_1
Plant identification: 
OEM ID of a module: 
Module name: Vestas V27 AS+PITCH
Serial number of module: 18382

其中能获取更多的信息。

Shodan的Banner处理机制比较复杂，我们这里只需要知道探测端口是来往的数据包中包含Banner，并包含了主机的部分信息即可。

3.Shodan的查询指南

基本查询

Shodan的参数有很多，这里只介绍简单几种。

hostname："主机或域名"   如 hostname:"google''
port："端口或服务" 如 port:"80"
ip : "ip地址" 如 ip : "114.114.114.114"
net："IP地址或子网"如 net:"111.112.113.110.0/24"
vuln :指定漏洞的cve如 vuln:CVE-2015-8869
但是这个命令最好搭配起来使用，如 country:CN vuln:CVE-2018-0610
os :"操作系统" 如 os:"debian"
isp："ISP供应商" 如 isp:"China Telecom"
product："操作系统/软件/平台" 如 product:"nginx"
version："软件版本" 如 version:"1.16.0"
geo："经纬度" 如 geo:"38°53.707′,77°02.182"
country`："国家" 如 country:"China"
city："城市"  如 city:"shanghai"
org："组织或公司" 如org:"google"
before/after："日/月/年" 如 before:"11/05/2019" after:"11/05/2019"
asn : "自治系统号码" 如 asn:"TS1826"

关联查询

搜索上海开放8080端口的主机

Apache city:"shanghai" port:"8080"

搜索IP段为23.238.20.0/24的所有linux主机

os:"linux"  net:"23.238.20.0/24"

Shodan参数还有很多，前提是注册或付费用户：

更多信息使用时可以查看中文说明手册,可点击前往。

其他功能

Shodan 不仅可以查找网络设备，它还具有其他相当不错的功能。
Exploits：每次查询完后，点击页面上的 “Exploits” 按钮，Shodan 就会帮我们查找针对不同平台、不同类型可利用的 exploits。当然也可以通过直接访问网址来自行搜索：https://exploits.shodan.io/welcome；

地图：每次查询完后，点击页面上的 “Maps” 按钮，Shodan 会将查询结果可视化的展示在地图当中；

报表：每次查询完后，点击页面上的 “Create Report” 按钮，Shodan 就会帮我们生成一份精美的报表，这是天天要写文档兄弟的一大好帮手啊；

4.命令行下的Shodan

Shodan 是由官方提供的 Python 库的，项目位于：https://github.com/achillean/shodan-python

安装

pip install shodan
或者
git clone https://github.com/achillean/shodan-python.git && cd shodan-python
python setup.py install

本文以debian为例，安装完后我们先看下帮助信息：

root@debian:~# shodan -h
Usage: shodan [OPTIONS] COMMAND [ARGS]...
Options:
  -h, --help  Show this message and exit.
Commands:
  alert       Manage the network alerts for your account  # 管理账户的网络提示
  convert     Convert the given input data file into a...  # 转换输入文件
  count       Returns the number of results for a search  # 返回查询结果数量
  download    Download search results and save them in a...  # 下载查询结果到文件
  honeyscore  Check whether the IP is a honeypot or not.  # 检查 IP 是否为蜜罐
  host        View all available information for an IP...  # 显示一个 IP 所有可用的详细信息
  info        Shows general information about your account  # 显示账户的一般信息
  init        Initialize the Shodan command-line  # 初始化命令行
  myip        Print your external IP address  # 输出用户当前公网IP
  parse       Extract information out of compressed JSON...  # 解析提取压缩的JSON信息，即使用download下载的数据
  scan        Scan an IP/ netblock using Shodan.  # 使用 Shodan 扫描一个IP或者网段
  search      Search the Shodan database  # 查询 Shodan 数据库
  stats       Provide summary information about a search...  # 提供搜索结果的概要信息
  stream      Stream data in real-time.  # 实时显示流数据

常用示例

init
初始化命令行工具。

root@debian:~# shodan init [API_Key] #请使用自己账号的API Key
Successfully initialized

count
返回查询的结果数量。

root@debian:~# shodan count nginx 1.16.0
81840

download
将搜索结果下载到一个文件中，文件中的每一行都是 JSON 格式存储的目标 banner 信息。默认情况下，该命令只会下载10条结果，如果想下载更多结果需要增加 --limit 参数。

root@debian:~# shodan download nginx 1.16.0 --limit 100
Search query:                   1.16.0
Total number of results:        82058
Query credits left:             0
Output file:                    nginx.json.gz
  [###---------------------------------]   10%  00:00:31
Notice: fewer results were saved than requested
Saved 100 results into file nginx.json.gz

parse
我们可以使用 parse 来解析之前下载数据，它可以帮助我们过滤出自己感兴趣的内容，也可以用来将下载的数据格式从 JSON 转换成 CSV 等等其他格式，当然更可以用作传递给其他处理脚本的管道。例如，我们想将上面下载的数据以CSV格式输出IP地址、端口号和组织名称：

root@debian:~# shodan parse --fields ip_str,port,org --separator , nginx.json.gz 
23.239.25.203,80,Linode
85.209.0.11,80,
93.119.176.67,80,0 7 I N T E R N E T . R O
149.202.169.98,80,OVH SAS
138.68.232.31,80,Digital Ocean
195.70.4.97,80,DFI Service SA
47.101.70.248,80,Hangzhou Alibaba Advertising Co.,Ltd.
42.159.196.244,80,Shanghai Blue Cloud Technology Co.,Ltd
142.4.17.163,80,Unified Layer
80.69.173.48,80,UpCloud Cloud Servers
39.100.85.208,80,Hangzhou Alibaba Advertising Co.,Ltd.
156.67.92.27,80,NETRONIK sp. z o.o.
193.112.97.173,80,Tencent cloud computing
47.107.139.162,80,Hangzhou Alibaba Advertising Co.,Ltd.
129.121.192.115,8080,Nexcess.net L.L.C.
162.144.69.141,80,Unified Layer
164.138.216.162,80,SuperHosting.BG Ltd.
......................................... #此处省略N行。

host
查看指定主机的相关信息，如地理位置信息，开放端口，甚至是否存在某些漏洞等信息。

root@debian:~# shodan host 42.159.196.244
42.159.196.244
City:                    Shanghai
Country:                 China
Organization:            Shanghai Blue Cloud Technology Co.,Ltd
Updated:                 2019-05-18T08:13:44.814290
Number of open ports:    2
Vulnerabilities:         CVE-2018-15919 CVE-2017-15906

Ports:
     22/tcp OpenSSH (7.4)
     80/tcp nginx (1.16.0)

search
直接将查询结果展示在命令行中，默认情况下只显示IP、端口号、主机名和HTTP数据。当然我们也可以通过使用 –fields 来自定义显示内容，例如，我们只显示IP、端口号、组织名称和主机名：

root@debian:~# shodan search --fields ip_str,port,org,hostnames nginx 1.16.0
162.144.138.155 80      Unified Layer   server.vitaathletics.com        
85.209.0.11     80                      
162.144.196.17  80      Unified Layer   server.yen.hlv.mybluehost.me    
138.68.232.31   80      Digital Ocean   nexo-host.com.ve        
212.22.64.245   80      LLC Quadronet   timri.ru        
38.143.213.84   80      Cogent Communications           
212.33.243.127  80      JSC ER-Telecom Holding  212x33x243x127.static-business.perm.ertelecom.ru        
64.247.179.214  80      SoftwareWorks Group     useast33.myserverhosts.com      
120.31.140.112  81      FoShan RuiJiang Science and Tech        ns1.eflydns.net;ns2.eflydns.net 
80.69.173.48    80      UpCloud Cloud Servers   80-69-173-48.fi-hel1.upcloud.host       
85.209.0.76     80                      
156.67.92.27    80      NETRONIK sp. z o.o.             
162.144.201.223 80      Unified Layer   server.formacolorytextura.com   
193.112.97.173  80      Tencent cloud computing         
47.110.78.125   80      Hangzhou Alibaba Advertising Co.,Ltd.           
129.121.192.115 8080    Nexcess.net L.L.C.      ip-129-121-192-115.local  
......................................... #此处省略N行。

5.代码中使用 Shodan 库

上面介绍了 shodan 库的用法，这里描述下如何在python代码中使用 shodan 库，首先需要初始化连接 API，代码如下：

import shodan
SHODAN_API_KEY = "API_Key"
api = shodan.Shodan(SHODAN_API_KEY)

随后，我们就可以搜索数据了，示例代码片如下：

try:
    # 搜索 Shodan
    results = api.search('apache')
    # 显示结果
    print 'Results found: %s' % results['total']
    for result in results['matches']:
            print result['ip_str']
except shodan.APIError, e:
    print 'Error: %s' % e

这里 Shodan.search() 会返回类似如下格式的 JSON 数据：

{
        'total': 8669969,
        'matches': [
                {
                        'data': 'HTTP/1.0 200 OK\r\nDate: Mon, 08 Nov 2010 05:09:59 GMT\r\nSer...',
                        'hostnames': ['pl4t1n.de'],
                        'ip': 3579573318,
                        'ip_str': '89.110.147.239',
                        'os': 'FreeBSD 4.4',
                        'port': 80,
                        'timestamp': '2014-01-15T05:49:56.283713'
                },
                ...
        ]
}

常用 Shodan 库函数

shodan.Shodan(key) ：初始化连接API
Shodan.count(query, facets=None)：返回查询结果数量
Shodan.host(ip, history=False)：返回一个IP的详细信息
Shodan.ports()：返回Shodan可查询的端口号
Shodan.protocols()：返回Shodan可查询的协议
Shodan.services()：返回Shodan可查询的服务
Shodan.queries(page=1, sort=’timestamp’, order=’desc’)：查询其他用户分享的查询规则
Shodan.scan(ips, force=False)：使用Shodan进行扫描，ips可以为字符或字典类型
Shodan.search(query,page=1,limit=None,offset=None,facets=None,minify=True)：查询Shodan数据。

至此，暗黑谷歌的料理介绍完毕，如果有付费的Shodan Membership用户就可以好好的Happy了。与之相似的料理就是Tor浏览器，这是一个无痕浏览的神器。

Tor浏览器的工作原理就是将你的ip跳到一连串的的代理上，比如：把你的ip地址先从美国跳到加拿大再跳到荷兰、日本、德国、俄罗斯。。。。。下载链接：https://www.torproject.org/download/

其中所有的数据全部都是经过加密处理，目的就是为了掩藏真正访问者的ip，防止被访问者的追踪。有兴趣的可以自行研究下，这里不再过多描述，综上内容纯属攻防和白帽子技术爱好。知己知彼，方能百战不殆。加油吧，少年！未来的某一天，白帽子大牛中你可能也是其中之一。

Ambari2.7.3 和HDP3.1.0搭建Hadoop集群

Sun, 12 Apr 2020 01:03:26 +0800

一、环境及软件准备

1、集群规划

	hdp01/10.1.1.11	hdp02/10.1.1.12	hdp03/10.1.1.13	hdp04/10.1.1.14	hdp05/10.1.1.15
ambari server	是	否	否	否	否
ambari agent	是	是	是	是	是
namenode	是	是	否	否	否
datanode	否	否	是	是	是
resourcemanager	是	是	否	否	否
journalnode	是	是	是	是	是
zookeeper	是	是	是	否	否

01和02主要做管理机，03-05做数据数据节点，01-03做zookeeper集群。
主机环境为Ubuntu server18.04，主机间已经建立互信。

2、下载ambari安装包

https://docs.hortonworks.com/HDPDocuments/Ambari-2.7.3.0/bk_ambari-installation/content/ambari_repositories.html
找到对应的版本下载即可。

image.png

ps需要下载repo file,ambari.list

3、下载hdp安装包

https://docs.hortonworks.com/HDPDocuments/Ambari-2.7.3.0/bk_ambari-installation/content/hdp_31_repositories.html

image.png

ps需要下载repo file，hdp.gpl.list，hdp.list.

4、安装一台lnmp备用

选择hadoop01

https://lnmp.org/install.html

wget -c http://soft.vpser.net/lnmp/lnmp1.5.tar.gz && tar zxf lnmp1.5.tar.gz && cd lnmp1.5 && ./install.sh lnmp

选择安装mysql5.7版本用于支持ambari
开启远程访问mysql。

 mysql -u root -p
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'root'  ;
flush privileges;

5、复制下载文件

放到lnmp的默认目录下。

mkdir /home/wwwroot/default/ambari
mkdir /home/wwwroot/default/ambari/HDP-UTILS
cd /home/wwwroot/default/ambari

复制下载文件到相关目录并解压。

tar -zxvf ambari-2.7.3.0-ubuntu18.tar.gz tar -zxvf HDP-GPL-3.1.0.0-ubuntu18-gpl.tar.gz tar -zxvf HDP-3.1.0.0-ubuntu18-deb.tar.gz tar -zxvf HDP-UTILS-1.1.0.22-ubuntu18.tar.gz -C HDP-UTILS

开启nginx目录浏览
nginx.conf http { }加入

        autoindex on;   #开启nginx目录浏览功能

        autoindex_exact_size off;   #文件大小从KB开始显示

        autoindex_localtime on;

image.png

6、配置本地源

cd /etc/apt/sources.list.d
ambari.list

#VERSION_NUMBER=2.7.3.0-139#json.url = http://public-repo-1.hortonworks.com/HDP/hdp_urlinfo.jsondeb http://192.168.0.151/ambari/ambari/ubuntu18/2.7.3.0-139/ Ambari main

hdp.list

#VERSION_NUMBER=3.1.0.0-78deb http://192.168.0.151/ambari/HDP/ubuntu18/3.1.0.0-78/ HDP main
deb http://192.168.0.151/ambari/HDP-UTILS/HDP-UTILS/ubuntu18/1.1.0.22/ HDP-UTILS main

hdp.gpl.list

#VERSION_NUMBER=3.1.0.0-78deb http://192.168.0.151/ambari/HDP-GPL/ubuntu18/3.1.0.0-78/ HDP-GPL main

更新list

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com B9733A7A07513CADsudo apt-get updateapt-cache showpkg ambari-serverapt-cache showpkg ambari-agentapt-cache showpkg ambari-metrics-assembly

复制到各台主机,并在各台主机更新list。

scp /etc/apt/sources.list.d/ambari.list 192.168.0.152:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/ambari.list 192.168.0.153:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/ambari.list 192.168.0.154:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/ambari.list 192.168.0.155:/etc/apt/sources.list.d/

scp /etc/apt/sources.list.d/hdp.list 192.168.0.152:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.list 192.168.0.153:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.list 192.168.0.154:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.list 192.168.0.155:/etc/apt/sources.list.d/

scp /etc/apt/sources.list.d/hdp.gpl.list 192.168.0.152:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.gpl.list 192.168.0.153:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.gpl.list 192.168.0.154:/etc/apt/sources.list.d/
scp /etc/apt/sources.list.d/hdp.gpl.list 192.168.0.155:/etc/apt/sources.list.d/

二、安装hdp集群

1、安装ambari &hadoop01

sudo apt-get install ambari-server


Success. You can now start the database server using:    /usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start

Ver Cluster Port Status Owner    Data directory              Log file10  main    5432 down   postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode
Setting up postgresql (10+190) ...
Setting up ambari-server (2.7.3.0-139) ...
Processing triggers for systemd (237-3ubuntu10.9) ...
Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...

2、配置ambari

root@hadoop01:/home/wwwroot/default/ambari# sudo ambari-server setupUsing python  /usr/bin/python
Setup ambari-server
Checking SELinux...WARNING: Could not run /usr/sbin/sestatus: OK
Customize user account for ambari-server daemon [y/n] (n)? y
Enter user account for ambari-server daemon (root):
Adjusting ambari-server permissions and ownership...
Checking firewall status...
Checking JDK...
[1] Oracle JDK 1.8 + Java Cryptography Extension (JCE) Policy Files 8[2] Custom JDK
==============================================================================
Enter choice (1):

配置java路径即可
/usr/lib/jvm/java-8-openjdk-amd64

配置mysql

Minimum JDK version is 8 for Ambari. Skipping to setup different JDK for Ambari Server.
Checking GPL software agreement...
GPL License for LZO: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
Enable Ambari Server to download and install GPL Licensed LZO packages [y/n] (n)? 
Completing setup...
Configuring database...
Enter advanced database configuration [y/n] (n)? y
Configuring database...
==============================================================================
Choose one of the following options:[1] - PostgreSQL (Embedded)
[2] - Oracle
[3] - MySQL / MariaDB
[4] - PostgreSQL
[5] - Microsoft SQL Server (Tech Preview)
[6] - SQL Anywhere
[7] - BDB
==============================================================================
Enter choice (1): 3

配置jdbc,需要上传jdbc.bin.jar
路径如下。
/var/lib/ambari-server/resources/mysql-connector-java-5.1.47-bin.jar

Configuring ambari database...
Enter full path to custom jdbc driver: 
Configuring ambari database...
Enter full path to custom jdbc driver: /var/lib/ambari-server/resources/mysql-connector-java-5.1.47-bin.jar
Copying /var/lib/ambari-server/resources/mysql-connector-java-5.1.47-bin.jar to /usr/share/java
Configuring remote database connection properties...
WARNING: Before starting Ambari Server, you must run the following DDL directly from the database shell to create the schema: /var/lib/ambari-server/resources/Ambari-DDL-MySQL-CREATE.sql
Proceed with configuring remote database connection properties [y/n] (y)? 
Extracting system views...
....ambari-admin-2.7.3.0.139.jar

Ambari repo file contains latest json url http://public-repo-1.hortonworks.com/HDP/hdp_urlinfo.json, updating stacks repoinfos with it...Adjusting ambari-server permissions and ownership...
Ambari Server 'setup' completed successfully.

三、配置ambari

1、导入mysql库

mysql -u root -p
mysql> create database ambari;
mysql> use ambari;
mysql> source /var/lib/ambari-server/resources/Ambari-DDL-MySQL-CREATE.sql;

2、启动ambari

root@hadoop01:/home/wwwroot/default/ambari#sudo ambari-server start
Using python  /usr/bin/python
Starting ambari-server
Ambari Server running with administrator privileges.
Organizing resource files at /var/lib/ambari-server/resources...
Ambari database consistency check started...
Server PID at: /var/run/ambari-server/ambari-server.pid
Server out at: /var/log/ambari-server/ambari-server.out
Server log at: /var/log/ambari-server/ambari-server.log
Waiting for server start..................................................
Server started listening on 8080DB configs consistency check: no errors and warnings were found.
Ambari Server 'start' completed successfully.

四、安装hadoop集群

http://192.168.0.151:8080
用户名密码、admin/admin

image.png

选择本地库。
输入目录。
http://192.168.0.151/ambari/HDP/ubuntu18/3.1.0.0-78
http://192.168.0.151/ambari/HDP-UTILS/HDP-UTILS/ubuntu18/1.1.0.22/

image.png

cat ~/.ssh/id_rsa
获取ssh密钥。

image.png

其他主机出现错误，跟agent没安装上有关。
在其他主机执行
apt install ambari-agent -y

image.png

Ranger、Ranger KMS选了安装失败。取消可以成功。

image.png

SRE实战之运筹帷幄

MySQL 高可用架构 之 MHA (Centos 7.5 MySQL 5.7.18 MHA 0.58)

环境准备

秘钥互信

安装基础依赖包

安装MHA组件

安装 MHA Node组件

安装 MHA Manager 组件

建立 MySQL 一主三从

初始化 MySQL

启动MySQL 并简单配置

建立 一主三从

特别说明

MHA Manager 配置

MHA 配置文件

配置文件说明

脚本配置

自动 VIP 管理配置

配置邮件和微信报警脚本

手动 VIP 管理配置脚本

赋权

验证 MHA 相关操作

验证 ssh 信任登录是否成功

验证 mysql 主从复制是否成功

启动 MHA

手动第一次添加vip

启动

关闭

模拟宕机测试

自动切换步骤

修复后重新加入集群

node02 操作

node01 操作

manager 操作

修改前

修改后

重新启动MHA

在线进行切换

停止MHA 的manager 监控

执行切换命令

查看状态

报错解决

报错一、

滴滴开源夜莺Nightingale：企业级监控解决方案

基于 Prometheus 构建高大上的 MySQL 监控平台

概述

exporter 相关部署

监控相关指标

主从复制运行指标：

Slave_IO_Running、Slave_SQL_Running两个线程正常那么说明我们的复制集群是健康状态的。

查询吞吐量：

慢查询性能

连接数监控

缓冲池情况：

官方模板 ID

简单的告警规则

总结

详解Mysql的锁机制

一、Mysql为什么要加锁

二、锁类型

四、InnoDB存储引擎：

网站排名文章编辑技巧之七条SEO优化建议

OpenTSDB/HBase的调优过程整理

背景

打开文件数

内核参数

regionserver java堆栈大小

HBase表压缩

HBase memstore flush and store files compaction

HBase GC 调优

文件系统读写优化

增加机器/hotspotting

增加内存

其他优化

最终解？TSDB compaction

经验总结

HBase数据压缩编码探索

前言

无损压缩:更小，更快，更省资源

新压缩（zstd、lz4）上线

MySQL 高可用架构之 MHA (Centos 7.5 MySQL 5.7.18 MHA 0.58)

建立一主三从