MongoDB高可用模式部署

首先准备机器,我这里是在公司云平台创建了三台DB server,ip分别是10.199.144.84,10.199.144.89,10.199.144.90。

分别安装mongodb最新稳定版本:

wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.4.12.tgz
tar -xzvf mongodb-linux-x86_64-2.4.12.tgz
mv mongodb-linux-x86_64-2.4.12 /usr/lib

做个软连接或者按照官方的做法把mongo shell都添加到环境变量:

ln -s /usr/lib/mongodb-linux-x86_64-2.4.12/bin/mongo /usr/bin/mongo
ln -s /usr/lib/mongodb-linux-x86_64-2.4.12/bin/mongos /usr/bin/mongos
ln -s /usr/lib/mongodb-linux-x86_64-2.4.12/bin/mongod /usr/bin/mongod

分别创建存储数据的目录:

mkdir -p /data/mongodb && cd /data/mongodb/ && mkdir -p conf/data conf/log mongos/log shard{1..3}/data shard{1..3}/log

分别配置启动config服务器:

mongod --configsvr --dbpath /data/mongodb/conf/data --port 27100 --logpath /data/mongodb/conf/confdb.log --fork --directoryperdb

确保config服务都启动之后,启动路由服务器(mongos):

mongos --configdb 10.199.144.84:27100,10.199.144.89:27100,10.199.144.90:27100 --port 27000 --logpath /data/mongodb/mongos/mongos.log --fork

分别配置启动各个分片副本集,这里副本集名分别叫shard1shard2shard3

mongod --shardsvr --replSet shard1 --port 27001 --dbpath /data/mongodb/shard1/data --logpath /data/mongodb/shard1/log/shard1.log --directoryperdb --fork

mongod --shardsvr --replSet shard2 --port 27002 --dbpath /data/mongodb/shard2/data --logpath /data/mongodb/shard2/log/shard2.log --directoryperdb --fork

mongod --shardsvr --replSet shard3 --port 27003 --dbpath /data/mongodb/shard3/data --logpath /data/mongodb/shard3/log/shard3.log --directoryperdb --fork

接下来配置副本集,假设使用如下的架构,每台物理机都有一个主节点,一个副本节点和一个仲裁节点:

配置shard1(登陆84,没有显式指定主节点时,会选择登陆的机器为主节点):

mongo --port 27001
use admin
rs.initiate({
    _id: ‘shard1‘,
    members: [
        {_id: 84, host: ‘10.199.144.84:27001‘},
        {_id: 89, host: ‘10.199.144.89:27001‘},
        {_id: 90, host: ‘10.199.144.90:27001‘, arbiterOnly: true}
    ]
});

配置shard2(登陆89):

mongo --port 27001
use admin
rs.initiate({
    _id: ‘shard2‘,
    members: [
        {_id: 84, host: ‘10.199.144.84:27002‘, arbiterOnly: true},
        {_id: 89, host: ‘10.199.144.89:27002‘},
        {_id: 90, host: ‘10.199.144.90:27002‘}
    ]
});

配置shard3(登陆90):

mongo --port 27001
use admin
rs.initiate({
    _id: ‘shard3‘,
    members: [
        {_id: 84, host: ‘10.199.144.84:27002‘},
        {_id: 89, host: ‘10.199.144.89:27002‘, arbiterOnly: true},
        {_id: 90, host: ‘10.199.144.90:27002‘}
    ]
});

下面设置路由到分片集群配置,随便登陆一台机器,假设是84:

mongo --port 27000
use admin
db.runCommand({addShard: ‘shard1/10.199.144.84:27001,10.199.144.89:27001,10.199.144.90:27001‘});
db.runCommand({addShard: ‘shard2/10.199.144.84:27002,10.199.144.89:27002,10.199.144.90:27002‘});
db.runCommand({addShard: ‘shard3/10.199.144.84:27003,10.199.144.89:27003,10.199.144.90:27003‘});

查看配置好的shard:

mongo --port 27000
use admin
db.runCommand({listshards: 1});

结果:

{
    "shards" : [
        {
            "_id" : "shard1",
            "host" : "shard1/10.199.144.84:27001,10.199.144.89:27001"
        },
        {
            "_id" : "shard2",
            "host" : "shard2/10.199.144.89:27002,10.199.144.90:27002"
        },
        {
            "_id" : "shard3",
            "host" : "shard3/10.199.144.90:27003,10.199.144.84:27003"
        }
    ],
    "ok" : 1
}

其中仲裁(ARBITER)节点没有列出来。

下面测试分片:

mongo --port 27000
use admin
db.runCommand({enablesharding: ‘dbtest‘});
db.runCommand({shardcollection: ‘dbtest.coll1‘, key: {id: 1}});
use dbtest;
for(var i=0; i<10000; i++) db.coll1.insert({id: i, s: ‘str_‘ + i});

如果dbtest已经存在,需要确保它已经以id建立了索引!

过上一段时间之后,运行db.coll1.stats()显式分片状态:

{
    "sharded" : true,
    "ns" : "dbtest.coll1",
    "count" : 10000,
    ...
    "shards" : {
        "shard1" : {
            "ns" : "dbtest.coll1",
            "count" : 0,
            "size" : 0,
            ...
        },
        "shard2" : {
            "ns" : "dbtest.coll1",
            "count" : 10000,
            "size" : 559200,
            ...
        }
    }
    ...
}

可以看到,这里分片已经生效,只是分配不均匀,所有的数据都存在了shard2中了。分片key的选择策略可以参考官方文档。在2.4版本中,使用hashed shard key算法保证文档均匀分布:

mongo --port 27000
use admin
sh.shardCollection(‘dbtest.coll1‘, {id: ‘hashed‘});

使用hashed算法之后,做同样的测试,插入的数据基本均匀分布:

{
    "sharded" : true,
    "ns" : "dbtest.coll1",
    "count" : 10000,
    ...
    "shards" : {
        "shard1" : {
            "ns" : "dbtest.coll1",
            "count" : 3285,
            "size" : 183672,
            ...
        },
        "shard2" : {
            "ns" : "dbtest.coll1",
            "count" : 3349,
            "size" : 187360,
            ...
        },
        "shard3" : {
            "ns" : "dbtest.coll1",
            "count" : 3366,
            "size" : 188168,
            ...
        }
    }
}

更多资料,请参考MongoDB Sharding

在应用程序里,使用MongoClient创建db连接:

MongoClient.connect(‘mongodb://10.199.144.84:27000,10.199.144.89:27000,10.199.144.90:27000/dbtest?w=1‘, function(err, db) {
    ;
});
时间: 2024-10-09 20:02:49

MongoDB高可用模式部署的相关文章

Haproxy+Keepalived高可用环境部署梳理(主主和主从模式)

Nginx.LVS.HAProxy 是目前使用最广泛的三种负载均衡软件,本人都在多个项目中实施过,通常会结合Keepalive做健康检查,实现故障转移的高可用功能. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

LVS+Keepalived 高可用环境部署记录(主主和主从模式)

一.LVS+Keepalived主从热备的高可用环境部署 1)环境准备 1 2 3 4 5 6 7 8 9 10 11 12 LVS_Keepalived_Master      182.148.15.237 LVS_Keepalived_Backup      182.148.15.236 Real_Server1               182.148.15.233 Real_Server2               182.148.15.238 VIP                

MongoDB 高可用集群架构简介

在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写.海量数据高效存储.高可扩展性和高可用性这些难题.不过就是因为这些问题Nosql诞生了. 转载自严澜的博文--<如何搭建高效的MongoDB集群> NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病. 高性能,Nosql通过简单的key-value方式获取数据,非常快速.还有

LVS负载均衡之lvs高可用实例部署2(案例篇)

在日常应用环境中,我们会遇到这样一种lvs部署环境,所有的dr以及的rs server都在一个局域网环境中,但只有一个公网ip,而又需要将应用发布到internet上,都知道lvs的最好的模式就是所有的server都有一个公网ip,但很多时候公网资源稀缺,当出现只有一个公网ip的时候,怎么实现lvs对外发布呢? Lvs(lvs/dr模式)单个公网ip高可用应用案例 如图所示为整体的拓扑图: 一.部署前说明: (1)系统版本: centos 6.6(64位) (2)角色及ip相关信息: 角色名称

MongoDB 高可用集群副本集+分片搭建

MongoDB 高可用集群搭建 一.架构概况 192.168.150.129192.168.150.130192.168.150.131 参考文档:https://www.cnblogs.com/vadim/p/7100683.html mongos mongos    mongos Config   server      Config server  Config serverShared1 server 1 Shared1 server 1 副本 Shared1 server 1 仲裁/隐

MongoDB 高可用切换

MongoDB 高可用集群切换 MongoDB最简单的集群模式是三节点搭建Replica Set(副本集),这样可以保证一个节点故障后,其余节点还可以继续提供服务. 在MongoDB集群中,也存在主节点和备用节点的角色,如主节点出现问题,会通过选举在备用节点中产生一个新的主节点,其主备用节点会自动向新的主节点进行同步. 在新旧主节点完成切换后,对前端应用几乎是透明的,原因在于MongoDB特殊的连接字符串配置方式: mongodb://[username:[email protected]]ho

MHA高可用架构部署配置实例

MHA高可用架构部署配置实例 一.前言 1.1What's MHA?--原理简介 ? MHA--Master High Availability,目前在MySQL高可用方面是一个相对成熟的解决方案,是一套优秀的MySQL故障切换和主从提升的高可用软件. ? 这里我们提到了两个个关键点:"高可用","故障切换".我们逐一简单介绍一下这两者的含义. 1.1.1何为高可用? ? 高可用就是可用性强,在一定条件下(某个服务器出错或宕机)可以保证服务器可以正常运行,在一定程度

k8s高可用环境部署-1.17.3版本

准备 在开始部署 k8s 高可用集群时,请先参考k8s高可用环境部署系统准备 操作系统兼容性 环境说明 集群部署前系统环境装备,请参考k8s高可用环境部署系统准备.md 本次高可用集群基本参照官网步骤进行部署,官网给出了两种拓扑结构:堆叠control plane node和external etcd node,本文基于第一种拓扑结构进行部署,使用Keepalived + HAProxy搭建高可用Load balancer,完整的拓扑图如下: 单个mastre节点将部署keepalived.ha

mongodb高可用集群01---单实例、主从模式、一主多从模式

本人根据此文章进行学习:http://blog.jobbole.com/72610/ 会不断更新内容主要分为四大模块: mongodb各种方式的部署 常用使用[工作不用就没必要学了,精力有限] 性能优化 故障排除 很多会和网上资料一样,主要是自己学习不断梳理资料,追求:提及精华 单实例: 1)建立mongodb测试文件 #存放整个mongodb文件 mkdri-p /data/mongodbtest/single #mongodb数据文件 mkdir /data/mongodbtest/data