zabbix mysql 迁移总结

之前的zabbix，item已经达到了27w，nvps达到了3.5K，高峰可以达到5K+，但是手里还有200台机器没有添加，还有若干个模板没有添加。面对如此情况，不得不对zabbix，做点啥了，zabbix的瓶颈在于mysql，首先的要点是mysql，我们的计划是mysql从sas迁移到ssd，顺便把主从同步，partition都做了。

2015年4月27日下午决定做这件事，整体流程和大约的花费时间如下所示：
实施过程：
0.思想斗争决定迁移zabbix的mysql，瓶颈和对稳定的追求之间迟疑了下。最后决定进行，同时参照github当年迁移Mysql的方式，写了类似的checklist，耗时不计

1.主从服务器的搭建，主要的困境在于mysql的版本上，之前的版本是Nysql5.6 ，然后决定降级到Mysql 5.5，rpm安装，找repo找了好久。2015年04月27日 进行，耗时2小时

2.主从服务器搭建结果的测试，耗时较短。2015年04月27日进行，耗时约为5分钟。

3.partition procedure相关操作，采用了zabbix org提供的方案，之前就有调研了解过，实际操作耗时较短，2015年04月27日进行，耗时5分钟


4.partition procedure的结果测试，耗时较短。2015年04月27日进行，耗时5分钟

5.原始表数据的导出，导入脚本书写，测试，耗时较短。业务简单，自己shell写的很熟练，没遇到bug。2015年04月27日进行。耗时大约30分钟

6.数据导出时间测试，数据导出大约用了2min06s，这里直接放弃了history*和trend*等表的数据。2015年04月27日进行。大约耗时10分钟

7.数据导入时间测试，原始的数据库导出的数据导入到新版的数据库耗时大约用了2mins。测试通过。2015年04月27日进行。大约耗时10分钟

8.zabbix-server配置文件的修改，主要是修改dbhost等信息，修改后记得vimdiff查看异同。2015年04月28日进行，大约耗时5分钟

9.zabbix-server到mysql master登录帐号的创建和测试。2015年04月28日进行，大约耗时5分钟

===================================================================================
0-7中间会有其他工作事宜的处理耗时为具体执行时间，22点。下班走人，回家，路上，睡觉前想了可能遇到的问题，以及解决方案.
8-9是遗漏的注意事项
===================================================================================
迁移过程的方案，以上的准备只为迁移过程中停机的时间可预测，停机时间足够短。
0.2015年04月28日 10:29:30开始通知可能影响的人，停止http 服务，2015年04月28日进行，耗时2分钟内

1.停止zabbix server，2015年04月28日进行，耗时5分钟

2.登录mysql，show processlist;查看sql执行过程，2015年04月28日进行，大约耗时2分钟

3.zabbix mysql数据导出导入，执行之前的脚本，2015年04月28日进行，耗时大约5分钟

4.在zabbix mysql数据导入导出的过程中，替换了 http php中的数据库连接地址，事先准备好的 zabbix conf文件，并一一做了检查，2015年04月28日进行，耗时大约5分钟

5.启动zabbix server，2015年04月28日进行，时长2分钟

6.watch -n 1 "ps axf|grep 'history syncer'" ，执行此语句，同时 tailf /var/log/zabbix/zabbix_server.log，查看syncer是否工作，各种的item是否become supported，耗时略久，2015年04月28日进行，具体忘了。一直关注zabbix server情况了

7.发现无大碍后，替换了http实现准备好的php配置文件， 启动http 服务，前端页面查看。2015年04月28日进行，2分钟

8.zbx本身的server health screen查看，nvps正常。

9.2015年04月28日 11点整的trends制作 check，没问题，这个过程大约从10:55到11:05

10.初步判断上面的操作成功。2015年04月28日13点10，吃饭回来，check zabbix，没问题。

11.通知相关人员，初步迁移完成

以上迁移完成。
=================================================================================
切记一点，一定保证所有的操作都有备份，大黑同事曾建议我在原有数据库的基础上做三级从库，被我拒绝了，我必须保证原有的主库的最小改动，这样出了问题，可以快速的回切补救。
=================================================================================
以上的所有操作记录在了纸上，现在整理成电子版发到博客，时间为执行过程的粗略计算，从04月27日下午决定开始，经历了折磨，最终在04月28日初步完成。

感谢我的大黑同事，和我一起review所有的过程，以及可能出现问题的地方；跟我一起想出问题的补救办法。

感谢大黑同事忍着尿意(所以我清楚的记得9.2015年04月28日 11点整的trends制作 check，没问题，这个过程大约从10:55到11:05)，一起跟我check trends是否正常。一起check log。感谢！！！！！