关于作者
前滴滴出行技术专家，现任OPPO文档数据库mongodb负责人，负责oppo千万级峰值TPS/十万亿级数据量文档数据库mongodb内核研发及运维工作，一直专注于分布式缓存、高性能服务端、数据库、中间件等相关研发。后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》，Github账号地址:https://github.com/y123456yz
Mongodb数据库版本包含企业版本和社区版本，他们的区别是企业版本相比有更多功能，使用企业版本必须购买付费，所以mongodb部分核心功能没有开源。为了增强mongodb集群稳定性，企业需要对开源版本内核进行二次开发，主要包括以下功能模块的开发(增加以下功能后，会有很好的收益)：
- mongos和mongod各种操作时延统计。
- Mongos代理慢日志记录。
- 普通用户权限细化控制，危险操作过滤。
- 危险操作日志审计。
- 所有增删改操作异步日志记录。
- mongodb增加热备功能。
- 。。。
1. 各种操作时延统计
开发背景：mongodb社区版本只有mongod有读写时延统计，没有各种详细时延统计功能，同时mongos没有时延统计，例如想看insert、update、delete、find操作的各种详细时延统计，开源版本没有该功能。
解决办法：给各种增、删、查、改操作增加详细的平均时延、最大时延、P99、P95等统计。
收益：1. 避免扯皮(例如之前线上某个业务线有一次故障，客户端时延提升了数倍，业务方抖动厉害，但是业务方时延监控包括了调用mongodb的时延及其他业务逻辑，这时候就区分不出来是mongodb抖动引起还是其他业务逻辑抖动引起)。2. 主动发现mongodb抖动问题，没有该功能前，mongodb抖动完全只能靠业务方发现，或者通过mongodb慢日志发现，但是mongodb慢日志记录得是100ms以上的操作，不能精确的反映各种时延问题。
2. mongos慢日志记录
开发背景: 由于mongos代理后端可以由多个sharding分片，例如mongos后端有50个sharding分片，如果我要分析整个mongodb集群的慢日志信息，那么就必现去分析后端50个sharding的慢日志，由于慢日志在每个sharding的主、从上都可能产生，如果每个sharding分片是一主两从架构，那么久必现分析3*50个mongo数据库实例。分析过程复杂繁琐。如果是分片模式，mongod记录的慢日志少了代理mongos到mongod这一段的时延。
解决办法: 由于代理默认部署就3个实例，直接在mongos代理拦截所有流量，记录下和后端sharding的详细慢日志即可。
收益：简化了慢日志收集分析过程，可以更快速的发现不合理的查询、写入等引起的慢日志。
3. 普通用户权限细化控制、危险操作过滤
开发背景: mongodb普通用户权限默认拥有所有操作权限(包括删库、删表、建索引等)，除非在创建账号的时候通过privileges来指定actions，如果通过privileges来指定actions会非常麻烦，因为mongodb有数百个不同actions操作。此外，业务方还得根据自己实际情况来梳理代码使用的action操作，如果想增加某种action，还得提各种申请添加，限制了业务方使用灵活性。
解决办法: mongodb中增加普通用户权限控制并对各种危险操作进行过滤，只要是普通用户访问mongodb数据库，就禁止其删库、删表、建库、建表、建索引等危险操作。
收益: 通过在mongodb中增加普通用户权限控制、危险操作过滤，增强了mongodb权限控制及稳定性功能，同时也使得业务方可以随意使用各种不同的action，使用也更加灵活。
4. 危险操作日志审计
开发背景: 数据库管理人员具有数据库root权限，拥有删库、删表等危险操作权限，如果误操作，将会带来巨大损失。如果某个库被恶意删除，怎么确定是由那个用户删除的？通过那台客户端登录的，什么时候做了该操作？
解决办法: 增加危险操作日志审计功能，记录这些危险操作的详细信息，包括用户、IP地址、key信息等。
收益: 快速定位是由哪位管理员恶意操作引起。此外，如果是业务方使用了删库、删表的操作，同样会记录下整个详细操作信息。
5. 所有增删改操作异步日志记录
开发背景: 场景1. 业务方感觉某个数据丢了，怀疑是数据库丢数据了。但是mongodb管理员觉得mongodb很稳定，不存在丢数据的情况，管理员觉得是客户端自己删除了，究竟是业务方自己删的还是mongodb丢数据呢？ 场景2. 业务方在某个时间段做了几个误操作，误删除了一些数据，想找出在这个时间段内误删除的具体数据。
解决办法: 把所有的增、删、改操作过程详细记录下来。
收益: 1. 避免扯皮。2.业务方想要的任意时间段的操作数据都可以获取出来，便于他们进行问题分析排查。
6. 给mongodb增加热备功能
开发背景: mongodb社区版本没有热备功能，如果需要备份数据库数据，需要对某个Mongod实例下线进行冷备。或者通过mongodump工具进行主从数据备份(该工具就是模拟mongodb的slave先做全量数据同步，然后拉取Oplog进行增量同步)。如果是冷备，需要停机某个副本，等cp拷贝整个mongodb数据完成后，然后在继续上线，这种备份方式需要下线实例对业务影响比较大。如果是通过mongodump方式模拟slave来拉取数据，在全量数据拉取过程中，会占用较大带宽，业务方时延会有较大抖动。此外，通过mongodump工具拉取数据非常慢，线上拉取400G数据需要10个小时左右，如果需要增加一个slave，通过这种方式完全不可接受。
解决办法: 借助wiredtiger存储引擎机制，增加热备功能。
收益: 1. 热备期间对业务影响较小。2. 备份数据时间降低百倍数量级，例如400G数据通过mongodump方式需要数小时，但是通过热备方式只需要几分钟即可。
7. 链接耗光，无法登陆mongod和mongos实例
可以新增特定端口或者特定IP放开最大链接数限制
8. 其他
