数据库开发环境一键式交付的设计思考

数据库开发环境一键式交付的设计思考

最近因为一些工作内容的调整，准备完善下开发环境的建设，让原本游离的环境管理更加合理。简单总结了下，数据库开发环境存在一些潜在隐患和瓶颈：

1)目前公司内的数据库开发环境是业务自主建设，没有DBA协助支持，有的部门会购买专门的服务器部署，有的会复用一些IDC的服务器资源，使用方式较碎片化

2)数据库开发环境基本上不会有备份配置，在出现服务器异常时难以恢复

3)数据库开发环境的版本管理缺乏规划，通常是选择最新或者已有的过旧版本，上线时会存在功能的兼容性问题，如使用了基于JSON数据类型，但是线上数据库版本依然不支持等，或者是数据库驱动的升级变动在测试环境没有充分测试可能会导致线上业务访问异常

4)数据库开发环境和测试环境的使用是混乱的，开发环境更偏向于开发人员个人自主使用，使用权限相对较大，更适合于办公机使用，可以自主创建表，变更表和基本的数据增删改查，而测试环境是在完成基础开发后进行功能集成测试时使用，需要应用测试服务器来访问

对于开发环境，测试环境，预发布环境和线上环境的整体规划如下，其中开发环境主要基于单机版，主要建设目标是提供高效的支持。

设计参考项：

1. 数据库开发环境的申请过程不需要审批，不需要填写复杂的表单等。

2. 开发人员的数据库使用配额，每个人最多可以申请创建5个数据库，累计存储空间最大不超过10G，且多个数据库实现集中部署(如单实例的多个数据库等)

3. 开发环境默认基于WEB端工具支持，办公机权限访问需基于Workbench使用

4. 数据库版本目前提供基于8.0和5.7两个版本，不支持5.5版本

5. 数据库基于InnoDB存储引擎，所有表需要有主键，不建议使用存储过程

6. 开发环境均为单机使用模式，在服务器异常时支持通过数据库恢复来还原数据

7. 为了避免数据库命名混乱和重复，默认数据库的命名规则为devdb【序号】，如devdb1,devdb2等

8. 如创建的数据库在1个月内没有使用记录，则会在1个月后自动生成相应的数据库备份归档，并将数据库资源释放

9. 开发环境不支持drop操作，会提供统一的数据库回收站和使用方式，要删除的表需要归置于回收站中由运维侧不定时回收

10. 开发环境不提供基于时间点的恢复，目前默认为每日全量备份，保留近15天的备份文件

11. 如对开发环境进行自助备份归档，则可以支持基于逻辑备份的数据恢复，数据恢复为全覆盖模式

12. 开发人员的数据库之间是隔离的，不允许互相跨库调用和依赖

13. 数据库账号基于开发人员域名，在忘记密码时可以使用密码重置功能，提供新的随机密码

14. 开发环境不提供高性能测试支持，仅为功能开发测试所用

15. 运维侧不支持线上数据库数据导入开发环境

16. 数据库字符集暂定为UTF8, 如有UTF8MB4等字符集，可以由业务侧自行创建时指定

17. 每个实例上的数据库最多为50个

整体的设计流程如下所示：