工作疑难问题解决5例

   记录一下工作上疑难问题解决：

    一，方便的页面监控  

     前几天早上，负责的kettle抽取数据表的任务又报错了，早上看手机有4个未接报警电话，一看是人员表，原来昨天报表系统有个大的查询一直未查询完成，导致truncate这个人员表，无法获取meta元数据锁，后续执行kettle抽取和SQL计算的都报错。为解决以前这个很偶发的大查询，特意用datart报表做了一个查询页面，在手机上直接看是否有大的事务查询，有的话kill，保证晚上抽取不会报错，但后面一直天天看，也会放松疏忽。

      不想被短信电话打扰如何解决？不要特别的点开看这个查询页面，又保证能天天看到。

      方法一：报表库购买一个从库，报表读和数据写入计算分离就可解决。  需购买从库，要费用，估计不会批

      方法二：做一个监控工具，如果报表库有大的查询报警或者是发送消息!    也会导致让人烦，入侵性强。不太好

      方法三： 在浏览器里把这个长事务页面设置成首页，每次打开浏览器就可以看到。 很友好，每天都会上网，上网就就会看到，非入侵性  

   二、缺少的数据库备机

        几年前，在一家电商公司做DBA，北京仓库有台数据库服务器(线上的数据抽取到本地作业)，但一直没有备机，几次和研发领导说这个事情买个备机做实时备份，领导也没说买，估计到CEO老板也不会同意买，公司当时也很缺钱，但这个隐患一直存在，假如某天这个数据库服务器出现故障，无法使用，就很影响到现在的仓库作业，这时再去弄备机，时间很长。

        不给买备机怎么处理？无法做一个实时备份，等出问题再说。跟领导说了几次，估计他也没办法！

        后来有次上海仓库，突然停电，当初配置了一个从库，没什么问题就系统和数据库都起来了。我把这个担忧给领导又说了一遍，担心如果北京仓库断电重启不起来，那就麻烦了，后来领导说买个高配的台式机做一下过度，是否可以，想想有个备机总比没有强，就立刻购买一台高配的兼容机，弄好配置从库。这才解决，后面再新加仓库配置本地数据库服务器，都是按一主一从库来购买。 

   三、表重构高风险

       几年前，公司的线上系统使用的优惠卷表，以前设计存在严重问题，要重新设计表，修改程序。优惠卷就2个表，表重构和程序修改比较容易，但上线，研发出现一个问题，因为代码分布在各个系统，以前维护这块的人都离职了，现在谁都无法了解全部！有以下2个风险点：

        1，不知道程序都改完没有   

        2，即使程序改完了，是否程序还有坑，出现问题，对用户影响很大。

     没办法保证100%的修改完成，也同时没法保证上线后100%不出问题。

      一句话：修改上线风险大，出问题还要背责任。

     和研发，架构还有领导开会讨论时，面临这个问题，怎么处理？ 讨论下来就是，出一个双写方案，就是新表和旧表同时运行，程序设置开关，可以直接打开双写。上线后，架构开发一个功能程序，对比两边的表的数据是差异，一直对比，有异常就看程序那些还没改，改得有问题。

    就这样整个双写程序功能运行1年多，对比确认没问题后，这才切换完成，并保证切换系统100%没有问题。

   四、大表拆分

        几年前，去新公司的数据库有个表比较大占用100G+的空间，核心库500G+大小，这个表如果有问题，会影响到核心业务库，最好是迁移出核心库。当时负责这块的研发在广州，我在上海。和负责这块的研发领导沟通，反馈是工作太忙，没有时间，要么排期（排期不知道排到什么时候）。

        而且当时公司研发文化，以结果目的为导向，只看重结果。这个工作又不是他们的核心业绩，即使做了也不一定有好的绩效。但如果不推动这个事情，后面表越来越大，风险也越来越大，必须要做下去，慢慢做，总有做完的那天，如果一直没时间做，就永远不会做。

        只是一个小DBA，没有权利去要求他们做什么，怎么推动这个事情解决？

        后来和广州研发部门的组长和经理沟通，研发的确很忙，和研发组长和经理多次沟通，这拆分还要做，但可以慢慢做，他们最后还把拆分任务分下去，哪个研发人员有空就分配给谁，修改一部分。刚好当时做一个MySQL的审计：

             1，用ELK分析每天4亿多条腾讯云MySQL审计日志(1)--解决过程

       每次程序修改了，可以通过ELK去查是否修改完成，是否还有其他遗漏的地方，一开始给他们开了ELK权限，后来又担心数据安全问题，又给取消了。就这样，每次上线，修改一部分，自己在钉钉群里通告一下是否改完，还有那些没改，监控出没改的SQL，发给他们修改，就这样，整个程序修改都半年多，终于把这个表给拆分出核心库，一句话说的好：真是世上无难事，只怕有心人。

        修改上线后，在例行每次优化报表邮件中，特意写了一份表扬信（写这个表扬邮件费点劲），对广州研发的同事表扬，他们的研发总监还特意点赞回复。邮件如下：

        

      五、电商系统核心发布配置数据库迁移 

           公司是线上电商网站，其发布配置库以前一直在一个主库的从库建的数据库，随着这个配置系统大量使用，其越来越重要性，要把这个配置库从库迁移主库上，避免从库故障的影响，因为如果这个从库实例故障，整个公司的发布配置就出大故障，恢复时间长。怎么处理？

          从2017年开始推动该发布配置数据库迁移新实例，无法得到研发，架构，运维等一致支持，主要担心迁移出故障问题，2018年底，公司为保证通过等保三级，特批6个小时线上停机维护时间，为抓住该机遇，特意协调开会推动研发，架构和运维等，说这个是好机会，必须迁移，和他们一起讨论迁移方案，在得到领导的同意下，在停机时间内完成迁移到新实例。

 

    总结：

              1，这个大表拆分能完成，不是靠一再的施压和只看结果，而是真正去了解他们的实际情况，给研发真正提供方便高效的帮助，大家齐心合力去完成一件事。

              2，古语说：天时地利人和

                  当做成一件事时，有决心，但没有人支持，同时没有好的时机，就做不成，如这个发布配置库迁移，一旦出现好的时间机会（系统停机6个小时维护），这个就可以推动大家达成共识，并得到领导的同意支持，这时天时，地利和人和都有了，就可以完成。