当前位置:天才代写 > tutorial > 数据库教程 > Mysql进阶之keepalived搭建mysql高可用集群(实战)

Mysql进阶之keepalived搭建mysql高可用集群(实战)

2021-02-13 16:29 星期六 所属: 数据库教程 浏览:81

mysql主从复制 读写分离 高可用性 负载均衡群集

本实际操作是在上一节haproxy负载均衡的案例基本上再次进行的

Mysql升阶之应用haproxy构建负载均衡群集(实战演练)

试验应用的服务器连接点

主1:54.22.37.21
主2:54.22.37.18
从1:54.22.37.20
从2:54.22.37.19
平衡1(主):54.22.37.3
平衡2(备份数据):54.22.37.2
web应用所属ip:204.175.124.51
总体目标:test数据库查询

此次试验系统架构图:

mysql主从复制 读写分离 高可用性 负载均衡群集

​​​​​​​

在上一节中,主1和从1,从2的从属关系早已进行

如今要进行主1和主2的主主拷贝和主2与从1、从2的主从复制:

主1和主2的主主拷贝以下:

==================== 主2 =====================

# 建立受权客户

grant replication slave on *.* to 'repl'@'54.22.37.%' identified by "xxxxx";

# 查询binlog是不是打开

show variables like "%log_bin%";
 --------------------------------- ------- 
| Variable_name                   | Value |
 --------------------------------- ------- 
| log_bin                         | OFF   |
| log_bin_basename                |       |
| log_bin_index                   |       |
| log_bin_trust_function_creators | OFF   |
| log_bin_use_v1_row_events       | OFF   |
| sql_log_bin                     | ON    |
 --------------------------------- ------- 

# 去打开binlong,而且开启同歩日志

server-id=18
replicate-do-db=test
replicate-do-db=mysql
log-bin=/var/lib/mysql/mysql-bin
log-bin-index=/var/lib/mysql/mysql-bin.index
relay-log=/var/lib/mysql/relay-bin
relay-log-index=/var/lib/mysql/relay-bin.index
slave-skip-errors=all

# 因为主1和主2网络服务器都是以一个镜像系统下拷贝的,因此 其uuid一样,这儿要改为不一样
vi /var/lib/mysql/auto.cnf

改成

[auto]
server-uuid=5088449b-3a71-11ea-8cdd-00156239020c

PS:上边的uuid根据,select uuid()转化成

重新启动

# 导进主1的test库备份数据

set character_set_server=utf8;
create database test;
use test
source /root/test.sql

#change master偏向主库1

stop slave;
reset slave;

change master to master_host="54.22.37.21",master_user="repl",master_password="xxxxx",master_log_file="mysql-bin.000010",master_log_pos=154;    # 在主1查询show master status获得master_log_file和master_log_pos

start slave;

show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 54.22.37.21
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000010
          Read_Master_Log_Pos: 154
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: test
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 521
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 86
                  Master_UUID: dd8de4de-3e32-11e9-930e-00155d871a13
             Master_Info_File: /var/lib/mysql/master.info
.....

========================  主1 =========================
# 打开同歩日志

server-id=86
log-bin=/var/lib/mysql/mysql-bin
binlog_format=mixed

replicate-do-db=test
relay-log=/var/lib/mysql/relay-bin
relay-log-index=/var/lib/mysql/relay-bin.index
slave-skip-errors=all
log_slave_updates=1         # 会将主2同歩到主1的删改改操作记录到主1的binlog日志中

# 重新启动mysql

# 偏向主2连接点

stop slave;
reset slave;
change master to master_host="54.22.37.18",master_user="repl",master_password="xxxxx",master_log_file="mysql-bin.000003",master_log_pos=154;
start slave;

# 查询slave情况

show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 54.22.37.18
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 154
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: test
      ......
             Master_Server_Id: 18
                  Master_UUID: 5088749b-3a71-11ea-8cdd-00155d39020c
             Master_Info_File: /var/lib/mysql/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
    ......

           
那样就完成了主1和主2的主主拷贝了。

如今看2个有意思的状况:
已经知道从1,从2和主1是主从复制关联。主1和主2是主主拷贝关联。

那麼在主2往test库插进一条数据信息,主1也会插进该数据信息,可是从1和从2却沒有插进这条数据信息。
缘故以下:
根据同歩而对数据信息的变化(删改改)实际操作是不容易纪录到binlog日志中。仅有对自身所属网络服务器上作出的mysql实际操作才会被纪录到binlog日志。
因此 因为沒有纪录在binlog日志,因此 从1和从2沒有出現主2新插进的数据信息。

假如要想在主2插进的数据信息也纪录到主1的二进制日志,能够根据在主1配备一条 
log_slave_updates=1

重新启动就可以

它是在主1中设定,表明主1做为从连接点会将主连接点(主2)的删改改操作记录到binlog日志中。
那样从1,从2也会产生相对的更改。

还有一个状况:
当从1插进一条数据信息,id为10,这时主1插进一条数据信息id也为10,可是别的字段名內容不一样,这时假如设定了skip-slave-errors,那麼从1不容易出错,但也始终不变。但实际上主键早已矛盾了。

================= 配备高可用性群集 ===============
# 免费下载,缓解压力,安裝keepalived

tar -xzf keepalived-2.0.19.tar.gz
cd keepalived-2.0.19
./configure             # 假如出错,请安装gcc-c  /openssl/openssl-devel这好多个依靠
make && make install

# 对主1的keepalived配备:
vi /usr/local/etc/keepalived/keepalived.conf內容以下:

! Configuration File for keepalived

global_defs {
   router_id LVS_MASTER
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass xxxxx
    }
    virtual_ipaddress {
        54.22.37.25/24
    }
}
  
virtual_server 54.22.37.25 3306 {  

    delay_loop 6     

    lb_algo wrr     

    lb_kind DR    

    persistence_timeout 60     

    protocol TCP          
 
    real_server 54.22.37.21 3306 {  

        weight 100         
 
        notify_down /var/www/mysql_down.sh      # 表明当主1的mysql服务项目挂了,就实行mysql_down.sh脚本。这一脚本制作的每日任务是关掉本连接点的keepalived进而将虚似IP偏向转至另一个mysql一切正常的连接点;假如想干的更强一些,能够启用php脚本制作邮件发送给开发人员通告它mysql已奔溃

        TCP_CHECK {  

        connect_timeout 10  

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 3306  

        }  

    }  

}

# 这儿要留意一点很重要的:
虚似IP务必特定和主1,主2同样子网的且沒有使用过的IP,如果是已经应用的真正IP,那麼以后mysql联接这一虚似IP是连不上的。

mysql.sh 
內容以下:

#!/bin/bash
pkill keepalive

chmod u x mysql.sh

运行keepalived

keepalived -D -f /usr/local/etc/keepalived/keepalived.conf

# 对主2的keepalived的配备
将上边的配备改动好多个地区,别的生搬硬套:
a.将54.22.37.21所有改成54.22.37.18
b.将MASTER字符串数组改成BACKUP
c.将priority改为100,备份数据连接点(主2)的priority要比主连接点(主1)低最少50,不然当主1恢复正常,虚似IP還是偏向主2。

主2还要有mysql.sh

运行keepalived
keepalived -D -f /usr/local/etc/keepalived/keepalived.conf

# 用负载均衡连接点试着联接该虚似IP的mysql(由于主1和主2的mysql有在负载均衡连接点受权客户),假如联接取得成功,则高可用性配备取得成功。

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

那麼如今主连接点的高可用性就构建好啦。
下面构建负载均衡的高可用性,大家以前在web应用所属连接点应用haproxy完成负载均衡,依照高可用性的逻辑性,必须在2个连接点上安裝haproxy,另外这两个连接点也要安裝keepalived,随后这两个负载均衡连接点要另外监管2个mysql从连接点。

可是实际上,keepalived自身就可以完成负载均衡,因此 假如从连接点很少的状况下沒有必需应用haproxy,大家立即在两部从服务器上安装keepalived而且应用同一个虚拟ip,即完成了负载均衡,也完成了高可用性(从连接点的高可用性群集的虚似IP有别于主连接点的高可用性群集的虚似IP,这时从连接点的高可用性群集和主连接点的高可用性群集是2个不一样的群集,因此 她们的virtual_router_id和虚似IP是不一样的)。

假如是以连接点许多的状况,那麼還是提议应用haproxy相互配合keepalived。haproxy和keepalived安裝在一起,那样就对负载均衡连接点开展高可用性。
假如从连接点许多的状况,還是用立即在从连接点上安裝keepalived开展负载均衡得话。那麼就需要对每一个从连接点的keepalived的环境变量开展改动,便会很不便。

在这儿大家仿真模拟从连接点许多的状况。

========================  平衡1的实际操作 ========================
操作过程,在主1受权一个haproxy客户给全部54.22.37.%这一IP段的mysql应用,从1和从2会另外转化成这一客户。
这一客户是用以给平衡1、平衡2连接点的haproxy联接从连接点应用的。

grant select on *.* to “haproxy”@”54.22.37.%” identified by “xxxxx”;

A.安裝和配备haproxy,监管全部从连接点
B.安裝和配备keepalived,对haproxy执行高可用性

A.流程以下:

tar -xzf haproxy-2.1.2.tar.gz
cd haproxy-2.1.2
make TARGET=Linux31
make install PREFIX=/usr/local/haproxy
mkdir /usr/local/haproxy/conf
cp examples/option-http_proxy.cfg /usr/local/haproxy/conf/haproxy.cfg

# 环境变量改动以下:

global
    daemon
    nbproc 1
    pidfile /usr/local/haproxy/conf/haproxy.pid
    
defaults
    mode tcp
    option redispatch
    option abortonclose
    maxconn 4096
    timeout connect 5000Ms
    timeout client 30000Ms
    timeout server 30000Ms
    log 127.0.0.1 local0 err
    
listen test1
    bind 0.0.0.0:3300
    mode tcp
    server s1 54.22.37.19:3306 check port 3306
    server s1 54.22.37.20:3306 check port 3306
    
listen admin_stats
    bind 0.0.0.0:8888
    mode http
    stats uri /haproxy
    stats auth haproxy:haproxy

# 将haproxy加上到环境变量,设定开机自启动haproxy
cd ~ && vi .bashrc
export PATH=$PATH:/usr/local/haproxy/sbin

source .bashrc

# 运行haproxy

haproxy -f /uar/local/haproxy/conf/haproxy.cfg

# 在当地做一下联接检测

mysql -h54.22.37.3 -uhaproxy -P3300 -p
show variables like "%uuid%";
\q
mysql -h54.22.37.3 -uhaproxy -P3300 -p
show variables like "%uuid%";

假如2次表明的uuid不一样,表明负载均衡取得成功。


B.流程以下:

tar -xzf keepalived-2.0.19.tar.gz
./configure
make && make install

# 改动环境变量(/usr/local/etc/keepalived/keepalived.conf):
! Configuration File for keepalived

global_defs {
   router_id LVS_HAPROXY_MASTER
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 52
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        54.22.37.26/24
    }
}

PS : 上边router_id,virtual_ipaddress及其virtual_router_id要和主1主2的keepalived的router_id不能反复。virtual_router_id、virtual_ipaddress一样则会被觉得主1主2和平衡1平衡2是同一个群集,而事实上它是2个不一样的群集。

# 运行keepalived 
keepalived -D -f /usr/local/etc/keepalived/keepalived.conf

# 查验keepalived是不是取得成功
ip add  #见到虚似IP的信息内容表明取得成功

# 查验虚似IP是不是可联接(要找一个被受权了mysql客户的连接点对该虚似IP开展远程桌面连接mysql服务项目,连接成了就表明该虚似IP是能用的。自然不一定是mysql服务项目,连别的服务项目也行,只需能证实连的这一虚似IP实际上是平衡1这一连接点就可以了)
mysql -h54.22.37.26 -uroot -pxxxxx

# 这儿只配备高可用性,不特定haproxy服务项目的负载均衡

================== 对平衡2的实际操作 ===============

将所述实际操作反复一次就可以。haproxy的配备內容一模一样。keepalived的配备內容则要作出一些更改,将MASTER字符串数组改成BACKUP,priority改成100就可以。

========================  Web运用的配备(以TP5为例子) ======================
最终,配备一下Web运用联接mysql群集,以TP5为例子,配备其根目录下/config/database.php。

这时database.php中,应当将主网络服务器填成主连接点高可用性群集的虚似IP 54.22.37.25;
将从服务器填成负载均衡连接点高可用性群集的虚似IP 54.22.37.26

我们可以将上一节的在204.175.124.51连接点中设定的haproxy给关掉了,由于早已用不到了。

如今从database.php中的配备上看,表层上主连接点连的是 54.22.37.25 事实上连的是主1 54.22.37.21
从连接点表层上连的是 54.22.37.26 事实上连的是 平衡1 54.22.37.2

<pre data-cke-widget-keep-attr="0" data-widget="codeSnippet" class="cke_widget_element" data-cke-widget-data="{"classes":null,"lang":"php","code":" ‘mysql’,\n    // 服务器ip\n    ‘hostname’        => [\”54.22.37.25\”,’54.22.37.26′],       # 将主连接点改成虚似IP\n    // 数据库查询名\n    ‘database’        => ‘test’,                            # 主连接点和从连接点的库名全是test\n    // 登录名\n    ‘username’        => [‘zbpblog’,\”haproxy\”],             # 主连接点受权zbpblog给负载均衡连接点,从连接点受权haproxy客户给负载均衡连接点\n    // 登陆密码\n    ‘password’        => [‘xxxxx’,\”xxxxx\”],\n    // 端口号\n    ‘hostport’        => [‘3306′,’3300’],                   # 负载均衡连接点的haproxy监视的是3300\n    // 联接dsn\n    ‘dsn’             => ”,\n    // 连接数据库主要参数\n    ‘params’          => [],\n    // 数据库查询编号默认设置选用utf8\n    ‘charset’         => ‘utf8’,\n    // 数据库表作为前缀\n    ‘prefix’          => ”,\n    // 数据库查询开发者模式\n    ‘debug’           => true,\n    // 数据库查询布署方法:0 集中型(单一网络服务器),1 分布式系统(主从关系网络服务器)\n    ‘deploy’          => 1,                                 # 表明应用mysql分布式系统群集\n    // 数据库查询读写能力是不是分离出来 主从关系式合理\n    ‘rw_separate’     => true,                              # 表明要读写分离,主库写,从库读\n    // 读写分离后 主网络服务器总数\n    ‘master_num’      => 1,                                 # 表明只有一个主连接点,假如master_num>1,则默认设置前n个连接点是主连接点,别的为从连接点\n    // 特定从服务器编号\n    ‘slave_no’        => [1],\n    // 全自动载入主库数据信息\n    ‘read_master’     => false,\n    \n    //…\n];”}”><?php
return [
    // 数据库类型
    'type'            => 'mysql',
    // 服务器ip
    'hostname'        => ["54.22.37.25",'54.22.37.26'],       # 将主连接点改成虚似IP
    // 数据库查询名
    'database'        => 'test',                            # 主连接点和从连接点的库名全是test
    // 登录名
    'username'        => ['zbpblog',"haproxy"],             # 主连接点受权zbpblog给负载均衡连接点,从连接点受权haproxy客户给负载均衡连接点
    // 登陆密码
    'password'        => ['xxxxx',"xxxxx"],
    // 端口号
    'hostport'        => ['3306','3300'],                   # 负载均衡连接点的haproxy监视的是3300
    // 联接dsn
    'dsn'             => '',
    // 连接数据库主要参数
    'params'          => [],
    // 数据库查询编号默认设置选用utf8
    'charset'         => 'utf8',
    // 数据库表作为前缀
    'prefix'          => '',
    // 数据库查询开发者模式
    'debug'           => true,
    // 数据库查询布署方法:0 集中型(单一网络服务器),1 分布式系统(主从关系网络服务器)
    'deploy'          => 1,                                 # 表明应用mysql分布式系统群集
    // 数据库查询读写能力是不是分离出来 主从关系式合理
    'rw_separate'     => true,                              # 表明要读写分离,主库写,从库读
    // 读写分离后 主网络服务器总数
    'master_num'      => 1,                                 # 表明只有一个主连接点,假如master_num>1,则默认设置前n个连接点是主连接点,别的为从连接点
    // 特定从服务器编号
    'slave_no'        => [1],
    // 全自动载入主库数据信息
    'read_master'     => false,
    
    //...
];

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

最终做检测,试着关掉主1的mysql服务项目,看一下是不是还能载入数据信息。
试着关掉平衡1的keepalived服务项目,看一下是不是还能查到数据信息。

这儿留意,在关掉主1以后插进数据信息,发觉查看到的数据信息不包含新插进的数据信息。
缘故是从1从2是对主1开展同歩,而不是对主2开展同歩。
主1主2是主主拷贝可是要直到主1的mysql重新启动以后,主2增加的数据信息才可以同歩到主1,才可以同歩到从1从2。
也就代表着,主1挂了的这一段期内所插进的新数据没法被查看到。
主1重新启动了以后才可以查看到。

假如想处理这个问题,能够应用多源拷贝。
我们知道,主从复制,从连接点只有同歩一个主连接点。而多源拷贝则能够让一个从连接点根据好几个主连接点的数据信息。
多源拷贝是mysql 5.7 的新作用
在这儿不对多源拷贝多论述,很感兴趣的盆友能够在网上查看相关资料完成。

 

    关键字:

天才代写-代写联系方式