前言
一次原以来很简单的pika升级（关掉slave，替换可执行文件，重启，然后主从切换，完成升级），两三个小时搞定，前后竟然折腾了一周，有必要总结下。
pika升级遇到问题
- pika运行环境带来的问题
线上环境pika使用的操作系统是centos6，gcc版本是4.4.7，而pika编译安装的环境要求gcc不能低于4.8，与运维同事沟通后，得知在centos6上升级gcc到新版本很麻烦，而且会有坑，建议直接在centos7上部署完整的环境。就选定用centos7部署新的版本pika，加入slave，切换master方式升级。
这个过程又遇到两个问题:
(1). 以为pika的安装运行环境的依赖库只需要在编译环境安装即可，后发现运行环境也必须按照相应的要求安装。
(2). 在一台机器编译并能够运行成功，但拷贝到其他机器上就报illegal instruction，定位为指令集不兼容的问题，使用的云环境不想再具体定位为啥指令集不兼容（同样的操作系统），就将代码拉到运行环境编译运行，然后拷贝到其他机器解决。 - 旧版本pika 卡死
开始升级pika时，遇到旧版本pika卡死的请求，后来和360的pika开发小伙伴沟通后，被告知这是pika 2.1版本的一个bug，在新版本pika 2.2.3已经fix，也正是这个bug，促使了我们在后面遇到问题时，也要尝试解决问题进行升级。一个数据库运行着卡死，这雷真心受不了。。还好卡死不是毕现的，遇到了一次 - pika同步不成功
在进行pika主从数据同步时，运维同事发现一直在进行全量数据同步，后来分析了下是由于binlog保留的太少了，导致在pika写数据量多时，全量同步完无法进行增量同步，重复全量同步，后来看了下相关实现及与pika开发小伙伴交流，通过在线 config set expire-logs-nums 500解决，这个设置这么大耗费硬盘还是比较多的，应该设置200左右就可以了～ - pika的主从互换后无法建立主从关系
这个问题分析了下是由于断开旧的主从关系时，旧的master上一些数据（binlog）还没有同步到旧slave上，而旧slave切换为新master后，旧的master作为新master的slave进行同步，会因为binlog的offset问题无法正常建立主从关系，INFO查看同步状态码为5，即错误状态。另一个导致不能进行主从同步的问题，有时在进行主从同步时，报某个binlog不存在，解决办法就是把那个binlog touch出来～～。在交流群里大家讨论了下，目前pika在Gracefully shutdown时，还是不够足够的graceful，应该是先将停写，然后将数据同步完，再shutdown比较合适。这个主从同步问题目前的解决办法是可以来一次全同步。。 - 新版本pika做为master挂掉
进行新旧版本切换时发现，把新版本的pika切为master，过几分钟后，新版本的master会挂掉，相关log看不出问题所在，后与360 pika的小伙伴沟通后，他们判断为那个pika进程的文件句柄被写满了，导致挂掉，后来查看了下pika进程的文件描述符限制远小于系统设定的。后定位到原因是由于启动pika的monit进程的最大文件描述符的限制是4095，导致pika最大文件描述符的限制是4095，导致too many open files而挂掉pika。
总结
pika在线上稳定运行快10个月了，这个过程没有出现明显的异常，还是很赞的。根据pika实现（将数据存在磁盘中，还有主从）及这么长时间的稳定运行，觉得这次升级还是比较容易，风险不大的，但还是发现了上面的这些问题。这次是在一个资深运维协助下进行的升级，不然估计还会有不少其他的问题。。
这次升级持续这么长时间，我在想这中间是有哪些是可以在升级前做的更多的吗，第一个问题中的编译运行环境可以提前测试确定出来，第三个问题在单机环境测试出来，不知道电脑能不能扛的住。。第四个问题如果测试覆盖够也可以发现这个问题（虽然这个问题发现了，也没太好的解决，只是避免了不必要的问题查看定位），其他的依然比较难发现出来。
对一个长时间没有进行升级的组件进行升级需要慎重，应对方案要考虑全，尤其是基础组件，应对失败，回退方案及可行步骤一定要提前准备好，侥幸要不得。
最终升级成功，祝大家玩的愉快～
