这周开始下起了秋雨，朦朦胧胧，不是很大，但是有风，尽管有伞，胳膊裤子还会被淋到。我的DBA工作也随着秋风的到来秋雨的落地，暂时告一段落了，第一份工作就这样夭折了，曾经满怀激情信心满满要成为一名优秀的MySQL DBA，要像Peter一样在这行里大红大紫，而如今，只能灰溜溜的离开了。虽然不久前方又会亮起来，但是心里还是多少有些失落，毕竟是第一次进入这个行业，第一份DBA的工作就没有开好头，首先士气上会受到一定的打击，也开始怀疑自己的能力，究竟自己适不适合这个行业，我的性格很浮躁不细心，过于异想天开，这是作为DBA要不得的，虽然已经意识到这些，但是实际中并没有得到控制，心里有些担心，害怕以后会再次跌倒。心情很复杂，已经休息有两个星期了，也在慢慢调整自己。下面说说，近期工作的小故事。

之前的一段时间，工作趋于稳定，没有过多的波动了，除了日常的琐事，就是配置replicaton以及更新维护脚本，也没有什么提高了。就像上周面试的时候PICA的一个项目技术总监，问我平时都做什么，听完后，便诧异的问：你这个DBA，似乎每天都没有什么事情呀！我自己想想，也是哦，真的想不出都做了点什么有技术的工作，那怎么每天每天还不把自己弄的跟个忙人似的，我很脸红，5个SQL题，没有一个能够写对，就这样还志高气昂的想做DBA，最基本的SQL都写不明白，哎…我沉默了，无言以对。还有一点，感触就是，自己做事情真的不到位，从来没有说我要把一件事一个脚本写到“极致”，做到精益求精，没有，还是没有，失败呀！

1. 存储过程(SP)的权限

之前工作中偶尔遇到些存储过程，于是就顺便了解了下SP的权限的分配。当我们去Create Procedure的时候，会用到这样一个关键词DEFINER，它后面接一个账号‘user’@’ip/host’，这个属性可以定义该SP所有者，如果不指定的话，就是执行该Create操作的当前用户；另一个属性是SQL SECURITY，它有两个选项，其中一个就是刚提到的DEFINER（默认），另一个是INVOKER。和SP相关有这么几个权限在权限表中，分别是create routine、alter routine、execute。其中，create为创建权限；alter为修改和删除权限；execute为调用sp的权限。下面就来说说SQL SECURITY [DEFINER | INVOKER]有什么不同。

如果我们指定SQL SECURITY DEFINER，当我们去调用SP的时候，那个去执行SP的body中的内容的时候，将是以definer后面定义的账号去执行的，所以，该definer的账号，需要具有execute外，还需要具有能够执行body中对应sql语句的权限，而执行call的这个帐号只需要被赋予对该SP有execute权限即可；如果指定的是SQL SECURITY INVOKER，那么这时就和之前我们定义的definer没有任何关系了，这时就需要调用该SP的帐号同时具备execute权限以及执行body中对应sql语句的相应权限。我们可以通过show create procedure db_name.sp_name\G查看SP的body，可以通过show procedure status like ’sp_name’\G查看SP的创建信息（比如：definer\created time\modified time）。但是，发现，只有root用户和definer的用户看到SP的body内容，其他用户都看到，难道这是MySQL处于安全的考虑的原因吗？

2. Binlog问题

故事的起因是这样的，一款游戏后期为了分析一些东西需要用到对游戏库中的数据以及日志库中的数据，而这两个库分别在两个实例下面运行，开发人员的存储过程执行在一个实例下去完成对两个库的统计，这就需要将这两个库每天要将数据导入到一个实例下面。处于数据库复杂度的考虑，之初我是计划通过replication将游戏库中各个库的数据从该库的从库同步过来（A->B->C），然后再通过脚本（mysqlbinlog |mysql）将日志库中的数据导入到同一个实例下，但是由于某些原因（记不得了）被人制止了，现在回想起来，我的做法也没有问题的。这因为没有，所以，才有机会遇到下面这个问题：）最后，采取都通过脚本，每天将当天产生的BINLOG导入到同一个实例下，就在我离开的前几个星期，问题出现了，每天早上我查看脚本的log文件的时候，游戏库的binlog导入遇到了问题，总是提示某个要操作的表不存在，导致导入终止。这是为什么？为什么之前一直都正常呢，而最近才出现这个问题呢？我找到提示不存在的这个表，发现它是个临时表，我们都知道，临时表是基于当前session的，当连接断开，那么它就会被自动drop掉，而且这个临时表是游戏库中的存储过程产生的。游戏库的架构是M-S,同步没有任何问题，说明存储过程的操作，通过binlog是能够在从库上执行，那为什么，我取从库每天产生的binlog去恢复，就会报错误呢？即便M-S中sql_thread一直在运行，但有也中断的时候，那么为什么不会影响到SP中的临时表呢，而我通过手动去导入binlog的方式就有问题了呢？究竟binlog里面有没有记录下存储过程中的所有记录？因为之前忙于别的，这个问题也就没有查个清楚，希望有兴趣的朋友也帮着想想到底是哪里的问题，大家一起讨论下。

近期的印象里面也就上面这么两个深刻点的，休息这段时间偶尔看看手册，再就是一直在网上看这么一篇文章《NoSQL数据库笔谈》，写的十分不错，里面有些东西看的不是太明白。

中秋要到了，希望大家的工作生活也像天上的明月一样光彩圆满；同时，十一也能好好享受。

“Don’t be Serious, be Sincere.”

建议继续学习：

1. 我对技术方向的一些反思    (阅读：9852)
2. Oracle DBA的学习进阶成长树-从初出茅庐到高瞻远瞩    (阅读：4389)
3. oracle技术方面的路线    (阅读：3312)
4. MySQL DBA修炼秘籍    (阅读：3173)
5. 我的担忧：dba如何在稳定环境中成长    (阅读：3024)
6. DBA有什么个人前途?    (阅读：2689)
7. DBA最缺的不是技术    (阅读：2673)
8. MySQL DBA面试全揭秘    (阅读：2620)
9. 《Oracle DBA手记》一书推荐 - 感谢刘松先生    (阅读：2497)
10. 应用DBA的价值    (阅读：2412)