MySQL数据平台设计规范.docx

MySQL数据平台设计规范主题简介：1、MySQL之备份2、MySQL之安全3、MySQL之SQL规范4、MySQL之系统规划一、MySQL之备份之所以开头就提这个，主要原因是最近的事故略多，删主机、删库、删表、删字段还有勒索病毒等，太多的不可控因素了，从“删XX到跑路”你缺少的只是一个“机会”。本来是你好、我好、大家好，但是万一呢？所以要未雨绸缪，当然备份的意义不仅仅在于此。1、可恢复性首先谈谈备份的可恢复性，或者说是有效性。无论你的备份是在本地、异地、存储、磁带、云上、或者其它不知名处，如果不知道出啥问题丢失了，而且还必须要用这份文件恢复，不能有效的恢复，后果会很严重，所以在系统设计之初就需要规划好。一般而言我们同一份文件需要存放多个位置，三份是个不错的选择。常规的做法是本地一份，其它地方两份，具体的可以根据实际条件酌情处理，通常一份的效验很难有说服力，而且也并不可靠，一定要确保多份副本，从技术的角度而言，奇数是常用的仲裁配置，而三是最小的单位。接下来就是需要经常验证，我这边说的是经常，日常不是很现实，如果资源足够，那就完全可以实施了，这样可以做到心里有底，避免真正在生产执行恢复的时候手忙脚乱，而且主要是可以通过预先准备的脚本或者命令，快速恢复。之所以一定要通过实践去检验，因为通过实际的行为去排雷、排坑、排问题，尽可能地摸清楚将来可能会遇到的可能性问题。虽然可能性为零，不过平时多演练，这样在真正需要的时候才能少掉坑里去。如果说因为各方面的原因你没法去验证，只能通过系统自带的验证或者采取其他的诸如文件效验的方式，这样回到之前说的多副本情况，如果你拥有多分副本，起码验证起来还是比较简单的，但是也并不是说多份副本就一定是有效的，还有时效性等问题。2、时效性这是建立在前面备份可恢复性基础上，首先你的备份是可以支持恢复的，这个接下来需要关注备份的有效性，恢复的效率性。这里面会涉及到RPO、RTO，两者是相互耦合的，RTO要求你越少的时间，RPO要求你恢复到最近时间点的数据，无论哪个方面，有效的解决方案都是更新的备份，更快的恢复效率，最好乃至于瞬间恢复到上一个事务，当前事务。不同的业务级别，需要不同的级别，当然灾备另说。时效性，说实话是属于比较难界定的。那具体需要恢复到什么时间节点的数据呢？根据相应的RPO级别，需要指定相应的计划，而且这其中还需要考虑RTO，如何缩短时间。如果说真的发生了需要从备份恢复的场景，首先需要确定你的数据库拥有完整的备份，但是往往这个时候可能没有最新的，要么就是最近的备份是不成功或者失败，不要觉得我在危言耸听。事实往往比这个更复杂、更加严重，如果幸运的是，你不仅仅拥有多份可靠的而且是最新的备份，还有完美得是到宕机前一刻的增量或者日志，接下来就是跟时间赛跑，稳稳地减少宕机时间。3、安全性安全性放在最后，并不是说不重要，相反，主要高度依赖以上两点，如果脱离了，就片面而言，没有备份，那就是安全的，这是在没有的情况下，不存在其它的情况。然后就轮到有备份了，当你有了备份，你不仅仅需要保证备份的多副本，还要保证其安全性，这里面的安全性包括内部安全，外部安全。很多时候外部反而是安全的，一个有效的备份经历加密、访问控制，别人无论是获取还是解密都需要花费大量时间的，而内部往往更容易出问题，千里之堤，毁于蚁穴。提一下泄密，这个还是比较尴尬的，不论等级划分，笼统来讲，被权限以外的人接触都算，那具体怎么界定，而且权限也是比较难划分的，所以该有的预防措施必须要有。安全无小事，相应的规定章程制定下来就需要严格的执行，剩下的这就需要看从业者的职业操守。PS：如果需要了解备份恢复可以关注下社群文章《解锁MySQL备份恢复的4种正确姿势》，相信可以帮到你。二、MySQL之安全在生产中，安全是相当重要的，毕竟你的核心数据都在里面，MySQL因为其开源的流行性，大量个人、企业、政府单位都采用，但是很多在部署的时候采用都是默认的配置，这就导致了安全的相对欠缺，你需要针对你的安全有所加强。总的来说，数据库一般划分为生产库、压测库、准生产库、测试库、开发库。下面部分主要说的是生产库，但其它库也适用。1、mysql_secure_installation这是数据库基础的安全设置脚本：设置root密码移除匿名用户禁止远程root登录移除test数据库以上是5.6版本，5.7有所加强但也仅此而已，看看你的环境是否存在上述问题，这个算是最基本的安全吧。2、连接访问安全常见创建用户时你需要指定你的IP访问地址范围或者固定IP，一般而言，只有特定唯一的几个IP才会访问，或者说你可以采用代理访问的方式，减少应用直接访问你的数据库，而且现在很多中间件也都有白名单机制，原则上是把非法请求防止在数据库以外的地方。规范数据库管理软件，实现管理软件的标准、统一化，还有严禁杜绝