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-00156239020cPS：上边的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 keepalivechmod 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
<?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 的新作用
在这儿不对多源拷贝多论述，很感兴趣的盆友能够在网上查看相关资料完成。
