勘误,昨天有一位 海外 friend 指出昨天文中 postgresql  bloom 中的第四步截图是并行扫描,而没有用到bloom 索引,这里抱歉,经查实截图错误,下面是重新的截图,同时另一幅截图也有问题建立索引时缺少 USING bloom,感谢您。

另也希望大家发现可以发现我的错误,并及时指出,让我们大家可以成长的更快

第四步截图

MYSQL  MHA VS GTID  与 BINLOG SERVER_远程库

今天正文

MYSQL  MHA VS GTID  与 BINLOG SERVER_远程库_02

其实MHA是真没有什么好说的,一个成熟的不能在成熟的 MYSQL 高可用的方案。但一般来说大部分企业部署 MHA 都是配以传统的复制方式,而MYSQL 从5.6 开始已经进入了 GTID 的世界,而MHA 从0.56 也支持了GTID,虽然那个日本人早就不在给大家升级MHA 的版本了,但貌似最近一个白人小哥在继续升级MHA 目前的最新版本是 0.58 。到目前为止没有任何一款数据库有 MYSQL的高可用的方案多(I am sorry ,其实 PG 的方案也不少)。

所以怎么将MYSQL的 MHA 的方案升级到 GTID 的方式就可以说说了,其中有一点就是,为什么要多了一个 binlog server 的设置。

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_03

我们从上面Yoshinori 的BLOG 中截取了一段

在binlog部分,您可以定义mysqlbinlog流媒体服务器。当MHA执行基于GTID的故障转移时,MHA检查binlog服务器,如果binlog服务器记录的BINLOG在其他从属服务器之前,MHA在恢复之前将来自binlog服务器的差异binlog事件应用到新主服务器。当MHA执行基于非gtid(传统)的故障转移时,MHA将忽略binlog服务器,更多细节可以在文档中找到。

并且其中还提到了支持自定义的mysql binlog location, 在使用GTID 的MYSQL复制中,并且使用了auto_postion=1 的情况下MHA 将不能使用老的模式来获得差异的日志,而这里使用BINLOG SERVER 可以有效的提高增强MYSQL 主从切换中,可以让新主从 BINLOG SERVER 中获得差异的日志,并且补齐。

从MYSQL  5.6开始 MYSQL  提供了 BINLOG SEVER 的概念,通过BINLOG SERVER 来备份BINLOG 日志,并且根据相关的原理这样的备份的BINLOG 日志基本上是实时的。

首先从MHA 0.56 添加了 master_binlog_dir 这个参数,这个参数是防止MYSQL 死机后无法获得BINLOG 的具体的位置而设定的。(当然如果LINUX 系统同死机了,那这个设置也是无效的)

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_04

在启动了 GTID 的复制方式后,并且添加了BINLOG SERVER 选项后,尝试终止MASTER ,可以看到 MHA 已经自动判断出 MYSQL 使用 GTID的方式进行的复制。

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_05

并且在信息中已经有相关 GTID 的位置信息

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_06

切换是成功的,那如何建立一个BINLOG SERVER 其实对MYSQL 数量众多的情况下,是有必要建立一个 BINLOG SERVER 来保存MYSQL 服务器的BINLOG 数据。(你也可以指定master 和其他slave 的 binlog 目录作为binlog server)

可以在一台定义好的MYSQL SERVER 中设置

nohup mysqlbinlog -R --raw --host='192.168.198.201' --port=3306 --user='repl' --password='1234.com' --stop-never --stop-never-slave-server-id=1202 mysql-bin.000001 --result-file=/data/binlog_backup/ &

其中 mysql-bin.000001 是告知传送BINLOG 是从哪个 BINLOG 开始的

R   --read-from-remote-server :表示从远程机器上读取 binlog,要确保远程 mysql 存储,需要提供--host, --user, --password 参数;  使用该选项时,mysqlbinlog 会伪装成一个 slave,连接读取,请求指定的 binlog file,主库获取接收到这个请求之后就创建一个 binlog dump 线程推送 binlog 给 mysqlbinlog server。
--raw: 以 binlog 格式存储日志,方便后期使用;
--host:  远程库的主机 IP 或者主机名;
--port:  远端库的端口号;
--user:  远程库上用于复制的账号;
--password:  远端库上复制账号的密码;
--stop-never:  一直连接到远程的 server 上读取 binlog 日志,直接到远程的 server 关闭后才会退出。或是被 pkill 掉;
--stop-never-slave-server-id:  如果需要启动多个 binlog server ,需要给 binlog server 指定 server-id 。

--result-file:   指定存储到本地的目录,注意后缀需要加上/

在执行完命令后,可以很快的将源端的BINLOG 复制到目的机,但需要注意的是,如果源端进行  purge 操作的时候,目的端的日志是不会减少的,所以还需要自己考虑如何定时清理不在使用的BINLOG  文件。

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_07

同时如果怕MASTER 主机重启动之类的事情可以写一个脚本定时运行

以下为从网上找的一段 SHELL 程序 

# cat > binlog_cp.sh << EOF
#!/bin/bash
BACKUP_BIN=/usr/local/mysql/bin/mysqlbinlog
LOCAL_BACKUP_DIR=/data/mysql/mysql3306/logs/
BACKUP_LOG=/tmp/backup.log
REMOTE_HOST=192.168.199.230
REMOTE_PORT=3306
REMOTE_USER=repl
REMOTE_PASS=unixfbi
FIRST_BINLOG=mysql-bin.000001
SLAVE_SERVER_ID=2313306
# wait for 10s
SLEEP_SECONDS=10
cd ${LOCAL_BACKUP_DIR}

while :
do
  if [ `ls -A "${LOCAL_BACKUP_DIR}" |wc -l` -eq 0 ];then
     LAST_FILE=${FIRST_BINLOG}
  else
     LAST_FILE=`ls -l ${LOCAL_BACKUP_DIR} |tail -n 1 |awk '{print $NF}'`
  fi
  ${BACKUP_BIN} --raw -R --stop-never --host=${REMOTE_HOST} --port=${REMOTE_PORT} --user=${REMOTE_USER} --password=${REMOTE_PASS}  --stop-never --stop-never-slave-server-id=${SLAVE_SERVER_ID} ${LAST_FILE} --result-file=${LOCAL_BACKUP_DIR}
  echo "`date +"%Y/%m/%d %H:%M:%S"` mysqlbinlog is stoped,return code: $?" | tee -a ${BACKUP_LOG}
  echo "${SLEEP_SECONDS}s will continue !" | tee -a ${BACKUP_LOG}  
  sleep ${SLEEP_SECONDS}
done
EOF

通过这个程序来不断的判断master 服务器是否OK ,如果连接断掉后,会在MASTER 启动后,再次进行连接将日志拉取。

MYSQL  MHA VS GTID  与 BINLOG SERVER_mysql_08