1、写在前面
学习MogDB已经有一段时间了，如果这个时候有这样一个客户，老业务系统随着时间的推进，已经像一个“大泥球”，每个功能都有各种各样的补丁，导致不敢随意修改某个功能，否则就牵一发而动千身，所有的功能只能新增代码，这样这个泥球越滚越大，运维人员已经不堪重负，加上要改革创新以及满足多样化的新业务需求，新建一套基于springboot的微服务应用系统也就迫在眉睫，恰巧数据库就选择了MogDB，这个时候我该如何开展工作那？
2、数据库设计
上图是一个应用的简单逻辑架构，老系统是一个单体的应用系统。新系统拆分出了12个系统。应用做了拆分解耦，各个子系统之间都是通过接口交互，那么数据库设计方案会比较多。
方案一：同一个集群下的同一个数据库多个schema，每个schema服务不同的微服务。
方案二：同一个集群下的不同数据库，每个数据库服务不同的微服务。
方案三：多个集群，每个集群服务不同的微服务。
基于上面三个方案做分析
方案一：运维工作量小，虽然在不同的schema下但是一个数据库下包含了所有的表，不利于后续的扩展，比如可能系统A库需要适应mysql，系统B需要适应Oracle，并且存在不同微服务之间的资源占用；随着业务的积累，数据库也会比较臃肿。
方案二：运维工作量小，不同微服务之间的资源可以通过MogDB的资源负载功能解决，也可以实现不同数据之间分而治之。
方案三：运维工作量大，比如每个集群都要至少一主一备，备份、监控、等运维工作非常繁琐。
通过上面的分析我会使用方案二，如果随着业务的积累，数据量不断扩大，可以把体谅最大、并发量高的数据库剥离出来，重新搭建一个集群，数据库设计简单描述为下图。
数据库搭建一主两备，通过MogHA软件管理高可用。应用连接池通过配置MogHA的VIP连接数据库。另外创建数据库的时候尽量指定字符集和兼容模式，兼容模式可以跟产品的研发数据库版本靠齐。数据库参数参考官方文档中《推荐参数设置》章节，然后根据实际情况对相应参数进行调整https://docs.mogdb.io/zh/mogdb/v3.0/recommended-parameter-settings，另外生产需要开启日志归档、闪回功能、慢sql跟踪功能。
3、业务数据迁移方案
新老系统替换，存量数据过度是一个必不可少的过程，在笔记《mogdb学习-从6开始(MTK)》中已经描述过，关于MTK的功能就不在描述，这里描述另外的手工方法。
编写shell脚本，从老系统中导出按特定格式分割的文本文件，不同的数据库方法比较多Oracle可以使用spool或者sqluldr2.bin；mysql可以使用mysqldump或者select into file；DB2可以使用db2export等。然后在MogDB中使用pg_bulkload进行数据导入，从源系统数据导出的时候需要注意回车换行。
并不是所有老系统的表都需要进行业务迁移，所以导出的时候尽量按照表进行操作，并且这样可以适当的开启并行导出多张表。另外在数据迁移过程中存在一个“中间库”的概念，中间库可以选在MogDB也可以选择与老系统一致的数据库。我们以中间库是MogDB为例，因为MogDB一个集群下的不同数据库是不可以互相访问的，所以中间库在设计的时候为了方便从oldtable插入到不同微服务的newtable，中间库的设计是一个微服务一个schema。
下图是从老信贷到中间库的逻辑架构，oldschema存放与老系统一模一样的表；执行数据加工后把表插入到不同schema的新表中。中间库中的每个newschema对应生产环境MogDB集群中的一个数据库。
中间库数据加工完成后使用gs_dump按照newschema导出多个文件，然后使用gs_restore导入到生产环境中不同的库。
4、数据库日常运维
1、搭建MogDB Manager图形化数据库运维工具（后面笔记会进行测试）。
2、跟踪分析慢sql。
3、定期检查WDR报告。
4、定期数据全量备份+备份归档xlog。
5、主从健康状态监测。
6、定期表空间碎片清理。
5、写在最后
这一篇的标题有点词不达意，其实本意是我学习MogDB已经3周了，遐想出了一个使用MobDB的新项目，根据自己目前的学习情况做了一个知识点应用归纳，在一个项目中如何开展工作。当然并不完善，还有很多优秀的功能还没有了解到。希望通过自己的学习可能更深入的了解MogDB。
