replication-manager搭建部署

1、replication-manager 安装配置
安装环境
MariaDB 10.1.16
168.24.65.30/168.24.65.31/168.24.65.32 主库30，一主两从结构
安装步骤
a、解压二进制文件
tar zxvf replication-manager-1.1.0-preview3-6cdbd91.tar.gz
解压后会产生三个文件目录 etc、usr、var
etc 目录下面有配置replication-manager的服务启动文件和范例配置文件。
usr目录下存放replication-manager核心执行程序
var目录主要是用来存放备份binlog和监控数据等
b、创建相应目录
mkdir -p /etc/replication-manager //配置文件存放目录，这里用默认的目录。
方便后续执行replication-manager命令时默认从这里加载配置文件。
mkdir -p /apps/logs/replication-manager //备份binlog保存目录
mkdir -p /apps/dbdat/replication-manager //数据目录
mkdir -p /apps/svr/replication-manager //可执行程序目录
cp -r /apps/tool/usr/share/replication-manager /usr/share/ 
cp -r /apps/tool/usr/bin/replication-manager  /apps/svr/replication-manager
chown -R apps:apps /apps/logs/replication-manager
chown -R apps:apps /apps/dbdat/replication-manager
chown -R apps:apps /apps/svr/replication-manager
chown -R apps:apps /usr/share/replication-manager
chown -R apps:apps /apps/logs

2、go环境安装
go下载：
http://pan.baidu.com/s/1pL0Ca4V#list/path=%2Fgo
tar zxvf go1.7.1.linux-amd64.tar.gz  -C /usr/local
mkdir -p /apps/gocode
chown -R apps:apps /apps/gocode
su - apps
$HOME/.bashrc 中配置环境变量
# Add go PATH
export GOROOT=/usr/local/go
export PATH=$PATH:$GOROOT/bin
export GOPATH=/apps/gocode

3、glibc-2.14安装 （replication-manager1.1的版本要求安装）
下载地址:http://pan.baidu.com/s/1sjLUcFz, 或者去http://rpm.pbone.net/ 搜索以上rpm包名下载
rpm -Uvh --aid --nodeps glibc-common-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps  nscd-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-static-2.14.1-6.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-utils-2.14.1-6.x86_64.rpm
检查GLIBC2.14是否安装成功
strings /lib64/libc.so.6 | grep GLIBC
列表中有GLIBC_2.14表示安装成功。

4、创建配置文件
more /etc/replication-manager/config.toml 
[Default]
logfile = "/apps/logs/replication-manager/replication-manager.log" //日志目录配置
verbose = true
hosts = "168.24.65.30:3306,168.24.65.31:3306,168.24.65.32:3306" //集群节点配置，主机ip:端口，用逗号分隔。
#user = "maxscale:xxx // replication-manager管理用户密码设置。该用户所赋予的权限 RELOAD,SUPER, REPLICATION SLAVE, REPLICATION CLIENT
user = "maxscale:6070a8044e97e3f92f01192dfb4a4198ad4dff8270a732d061" //配置的是加密码后的密码
#rpluser="rep:xxx"
// 该用户所给的权限 REPLICATION SLAVE, REPLICATION CLIENT
rpluser="rep:c7445298b22c368d01bff5a0c61e7d3281100bb769ac4b" //加密后的密码。
interactive = false   ---控制failover为自动方式
working-directory = "/apps/dbdat/replication-manager" 
share-directory = "/usr/share/replication-manager"
http-root = "/usr/share/replication-manager/dashboard" 
switchover-at-equal-gtid=true //确保主从库GTID一致才进行切换。这个对与保障主从数据一致性很重要
failcount=10 // 主库失败后，累计检测到10次主库失败信息才进行切换。默认系统每300秒对该数据清0。换句话说就是在300秒内累计 检测到10次主库失败的信息才进行主从失败切换。
#switchover-max-slave-delay=1 //手动切换前的延迟控制。默认为0，即不做限制。
#For a more conservative never lost data scenario
#failover-limit = 3 
#failover-time-limit = 10
#failover-at-sync = true // 主从库启用半同步复制保持一致才进行切换
failover-max-slave-delay = 1 //主库失败切换的延迟限制条件
failover-restart-unsafe = false //主库失败后，直接启动加入集群。这里配置为false,从数据安全角度考虑，是不允许直接加入的。
=======
[Default]
logfile =  "/apps/logs/replication-manager/replication-manager.log"
verbose = true
hosts ="168.24.65.30:3306,168.24.65.31:3306,168.24.65.32:3306"
user = "maxscale:7244644664b42f163c58ed4e2f90c49cb3d48b6977a3e761"
rpluser="rep:f9e6336e06f8f1d8fd5bab04a1c156266faedebde0e216
interactive = true  --
daemon = true
#autorejoin-flashback = true
#autorejoin-mysqldump = true
#config auto rejoin-script
#rejoin-script = "" 
# HTTP
 http-server = true
 http-bind-address = "0.0.0.0"
 http-port = "10001"
 http-auth = false
 http-session-lifetime =   3600
 http-bootstrap-button = false
# A user can force switchover or failover by ignoring those checks via the
#rplchecks=false   
working-directory = "/apps/dbdat/replication-manager"
share-directory = "/usr/share/replication-manager"
http-root = "/usr/share/replication-manager/dashboard"
mariadb-binary-path = "/apps/svr/mariadb10/bin/"
#http-root = "/apps/replication-manager1.1/share/replication-manager/dashboard"
switchover-at-equal-gtid=true
failcount=10
switchover-max-slave-delay=1
#For a more conservative never lost data scenario
failover-limit = 3
failover-time-limit = 10
#failover-at-sync = true
# Maximum replication delay before initiating failover
failover-max-slave-delay = 1
failover-restart-unsafe = false
并把配置文件copy到其它节点上.

chown -R apps:apps /etc/replication-manager/

5.用户密码加密方法：
a.以root用户执行命令创建秘钥，会在 /etc/replication-manager/ 目录下生产一个隐藏的秘钥文件 .replication-manager.key
/apps/svr/replication-manager/replication-manager keygen 
b.对明文密码进行加密：
 replication-manager password  'your password' 

7..Replication-Manager管理用户权限配置。主库上执行该命令。 
select password('密码");---先查出密码的hash值，再带入如下授权脚本中
GRANT SELECT, RELOAD, SHOW DATABASES, SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'maxscale'@'%' IDENTIFIED BY PASSWORD '*EC44299D2F136633BEE4240CBB5AC0D9828470E8'; flush privileges;
PS：两个密码都要作上面处理，并将密码hash值放入配置文件中.

6、启动 replication-manager 的monitor监控程序 
nohup /apps/svr/replication-manager/replication-manager --config=/etc/replication-manager/config.toml monitor > /apps/logs/rplm.log 2>&1 & 

7、failover测试：
a.关闭30主库。观察到replication-manager检测到主库10次失败信息后手工进行主库切换,选举31从库为主库,32从库重新change master到新主库上。
b.再启动30主库，观察到主库会自动加入集群，并指向新选举的主库31进行复制。
新主库上查看到从库信息：30和32
MariaDB [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|    323306 |      | 3306 |    313306 |
|    303306 |      | 3306 |    313306 |
+-----------+------+------+-----------+

8、switchover测试
关闭 replication-manager的monitor 程序。31主库，30/32是从库。
replication-manager switchover。
执行主库切换命令后会检测到主库和从库的GTID值有差异，因此手动切换失败。
等待上面从库数据追上主库后，执行主库切换命令，可以观察到主库已经成功从31切换到32，原来30和31变为指向32进行复制。
(product)root@localhost [(none)]> show slave hosts;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|    313306 |      | 3306 |    323306 |
|    303306 |      | 3306 |    323306 |


总结
replication-manager对于failover在高负载crash情况下有可能造成主从库数据不一致。作者建议主从复制采用并行复制和半同步复制来保障主从数据的一致性。
考虑到我们生产环境暂时不推广使用半同步复制，因此我们不采用replication-manager的自动失败切换方案。
replication-manager 对于switchover的支持很不错。考虑到我们生产主库失败宕机的情况非常的少。真正发生这样的突发状况，在
收到告警信息之后，可以先确认主从库复制是否一致，然后启动恢复主库、切换主库。
Replication-Manager切换步骤：
1.确认复制配置
2.检查从库复制状况
3.主库上检查长连接查询和事务
4.选举新的主库（默认是数据最新的从库，但也可以是指定的候选从库）
5.通过调用可选的脚本，让主库上的IP失效。
6.通过执行 flush tables with read lock 拒绝主库的写请求
7.通过设置 read_only 标签，拒绝主库写请求 8.通过减小 max_connections 拒绝主库写请求
9.杀掉主库上任何存在的连接
10.观察确保所有从库赶上主库目前的GTID位置
11.提升候选的从库为新的主库
12.通过调用可选的脚本，把主库IP拉起来。
13.把其他从库和旧的主库切换到指向新主库复制
14.设置从库为 read-only