mongodb数据迁移2种方式比较

尝试了2种方式对数据进行迁移,一种是rsync,直接拉取数据;另一种是使用mongodump/mongorestore 1.rsync 操作步骤: 1.2: [mongodb] path = /data1/mongodb/data hosts allow = 192.168.1.0/24 read only = no write only = no 1.3: rsync -avz root@192.168.1.2::mongodb/dbname /data/mongodb-linux-x86_64-1.8.1/data/ chown -R mongodb:mongodb /data/mongodb-linux-x86_64-1.8.1/data/ 使用时间:50分钟 到目标服务器数据:50G 优点:使用时间短 缺点:需要配置rsync,数据占用的空间大(数据原封不动的拉取过来,包括碎片) 2.mongodump/mongorestore 操作步骤: mongodump: /data/PRG/mongodb/bin/mongodump –host 192.168.1.2:27017 -d dbname -uuername -ppasswd -o /data/mongodb-linux-x86_64-1.8.1/data/ –directoryperdb mongorestore: /data/mongodb-linux-x86_64-1.8.1/bin/mongorestore –dbpath /data/mongodb-linux-x86_64-1.8.1/data/ –directoryperdb /data/dbname/ chown -R mongodb:mongodb … Continue reading "mongodb数据迁移2种方式比较"

mongodb sharding cluster(分片集群)

MongoDB的auto-sharding功能是指mongodb通过mongos自动建立一个水平扩展的数据库集群系统,将数据库分表存储在sharding的各个节点上。 通过把Sharding和Replica Sets相结合,可以搭建一个分布式的,高可用性,自动水平扩展的集群。 要构建MongoDB Sharding Cluster,需要三种角色: Shard Server: mongod 实例, 使用 Replica Sets,确保每个数据节点都具有备份、自动容错转移、自动恢复能力。用于存储实际的数据块,实际生产环境中一个shard server角色可由几台机器组个一个relica set承担,防止主机单点故障 Config Server: mongod 实例,使用 3 个配置服务器,确保元数据完整性(two-phase commit)。存储了整个 Cluster Metadata,其中包括 chunk 信息。 Route Server: mongos 实例,配合 LVS,实现负载平衡,提高接入性能(high performance)。前端路由,客户端由此接入,且让整个集群看上去像单一数据库,前端应用可以透明使用。 环境如下: 192.168.198.131 shard1:10001 shard2:10002 shard3:10003 config1:20000 192.168.198.129 shard1:10001 shard2:10002 shard3:10003 config2:20000 192.168.198.132 shard1:10001 shard2:10002 shard3:10003 config3:20000 192.168.198.133 mongos:27017 分别在三台服务器上安装mongod服务,安装如下: # wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz # … Continue reading "mongodb sharding cluster(分片集群)"

mongodb的NUMA问题

mongodb日志显示如下: WARNING: You are running on a NUMA machine. We suggest launching mongod like this to avoid performance problems: numactl –interleave=all mongod [other options] 解决方案: 1.在原启动命令前面加numactl –interleave=all 如# numactl –interleave=all ${MONGODB_HOME}/bin/mongod –config conf/mongodb.conf 2.修改内核参数 echo 0 > /proc/sys/vm/zone_reclaim_mode http://www.mongodb.org/display/DOCS/NUMA 下面注释转自网络 一、NUMA和SMP NUMA和SMP是两种CPU相关的硬件架构。在SMP架构里面,所有的CPU争用一个总线来访问所有内存,优点是资源共享,而缺点是总线争用激烈。随着PC服务器上的CPU数量变多(不仅仅是CPU核数),总线争用的弊端慢慢越来越明显,于是Intel在Nehalem CPU上推出了NUMA架构,而AMD也推出了基于相同架构的Opteron CPU。 NUMA最大的特点是引入了node和distance的概念。对于CPU和内存这两种最宝贵的硬件资源,NUMA用近乎严格的方式划分了所属的资源组(node),而每个资源组内的CPU和内存是几乎相等。资源组的数量取决于物理CPU的个数(现有的PC server大多数有两个物理CPU,每个CPU有4个核);distance这个概念是用来定义各个node之间调用资源的开销,为资源调度优化算法提供数据支持。 二、NUMA相关的策略 1、每个进程(或线程)都会从父进程继承NUMA策略,并分配有一个优先node。如果NUMA策略允许的话,进程可以调用其他node上的资源。 2、NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind规定进程运行在某几个node之上,而physcpubind可以更加精细地规定运行在哪些核上。 3、NUMA的内存分配策略有localalloc、preferred、membind、interleave。localalloc规定进程从当前node上请求分配内存;而preferred比较宽松地指定了一个推荐的node来获取内存,如果被推荐的node上没有足够内存,进程可以尝试别的node。membind可以指定若干个node,进程只能从这些指定的node上请求分配内存。interleave规定进程从指定的若干个node上以RR算法交织地请求分配内存。 三、NUMA和swap的关系 可能大家已经发现了,NUMA的内存分配策略对于进程(或线程)之间来说,并不是公平的。在现有的Redhat Linux中,localalloc是默认的NUMA内存分配策略,这个配置选项导致资源独占程序很容易将某个node的内存用尽。而当某个node的内存耗尽时,Linux又刚好将这个node分配给了某个需要消耗大量内存的进程(或线程),swap就妥妥地产生了。尽管此时还有很多page cache可以释放,甚至还有很多的free内存。 四、解决swap问题 … Continue reading "mongodb的NUMA问题"