全部博文(51)
分类: 系统运维
2017-11-09 17:49:56
思路:twemproxy代理后端有若干的redis节点,如果某个节点机器内存不足,就得将此节点迁移到内存够大的机器,如果此节点已经坏掉,就应该将它保存的rdb文件拷贝到迁移的机器上(注意校验),重新部署新的节点,然后将twemproxy的配置文件修改,通知相关人员,最后重启twemproxy,之后在观察twemproxy的状态(cpu,连接数)是否和之前twemproxy的状态一致,再联系相关人员,对比是否有异常。
1> 登录中控机器
2> cd /opt/temp/liuguo/nutcracker_conf #其中包含了你即将迁移的集群的所有twemproxy的配置文件
3> sed -n 's/$newip/$oldip/p' *.yml #用新的节点替换旧的节点,修改配置文件
4> bash #检查线上的配置文件是否和本地的一样(如一样,是否是没有修改,或者是故意没有修改的),期待是不一样的,因为你修改了配置文件
5> \cp -f *.yml last_version_conf/ #备份当前的配置文件
6> bash #分发配置文件,如果线上的文件和本地的文件是一致的,就不会分发,只有配置文件不同才会分发
7> ./b_c hosts/liuguo /opt/twemproxy1/sbin #分发到线上的机器(远端路径是:/opt/twemproxy1/sbin),用法./restart.sh 22121,判断22121端口是否监听在机器上,否,则不做任何操作,这个脚本通过优化后,可以提供交互式的操作,如果为重启成功会提示你是否重新尝试。
8> ./b_d.sh hosts/liuguo "bash /opt/twemproxy1/restart.sh 22121" #仔细看下b_d.sh脚本,这个脚本会显示分割线,并且会捕捉信号,用于退出整个循坏。
9> ./b_d.sh hosts/liuguo "ps -ef | grep nutcracker" #检测进程是否启动成功
注:1.将twemproxy集群的后端redis的数据先拷贝(或者用slave的方式)到目标机器。
2.在新机器上装twemproxy时注意有没有打开debug日志,如果打开了,在启动的时候,最好将日志级别调到4,因为5以上的日志级别刷日志比较快。
3.部署的时候最好先拿一台测试一下,是否是预期的效果。
在集群迁移过程中遇到的问题:
1.使用重启脚本在中控上远端执行的时候,由于脚本并没有反馈是否重启成功,并且输出的信息是多余没必要的,所以临时的想了方法检测是否重启成功,事实证明确实有没能重启成功的端口,可能的
原因是端口被占用,只能在远端机器上手动重启(脚本已优化)
2.twemproxy启动的命令不正确,由于其中有一台机器的twemproxy安装的时候是打开了debug日志的,所以以之前的重启命令重启的时候,会产生大量的日志,导致twemproxy的cpu负载提升了2-6%
(当时迁移的时候是看着twemproxy的cpu监控screen的),之后重新调整了启动命令。
涉及相关脚本
./b_c.sh
./b_d.sh
deploy.sh
restart.sh