MYSQL教程实战篇:搭建mysql高可用集群

作者 : IT 大叔 本文共14846个字,预计阅读时间需要38分钟 发布时间: 2020-11-14

本文继上一节MYSQL教程实战篇:使用haproxy搭建负载均衡集群

这里贴出上一节使用haproxy搭建负载均衡集群的拓扑图:

MYSQL教程实战篇:搭建mysql高可用集群插图

负载均衡集群拓扑图

之前我们搭建负载均衡的好处:
一个是提高读取性能
一个是当一台从节点挂掉,负载均衡节点会将请求平均的导到其他从节点,提高可用性。

但是之前的例子只有一台写服务器(主节点),一台负载均衡节点,如果主节点挂掉,那么web应用就不能进行写操作,如果负载均衡节点挂掉就无法读取数据。

为了避免这个问题,就要做一些冗余性操作:
多设置一台主节点的备份节点,当我们写入的时候只往主节点写入,不往这个备份节点写入,也就是说正常情况下,备份节点什么都不用干。只有当主机点挂掉了之后,web应用才往这个备份节点写入。而备份节点当然也和所有从节点是主从复制的关系。
备份节点和主节点是主主复制的关系,这样一方面平时备份节点会和主节点的新增数据同步;另一方面在主节点挂掉的期间,备份节点新增的数据也会写入到主节点里面(在主节点恢复正常后写入主节点)。

然后负载均衡节点也同样是这样操作,多架设一台负载均衡节点,平时也是不起作用,当原负载均衡节点挂掉的时候,另一台负载均衡节点就会起作用。

使用keepalived实现高可用


原理和过程:

MYSQL教程实战篇:搭建mysql高可用集群插图(2)
节点正常时的虚拟IP指向

MYSQL教程实战篇:搭建mysql高可用集群插图(4)

节点宕机时的虚拟IP指向

在主节点和主节点的备份节点(叫做主节点2)都安装keepalived。并通过keepalived的配置文件指定同一个虚拟IP,该虚拟IP和两台主节点的IP段要一致才行。
当两台主节点都启动keepalived服务的时候,keepalived会在其中一台权重高的节点,即主节点1(权重可以在keepalived配置中指定)生成这个虚拟IP,另一个节点不会生成这个虚拟IP。
我们连接mysql服务的时候,在业务层指定连接的host是这个虚拟IP的IP,而不是两台主节点的ip。
此时虚拟IP是在主节点1中生成的,所以web应用其实连接的是主节点1。
此时,主节点1和主节点2是有互相通信的。当主节点1因为故障(如断电,死机等原因)导致主节点1的keepalived服务断开,主节点2的keepalived接收不到主节点1的keepalived的响应,那么主节点2的keepalived就会在主节点2上生成这个虚拟ip。此时web应用连接的就是主节点2。
当主节点1恢复过来,并且重启keepalived服务时,两个节点的通信恢复,而且主节点1权重比主节点2高,此时主节点1会重新生成该虚拟IP,柱节点2的虚拟IP就消失。那么相当于Web节点又连回主节点1。

两个主节点最好设置开机自启动keepalived,不然主节点所在主机挂掉之后再恢复,但是忘记重启keepalived,那么虚拟ip就一直都在备份节点那。
keepalived不仅仅只局限在mysql的高可用,其层面更高。

keepalived的安装和使

# 下载,解压,安装keepalived
tar -xzf keepalived-2.0.19.tar.gz
cd keepalived-2.0.19
./configure             # 如果报错,请安装gcc-c++/openssl/openssl-devel这几个依赖
make && make install

此时 keepalive 的

配置文件在 /usr/local/etc/keepalived/keepalived.conf

命令文件在 /usr/local/sbin/keeplive

配置参数:
下面是最简单的配置,也是作者的配置:

global_defs {
   router_id LVS_MASTER     # 在每一个keepalived都有一个router_id,可以随便起,但相连通的keepalived的router_id不能一样。
}

vrrp_instance VI_1 {        # 配置实例
    state MASTER    # 表示该keepalived的状态,有两种,MASTER和BACKUP。表示是主节点还是备份节点,但是并非在这里配置了MASTER就是主节点。而是要通过priority配置,优先级高的就是主节点。而且主节点的priority要比备份节点的起码高50才行
    
    interface eth0      #表示虚拟ip所绑定的网卡
    virtual_router_id 51    # 虚拟路由节点的id号,主节点和备份节点的虚拟路由id必须相同
    
    priority 150    # 优先级,优先级高的是主节点,主节点平时处于工作状态,而备份节点平时不干事情,只有当主节点挂了才顶替主机点工作
    
    advert_int 1    # 我们知道 主节点和备份节点的keepalived是互相通信的。这里是通信的时间间隔,单位秒。该值越小,越消耗性能。
    
    authentication {    # 授权,有两种方式,默认使用PASS的方式
        auth_type PASS  # 授权方式
        auth_pass 1111  # 密码,连通的多台keepalived间的密码要相同
    }
    virtual_ipaddress {     # 要生成的虚拟IP地址,可以生成多个,可以随意指定,但是必须是和主节点以及备份节点相同的网段的ip才行
        192.168.200.100/24   # 后面的/24表示子网掩码是255.255.255.0
    }
}

接下来就可以启动了
keepalived -D -f /usr/local/etc/keepalived/keepalived.conf          # -D后台运行

然后执行
ip add
可以看到eth0网卡下有本机ip信息,还有虚拟ip的信息,就表示成功了:
inet 154.202.57.21/29 brd 154.202.57.225 scope global eth0
valid_lft forever preferred_lft forever

inet 154.202.57.100/24 scope global eth0
valid_lft forever preferred_lft forever

备份节点也安装keepalived,配置内容如下(和主节点的基本一样):


global_defs {
   router_id LVS_BACKUP
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    priority 100
    advert_int 1    
    authentication {   
        auth_type PASS  
        auth_pass 1111  
    }
    virtual_ipaddress {    
        192.168.200.16/24  
    }
}

发现这里并没有虚拟ip的信息。这是对的,因为虚拟ip只会在一台节点上出现,如果主节点挂掉了,那么虚拟ip才会出现在备份节点上。
这里我设置了主节点的priority比备份节点的priority高50,所以当主节点重启keepalived服务的时候,虚拟ip会重新绑回到主节点上。

在业务层,我们就直接连接这个虚拟ip,而我们实际连的是这个虚拟ip所在的节点上,当主节点正常工作时,虚拟ip在主节点上,那么我们实际连的就是主节点;当主节点挂掉,虚拟ip就会出现备份节点上,我们此时实际连接的就是这个备份节点。

此时我们在本地连接一下这个虚拟IP的mysql(主节点和备份节点要关闭防火墙,而且要授权mysql用户给本地ip才行)
连成功就说明可以了。

PS:如果连不上,可能是防火墙没关;
还有可能是你指定的虚拟IP是一个真实IP,该真实IP已存在,是别人的服务器。
所以你必须绑定一个没有人用的ip作为虚拟ip才行。

keepalived的邮件参数

现在,假如主机点挂掉了,只剩下一台备份节点了,那么如果这个备份节点也挂掉了,那么就读取不了数据了。此时我们就要设置邮件报警,提示开发者只剩下一台节点了。

邮件报警写在global_defs这个全局配置中,如下:

global_defs{
    noticatition_email{
        wenzhangxiang@yeah.net      # 收件者
    }
    notification_email from 1640632344@qq.com       # 发件者
    smtp_server localhost       # 本地安装smtp服务
    smtp_connect_timeout 30     # 超时时间
}

但是本地还没有安装smtp服务,还要自己安装smtp服务。

keepalived的负载均衡参数

keepalived不仅可以配置高可用集群,还可以配置负载均衡集群

其实就是在keepalived中指定服务,这里以指定mysql服务为例。
如果只是搭建高可用,不使用keepalived负载均衡的配置也行,只需要上面的最基本的配置即可。但是最基本的配置会有一个问题:
我们知道如果主节点的keepalived服务挂掉,那么虚拟IP就所代表的的真实IP就会转到备份节点。但是如果是mysql服务挂掉但是keepalived服务没有挂掉,那么keepalived就不会将虚拟IP转到备份节点,而我们的目的就是要对mysql服务进行高可用,这种情况下就没有达到我们的目的,所以还是要对keepalived的配置指定要绑定的服务的。

virtual_server 虚拟IP 3306 {  # “虚拟IP 端口号” 虚拟IP是上面的virtual_ipaddress指定的IP,不含/24;端口号是你想指定的服务的端口号,如果想对网站进行负载均衡,就是80或443端口

    delay_loop 6     #每隔6s检查一次联通性

    lb_algo wrr      # 负载均衡的算法,wrr/rr/wlc,rr是轮询

    lb_kind DR       # 负载均衡转发规则:DR/NAT/TUN,如果主节点和备份节点在同一网段下,用DR即可

    persistence_timeout 60     #会话保持时间

    protocol TCP          # 协议

    real_server 节点的真实IP 3306 {  # 本机真实IP

        weight 100      # 权重   
 
        notify_down /data/sh/mysql.sh   

        TCP_CHECK {  

        connect_timeout 10  

        nb_get_retry 3  

        delay_before_retry 3  

        connect_port 3306  

        }  

    }  

}

这里提一下notify_down /data/sh/mysql.sh 这个配置。
表示当该节点的mysql服务挂掉是,要执行/data/sh/mysql.sh这个shell脚本。而这个脚本要做的事情就是将keepalived停止。原因很简单,mysql挂掉但是keepalived不挂掉,那么主节点会一直抢占着虚拟IP,为了将虚拟IP转移到备份节点,我们就要将主节点的keepalived杀死,这是/data/sh/mysql.sh这个脚本要做的事情,该脚本内容如下:

#!/bin/bash
pkill keepalive

当然我们还可以写一个用于发送邮件的Python脚本或者PHP脚本,并在mysql.sh这个bash脚本中执行发邮件的脚本。这样就可以在节点挂掉时通知管理员及时处理。

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教程实战篇:搭建mysql高可用集群插图(6)

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的主主复制了。

现在看两个有趣的现象:
已知从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实现负载均衡,按照高可用的逻辑,需要在两个节点上安装haproxy,同时这两个节点还要安装keepalived,然后这两个负载均衡节点要同时监控两个mysql从节点。

但是其实,keepalived本身就可以实现负载均衡,所以如果从节点不多的情况下没有必要使用haproxy,我们直接在两台从服务器上安装keepalived并且使用同一个虚拟ip,即实现了负载均衡,也实现了高可用(从节点的高可用集群的虚拟IP不同于主节点的高可用集群的虚拟IP,此时从节点的高可用集群和主节点的高可用集群是两个不同的集群,所以他们的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%";

如果两次显示的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是同一个集群,而实际上这是两个不同的集群。

# 启动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

<?php
return [
    // 数据库类型
    'type'            => 'mysql',
    // 服务器地址
    '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 的新功能
在这里不对多源复制多阐述,感兴趣的朋友可以网上查阅相关资料实现。

免责声明:
1. 本站资源转自互联网,源码资源分享仅供交流学习,下载后切勿用于商业用途,否则开发者追究责任与本站无关!
2. 本站使用「署名 4.0 国际」创作协议,可自由转载、引用,但需署名原版权作者且注明文章出处
3. 未登录无法下载,登录使用金币下载所有资源。
IT小站 » MYSQL教程实战篇:搭建mysql高可用集群

常见问题FAQ

没有金币/金币不足 怎么办?
本站已开通每日签到送金币,每日签到赠送五枚金币,金币可累积。
所有资源普通会员都能下载吗?
本站所有资源普通会员都可以下载,需要消耗金币下载的白金会员资源,通过每日签到,即可获取免费金币,金币可累积使用。

发表评论