月度存档: 一月 2012

关于Mongodb的oplog

oplog是Replica set模式中的核心部分,通过它来同步不同服务器之间的数据,之前忽略了对它的配置而导致了一些小问题。

首先oplog的size是可以设置的,默认的大小是数据所在硬盘的5%大小。oplog大一点可以储存更多的操作日志,当SECONDARY当机时可以提供更多的恢复时间,但是要衡量机器内存的大小,最好留出足够的表空间之后,再分配合适的大小。

现在我们就遇到了一个比较尴尬的问题,PRIMARY服务器都是大内存的,但是硬盘是较小的高速硬盘;备机则是大容量低速硬盘+小内存,而且只采用了默认的oplog size设置,这就导致了备机的oplog表占用的大小远大于主机的oplog表,实际上起作用的只是主机上oplog的内容,却让备机的空闲内存数量长期为空,甚至出现了一些load升高的问题。

Mongodb的可选构架和安全配置

上一个项目使用了Mongodb,它的结构是十分灵活的,能够更方便的的建立高可用性和易扩展的数据仓库。

下面是mongodb的几种构架方式,逐一进行一下简要介绍。

第一种是简单的主从方式,这种方式下可以指定一个主库和多个副库,主库读写,副库做备份,当然也可以用作只读库。这种方式比较简单而且没有实现自动故障处理,不做细节介绍。

第二种是Replica方式,这也是一种类主从的方式,主库写,副库读,当初始化数据库连接时,需要指定多个(但不是全部)数据库节点。当主库出问题时,这种方式下可以自动从副库中选出更新时间最接近的一个库提升为主库,其他的作为副库,也可以通过优先级判断。当主库恢复的时候,可以将其加入Replica set,再将其提升为主库。

第三种是Sharding方式,sharding是指分片,将不同的数据部分放到不同的数据服务器上,同时每个片可以是单点,也可以是Replica set,这样就实现了高性能和安全。片也是可以后期加入,mongo将自动分配压力到不同分片,把新数据放到新的分片上但是不会移动老的数据,所以如果想要更好的分配各分片的压力,需要设定更合理的拆分键值和方式。

我们的服务由于数据条目数量巨大,又需要排除单点,保证可用性,故选用了Sharding+Replica set的方式。

//=======

下面简要说一下mongodb的安全验证:

单点的mongo可以设定各库的用户名密码,很简单不消说,当需要对Replica set和sharding方式增加用户验证就麻烦一些,现在版本(2.0.2)已经实现了这两个方式的用户验证,不过需要对每个点增加秘钥。

秘钥是一串6-1024位的base64编码方式的字符串,每一个介入的mongo服务(包括replice,shard,config和monogs)的配置中都需要包含这个key文件,之后可以在admin库中设置密码,当设置好密码之后,访问所有配置功能和已有用户的数据库就需要用户名密码验证之后才能通过了。

mongo的权限设置仍然稍微简单,比如并没有对某库的只读权限等的细分,希望以后的版本可以增加吧。