此次实验的环境如下
IP地址 | 主从关系 | 复制账号 | 复制格式 |
---|---|---|---|
11.12.14.29 | 主库 | repl | Row-Based |
11.12.14.30 | 从库(半同步/备master) | repl | Row-Based |
11.12.14.39 | 从库(异步) | repl | Row-Based |
11.12.14.40 | 管理节点 | 无 | 无 |
11.12.14.41 | VIP | 无 | 无 |
上节我们说了MHA的故障转移,这节内容为手动切换
我们可以先通过 show slave status\G查看从库同步是否正常
我们通过如下命令事实查看切换功臣
tail -f /etc/mha/manager/mha.log
首先需要关闭MHA的管理进程
root> masterha_stop -conf=/etc/mha/mha.conf
之后我们通过如下命令关闭主库
masterha_master_switch -master_state=alive –orig_master_is_new_slave –conf=/etc/mha/mha.conf
-master_state=alive 代表告诉MHA原master还是存活的,不需要将其从配置文件删除
–orig_master_is_new_slave 参数代表原master会自动同步新的master
还有一些其他的参数如下
-running_updates_limit 如果主库的写操作时间超过了该参数,则退出切换
–interactive=0 代表直接确认,不需要输入YES
这时我们查看你管理阶段的日志输出
上图可以看到需要确认在确认前是否执行flush no_write_to_inlog tables 语句
这里输入YES
从上图可以看出,mha重新读取配置文件并确认数据库状态
这里确认是否需要从14.29切换至14.30
这里输入YES
之后就是正式的切换过程,简单概括如下
以上就是一个完整的手工迁移过程,这时可以手动查看各节点信息
https://www.percona.com/blog/2016/09/02/mha-quickstart-guide/
http://www.ttlsa.com/mysql/step-one-by-one-deploy-mysql-mha-cluster/