鹏博士机房下线
- oracle今天晚上22:00 正式完成
- Redis本周完成
- MySQL去年完成
- 其他数据库服务也已完成
- 本周结束，这个大麻烦重于能结束了
为什么这么难
- 酒仙桥鹏博士机房是原来的数据库主机房
- 数据库的主实例都是在这个机房
- 我接手的时候没有双机房高可用方案
- 业务连接数据库用的是ip
- 主要的阴力来自oracle方向
- 第一次做计划的时候组内同事跟我说换一个实例要3个小时的停机
- 而且需要几乎全公司的研发测试留下来加班
- 方案是：
- 1.数据库切换机房
- 2.业务修改连接串到新的ip
- 3.开始验证
- 我当时的内心是…
- 于是半年的时间里紧急上线oracle双机房方案
- 一开始我打算自己写一个oracleproxy 做流量转发
- 后来发现性能有问题，长连接不放的bug
- 于是改用f5的流量转发
- 业务修改ip直连数据库改成dns
- (这一步消耗了巨多的时间)
- dns后面挂的是f5的vip
- 这一步做完以后
- 其实数据库跨机房切换就在dba可控范围内了
- 但是这一步修改是真的。。。
- 历史包袱太重
- 原以为很快就能推下去的工作
- 开了N次会
- 各种找研发leader
- 把连接数据库的ip一次次的发给研发去修改
- 大约花了3，4个月的时间
- 才算是把这个工作进行完
- 我们在数据库上看到的连接全是f5过来的流量
- 这时候有新的问题
- 原来的OracleDBA们（注意这个们）
- 因为种种原因集体离职
- 好在新招来的OracleDBA（注意这里没有们）比较给力
- 开始了分批次迁移
- 终于在今天完成了最后一个实例的切换
- 所有切换过程都很快
- 很顺利
- 对业务影响也小
- 只是需要确定时间点
- 留下研发观察即可
- 几乎不需要研发和测试做什么
- 只是帮忙检查业务流程
- 中断时间也基本是在5分钟以内
- 当然我觉得这里还有优化空间
- 但是目前也能接受吧
Oracle转MySQL
- 去年转了一批小实例
- 发现核心逻辑光靠dba转还是很费力
- 今年研发团队人员在缩减
- 业务压力增大
- 目前这个项目我是觉得可以暂停了
- 至少在我的安排里
- 今年不会再推这个项目了
- 非不愿，实不能也
- 这年头研发资源太紧张了
- 再拉着他们去O
- 说实话有点说不出口
自动化
运维平台
- 最近在做偏数据支持类的自动化开发
- 可能最近
- 也许是下周会推一个比较酷的功能上线
- 然后流程类的开发
- 几乎大部分流程都已自动化
- 如果有可能
- 下半年可能会把自动化平台的底层掀了重构一次
- （很大的工程）
DBProxy方向
- Oracle/MySQL的Proxy
- 目前已经完成了第一版
- 确实有个巨大的bug
- 不知道咋解决了
- 主要是go语言用得也不熟
- 这个是受我的技能影响
数据同步平台
- 冬天可能会写一个数据同步平台
- 计划中
xdriver
- 推还是不推
- 还没想好。
其他工作
Redis/SQLServer/Nebula/Neo4j/PG/Mongodb
- 目前这些工作全交给龙哥在处理
- 杂但是工作量不大
- 有没有可能把这些工作组内分摊下
- 可能更多的人参与
- 对大家的技能广度也有提升
bi支持
- 得益于老bi平台的各种性能瓶劲到达
- 目前bi团队的问题经常会卡住
- 主要的原因是
- 老bi的主要逻辑是
1.begin一个事务
2.delete from **表（几万到几千万不等）
3.insert into **表 select * from 连接服务器.**表
4.commit
5.insert into **dw表 select * **表 join group by 各种运算
- 对数据产生了巨大的性能冲击
- 随着时间的积累
- 这个神奇的逻辑越来越慢
- 越来越难以支撑
- 而短时间还没有办法解决
- 我们做为数据库支持方
- 需要在bi同事化解问题前
- 守住最后的底线（数据库服务高效/不崩）
- 哎。。。
日常运维和支持
- 琐事不值一提了
