Mongodb管理与维护

本篇使用Mongodb版本为3.2.6。 Mongodb是json格式的文档数据库,优点是存储灵活、查询语法比较丰富、拥有良好的failover机制和伸缩能力、性能良好、易用。当然也有很多不足之处,比如不支持事务、join查询支持的不好等。这些与其价值定位有很大关系,有得必有失,没有各方面都很极致的产品。只要能在某些方面做的足够好,就能在其适合使用的场景下实现价值。 控制脚本与配置文件 Mongodb集群由分片(shard)、配置中心(config)、路由(mongos)三种节点组成。其中shard存储业务数据,可以配置多个副本;config存储分片表的元数据和块分布信息,可以配置多个副本;mongos自身不存储数据,而是直接与config通信查询或更新config的数据。各自的启动配置文件(YAML格式)示例如下: sh

Mongodb跨数据中心部署实践

公司某休闲游戏的海外应用服务器和Mongodb数据库服务器都部署在了AWS美国东部某数据中心。最近为了降低欧洲用户的访问延迟,打算尝试使用Mongodb的zone sharding特性实现数据跨欧洲、北美两个数据中心,并在欧洲再部署一套应用服务器直连欧洲的数据库服务器。再通过AWS的Route 53(域名系统)的地理策略,依据其ip位置将用户分流到欧洲、北美两个入口,从而实现用户就近访问后端服务器,本地读写数据。 动手前先从架构和业务两方面思考有哪些需要解决的问题,尽可能避免一些弯路,做好充分的准备。 问题及解决方案 选择跨数据中心的网络连接方式 这里需要考虑安全和稳定两方面因素。分别调研了以下三种方式: VPC Peering Connections(对等连接),这个适用于同一数据中心里跨账户或跨VPC间的子网互连,目前

Mongodb集群压力测试与性能调优

实验设备 用于mongodb集群节点的设备 主机:8台 CPU:8核Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 内存:32G 磁盘:SSD 系统:Linux 3.10.0-229.el7.x86_64 CentOS 7.1 运行环境 集群:使用mongodb-3.2.6,每台主机一个shard组成分片集群,每台主机一个路由(mongos)作为入口。 准备工作,参考官方文档: 关闭透明大页。 关闭atime。 增加mongodb运行用户的最大进程数。 实验数据和方法 数据库和集合开启分片后导入bson格式数据文件。 小文档数据: data : 697.67MiB docs : 17013091 avg obj size :43B 大文档数据: data : 64.33GiB docs

Mongodb集群环境下的数据备份与恢复

当mongodb在生产环境运行时,我们除了要保障运行稳定(高可用),还要尽最大可能保障数据安全。通常会思考各种可能出现问题的因素,比如: 配置服务器(configdb)数据没了 分片(shard)数据没了 集合被drop了,数据库被drop了 configdb和shard由于在集群环境下,通常会做多个副本,运行在不同的主机上。一方面提高了可用性,另一方面避免了因为某些磁盘损坏导致的数据丢失。 但是如果有人登入db,有意或无意批量删除了不该删除数据;或者十分不巧,同一shard的所有副本都同时坏的找不回数据,这时我们还需要其他措施进行补救。以下是几个常用的方案和思路。 增加延时同步的副本节点 参考官方文档-延时同步的副本节点 延时同步的副本节点在拿到oplog后不会立即执行,而是等待一段时间后才执行。在一定程度上可以避免因为

Mongodb经验小结

本篇使用Mongodb版本为3.2.6。 在mongodb里执行某些操作时,可能因为输出内容太多而难以查看。办法是先输出到文件再打开查看。 oplog保存在local库的oplog.rs表中,它是个capped collection,默认5%的可用磁盘空间。如果设置过小,且在数据更新操作繁忙的时候创建新副本,会导致新副本集变secondary失败,查看日志会看到相关内容。 mongos进程占用的内存在某些情况下可能会持续增长直到触发oom-killer,导致mongod躺枪,见/var/log/messages。 各项配置中建议使用hostname代替ip,方便组件迁移。 查看shard日志中执行时间大于1000毫秒的操作。 如果日志中提示存在大量jumbo块且需要手动切割执行以下命令。如果目标collection有chu

Mongodb集群搭建与应用

本文基于3.2.3版本搭建最小规模的mongodb分片集群,将简单介绍基本概念和搭建过程,并总结一些使用经验。 基本概念 路由(mongos) 请求的入口,所有请求都经过mongos协调和分发。通常部署多个实例,以便当一个mongos失败时,应用层驱动可以切换到其他正常的实例上。此外也可以通过一组mongos实例实现“池”的概念,在与应用层之间增加一层用于负载均衡的代理,将请求分配到“池”中的mongos实例上。mongos实例本身并不需要磁盘空间存储数据,它启动时会加载config server中的配置数据到内存,当config变化时会被通知更新。 配置服务器(mongod. config server) 存储整个集群的元数据配置信息(路由、分片),mongos通过这些配置作为导向,将读写请求分发到不同的shard上。

Mongodb命令速查

插入 覆盖保存 更新 删除 查询 索引 特殊数据类型:JSON结构的地理数据(GeoJSON) 特殊数据类型:GeoJSON操作 特殊数据类型:平面坐标数据(legacy coordinate pairs)操作 特殊数据类型:大文件(GridFS)操作 聚合管道(Aggregation Pipeline) 导出导入,备份还原 全文检索 函数(function) 固定集合(Capped Collection) 其他 Type数字对照

Mongodb实战记录

自加入公司以来,接触过的产品如《糖果萌萌消》、《梦幻蛋糕店》、《冰雪奇缘》等,使用的数据库均是mysql+mongodb,其中mongodb承载了99%以上的数据量和访问量。早期受mongodb版本等历史原因的限制,采用的是在应用程序的数据访问层依据userId进行分表,各分表落在不同的mongodb实例上且无副本,虽然分担了负载但可用性较低,如《梦幻蛋糕店》、《冰雪奇缘》和《糖果萌萌消》的最初阶段都是这样。后来随着《糖果萌萌消》用户量不断增长以及mongodb的发展完善,到目前为止数据库层进行了两次较大改变。 第一次改变:使用mongodb分片集群 起因: 旧的集群是以userId%10的方式,用余数关联数据库ip(mongoClient)和mongodb集合名字(collection)。各个mongod实例彼此独立存在