|
5 | 5 | 3. 普通用户权限细化控制,危险操作过滤。
|
6 | 6 | 4. 危险操作日志审计。
|
7 | 7 | 5. 所有增删改操作sql异步日志记录。
|
8 |
| -6. mongodb增加热备功能。 |
9 |
| - |
10 |
| -# _**1\. 各种操作时延统计**_ |
11 |
| - |
12 |
| -**开发背景**:mongodb社区版本没有各种时延统计功能,例如想看insert、update、delete、find操作的各种详细时延统计,开源版本没有该功能。 |
13 |
| - |
14 |
| -**解决办法**:给各种增、删、查、改操作增加详细的平均时延、最大时延等统计。 |
15 |
| - |
16 |
| -**收益**:1\. 避免扯皮(例如之前线上某个业务线有一次估值,客户端时延提升了数倍,业务方抖动厉害,但是业务方时延监控包括了调用mongodb的时延及其他业务逻辑,这时候就区分不出来是mongodb抖动引起还是其他业务逻辑抖动引起)。2. 主动发现mongodb抖动问题,没有该功能前,mongodb抖动完全只能靠业务方发现,或者通过mongodb慢日志发现,但是mongodb慢日志记录得是100ms以上的操作,不能精确的反映各种时延问题。 |
17 |
| - |
18 |
| - |
19 |
| -# _**2\. mongos慢日志记录**_ |
20 |
| - |
21 |
| -**开发背景:** 由于mongos代理后端可以由多个sharding分片,例如mongos后端有50个sharding分片,如果我要分析整个mongodb集群的慢日志信息,那么就必现去分析后端50个sharding的慢日志,由于慢日志在每个sharding的主、从上都可能产生,如果每个sharding分片是一主两从架构,那么久必现分析3*50个mongo数据库实例。分析过程复杂繁琐。 |
22 |
| - |
23 |
| -**解决办法:** 由于代理默认部署就3个实例,直接在mongos代理拦截所有流量,记录下和后端sharding的详细慢日志即可。 |
24 |
| - |
25 |
| -**收益:**简化了慢日志收集分析过程,可以更快速的发现不合理的查询、写入等引起的慢日志。 |
26 |
| - |
27 |
| - |
28 |
| -# _**3\. 普通用户权限细化控制、危险操作过滤**_ |
29 |
| - |
30 |
| -**开发背景:** mongodb普通用户权限默认拥有所有操作权限(包括删库、删表、建索引等),除非在创建账号的时候通过privileges来指定actions,如果通过privileges来指定actions会非常麻烦,因为mongodb有数百个不同actions操作。此外,业务方还得根据自己实际情况来梳理代码使用的action操作,如果想增加某种action,还得提各种申请添加,限制了业务方使用灵活性。 |
31 |
| - |
32 |
| -**解决办法:** mongodb中增加普通用户权限控制并对各种危险操作进行过滤,只要是普通用户访问mongodb数据库,就禁止其删库、删表、建库、建表、建索引等危险操作。 |
33 |
| - |
34 |
| -**收益:** 通过在mongodb中增加普通用户权限控制、危险操作过滤,增强了mongodb权限控制及稳定性功能,同时也使得业务方可以随意使用各种不同的action,使用也更加灵活。 |
35 |
| - |
36 |
| - |
37 |
| -# _**4\. 危险操作日志审计**_ |
38 |
| - |
39 |
| -**开发背景:** 数据库管理人员具有数据库root权限,拥有删库、删表等危险操作权限,如果误操作,将会带来巨大损失。如果某个库被恶意删除,怎么确定是由那个用户删除的?通过那台客户端登录的,什么时候做了该操作? |
40 |
| - |
41 |
| -**解决办法:** 增加危险操作日志审计功能,记录这些危险操作的详细信息,包括用户、IP地址、key信息等。 |
42 |
| - |
43 |
| -**收益:** 快速定位是由哪位管理员恶意操作引起。此外,如果是业务方使用了删库、删表的操作,同样会记录下整个详细操作信息。 |
44 |
| - |
45 |
| - |
46 |
| -# _**5\. 所有增删改操作sql异步日志记录**_ |
47 |
| - |
48 |
| -**开发背景:** 场景1\. 业务方感觉某个数据丢了,怀疑是数据库丢数据了。但是mongodb管理员觉得mongodb很稳定,不存在丢数据的情况,管理员觉得是客户端自己删除了,究竟是业务方自己删的还是mongodb丢数据呢? 场景2. 业务方在某个时间段做了几个误操作,误删除了一些数据,想找出在这个时间段内误删除的具体数据。 |
49 |
| - |
50 |
| -**解决办法:** 把所有的增、删、改操作过程详细记录下来。 |
51 |
| - |
52 |
| -**收益:** 1\. 避免扯皮。2.业务方想要的任意时间段的操作数据都可以获取出来,便于他们进行问题分析排查。 |
53 |
| - |
54 |
| - |
55 |
| -# _**6\. 给mongodb增加热备功能**_ |
56 |
| - |
57 |
| -**开发背景:** mongodb社区版本没有热备功能,如果需要备份数据库数据,需要对某个Mongod实例下线进行冷备。或者通过mongodump工具进行主从数据备份(该工具就是模拟mongodb的slave先做全量数据同步,然后拉取Oplog进行增量同步)。如果是冷备,需要停机某个副本,等cp拷贝整个mongodb数据完成后,然后在继续上线,这种备份方式需要下线实例对业务影响比较大。如果是通过mongodump方式模拟slave来拉取数据,在全量数据拉取过程中,会占用较大带宽,业务方时延会有较大抖动。此外,通过mongodump工具拉取数据非常慢,线上拉取400G数据需要10个小时左右,如果需要增加一个slave,通过这种方式完全不可接受。 |
58 |
| - |
59 |
| -**解决办法:** 借助wiredtiger存储引擎机制,增加热备功能。 |
60 |
| - |
61 |
| -**收益: 1\.** 热备期间对业务影响较小。2\. 备份数据时间降低百倍数量级,例如400G数据通过mongodump方式需要10小时,但是通过热备方式只需要几分钟即可。 |
| 8 | +6. mongodb增加热备功能。 |
| 9 | +...... |
62 | 10 |
|
63 | 11 | 如果对mongodb数据库和wiredtiger存储引擎源码感兴趣,可以参考如下注释:
|
64 | 12 |
|
|
0 commit comments