您的当前位置：首页正文

坑爹的MongoDB

2023-11-09 来源：东饰资讯网

无法远程连接？！认证失败？！

为了提高远程访问的安全性，按照MongoDB官网的说明，增加了用户认证，本地测试均通过，然而远程访问死活通不过，无论是spring-data-mongo，还是MongoVUE客户端，还是ubuntu下的mongo-clients，均报auth failed，难道是我的人品有问题？这里回顾一下软件环境： 1、MongoDB是3.0.3版本，号称性能提升95%不只提升7到10倍的写入效率以及增加80%的数据压缩率,还能减少95%的运维成本。 2、由于spring用的3.2，spring-data-mongo使用的1.5.5版本，对于mongo-java-driver为2.12.5 3、windows客户端用的是MongoVUE-1.6.9 4、ubuntu下简单测试是通过apt-get安装的mongo-clients，版本2.4.9 在未开启auth之前，一切都是正常的，数据能正常读写，开启auth后，也只是报auth failed，所有的Built-In Roles都加上了，还是不行。中间的各种折腾就略过了，最后我原样在另外一台机器上部署了同样一个版本的mongodb，再同mongo命令远程连接，居然通了！！！居然不向下兼容！我勒个去，由于mongo-java-driver版本间也不兼容，要升级意味着spring-data-mongo要1.7以上版本，spring版本要升至4.0，想想还是算了

坑爹的MongoDB

标签：

小编还为您整理了以下内容，可能对您也有帮助：

千万别用MongoDB？真的吗

为什么这么说？

数据库应该是正确的，或是尽可能的正确，因为数据库的错误会比其它错误危害更大。不仅仅是因为其对运行，性能，开销，和其价值影响巨大，还因为其连带的东西。匆忙去去移植 TB 级的数据相比起去修改代码中的一个逻辑错误来说是一个很巨大的工作。而在系统出问题后需要恢复 TB 级的数据，你会被硬盘的速度所，你会有一种绝望的感觉。

数据库是一个很复杂的系统，对于开发者来说就像一个黑盒一样。你需要对你所采用的数据库持绝对信任的态度，信任它会做正确的事，并会保持一致性和可用性。

为什么 MongoDB 会流行？

说句公道话，我们必需承认 MongoDB 是流行的，因为下面这些原因让其流行变得很合理：

它非常容易地运行

非常自由的 Schema 模型，而且可以很容易地和 JSON 类的数据结果映射起来，这对于程序员来于有很大的感染力（它完全符合程序员的逻辑思维），而且，程序员总是在项目可以做技术选型的人。

成熟和健壮，track record，被真实的 Use Case 测试过，等等。对于那些喜欢选择成熟的技术的系统管理员和运营专业来说，这是一个很典型的选择。

它单系统，低并发读的性能测试非常令人惊讶，而对于那些没有经验的评估者来说，这基本上来说是最重要的。

现在，你可能正在开发一个随便玩一玩的网站，或是一个原型，或是那种只考虑开发速度不考虑别的的项目。老实说，对于这种项目，无所谓你用什么样的技术，只要搞定工作就行了。

但是，如果你想要在 MongoDB 上搞一个大规模的系统，在上面运行真实的业务，那么，请不要用 MongoDB。转载，仅供参考。

总结遇到的几次MongoDB副本集初始化失败问题

前言：
在之前搭建MongoDB集群中，遇到过几次小问题引起的初始化副本集失败，都是之前初学时踩的坑，做个小结。

1、IP错误引起MongoDB副本集初始化失败
这个错误在另一篇文章已经描述过，这里略过不赘述。
详情见博客：IP错误引起MongoDB副本集初始化失败

2、PRIMARY与SECONDARY主机mongodb-keyfile文件内容不一致，导致在PRIMARY上添加副本集失败
问题描述：
搭建另外一个MongoDB副本集，主机和角色分配如下：

主机IP
角色
系统
131.10.11.106
PRIMARY
centos7
131.10.11.111
SECONDARY
centos7
131.10.11.114
SECONDARY
centos7
MongoDB server version: 3.4.10.1

在PRIMARY上添加SECONDARY主机131.10.11.111，出现下面的报错：

mongotest:PRIMARY> rs.add("131.10.11.111:27017")
{
"ok" : 0,
"errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 131.10.11.106:27017; the following nodes did not respond affirmatively: 131.10.11.111:27017 failed with Authentication failed.",
"code" : 74,
"codeName" : "NodeNotFound"
}
原因分析：
经过排查，发现131.10.11.111主机的mongodb-keyfile和主节点不一致，并且在131.10.11.111主机的配置文件mongo.conf文件没有配置安全认证，所以导致了初始化失败

解决方法：
1、将PRIMARY节点上的mongodb-keyfile文件复制到备节点131.10.11.111上，并且修改权限为400
2、并且修改配置文件/etc/mongodb/mongo.conf如下：

[root@mongodb111 mongodb]# cat mongo.conf
systemLog:
destination: file
path: "/opt/mongodbdata/mongod.log"
logAppend: true
storage:
journal:
enabled: true
dbPath: /opt/mongodbdata
setParameter:
enableLocalhostAuthBypass: true
processManagement:
fork: true
pidFilePath: "/opt/mongodbdata/mongod.pid"
replication:
replSetName: mongotest
#添加下面几行：
security:
authorization: enabled
keyFile: "/etc/mongodb/mongodb-keyfile"
[root@mongodb111 mongodb]#
重启131.10.11.111机器mongodb，然后重新在PRIMARY上执行 rs.add("131.10.11.111:27017")，成功。

3、备节点配置文件没有配置replSet，导致添加副本集失败
问题描述：
这个问题和问题2是在同一个环境中遇到的，在106主机上添加114主机的时候，报下面的错误：

mongotest:PRIMARY> rs.add("131.10.11.114:27017")
{
"ok" : 0,
"errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 131.10.11.106:27017; the following nodes did not respond affirmatively: 131.10.11.114:27017 failed with not running with --replSet",
"code" : 74,
"codeName" : "NodeNotFound"
}
原因分析：
根据提示“the following nodes did not respond affirmatively: 131.10.11.114:27017 failed with not running with --replSe”，查看了114主机的配置文件mongo.conf，发现这是因为备节点上的配置文件里面没有配置副本集，所以无法添加

解决方法：
修改备节点的/etc/mongodb/mongo.conf配置文件如下，加上副本集配置：

[root@mongodb114 mongodb]# cat mongo.conf
systemLog:
destination: file
path: "/opt/mongodbdata/mongod.log"
logAppend: true
storage:
journal:
enabled: true
dbPath: /opt/mongodbdata
setParameter:
enableLocalhostAuthBypass: true
processManagement:
fork: true
pidFilePath: "/opt/mongodbdata/mongod.pid"
security:
authorization: enabled
keyFile: "/etc/mongodb/mongodb-keyfile"
replication: #加上副本集配置，
replSetName: mongotest #name要注意和主节点上保持一致
[root@mongodb114 mongodb]#
重启131.10.11.114机器mongodb，然后重新在PRIMARY上执行 rs.add("131.10.11.114:27017")，成功

4、bindIp默认127.0.0.1，导致MongoDB副本集初始化失败
问题描述：
有一次搭建一个MongoDB副本集，主机和角色分配如下：

主机IP
角色
系统
10.0.0.101
PRIMARY
centos7
10.0.0.102
SECONDARY
centos7
10.0.0.103
SECONDARY
centos7
MongoDB server version: 4.0.2
在PRIMARY主机10.0.0.101上加入SECONDARY主机10.0.0.102的时候出现这个错误：
添加从节点失败:

CrystalTest:PRIMARY> rs.add("10.0.0.102:27017")
{
"operationTime" : Timestamp(1539054715, 1),
"ok" : 0,
"errmsg" : "Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: 10.0.0.101:27017; the following nodes did not respond affirmatively: 10.0.0.102:27017 failed with Error connecting to 10.0.0.102:27017 :: caused by :: Connection refused",
"code" : 74,
"codeName" : "NodeNotFound",
"$clusterTime" : {
"clusterTime" : Timestamp(1539054715, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
原因分析：
看到 “failed with Error connecting to 10.0.0.102:27017 :: caused by :: Connection refused”的时候很疑惑，因为10.0.0.102主机上的27017端口是OK的，服务也能正常使用，防火墙什么的都是关掉了的，尝试在PRIMARY主机10.0.0.101主机上telnet，发现不通：

[root@test101 ~]# telnet 10.0.0.102 27017
Trying 10.0.0.102...
telnet: connect to address 10.0.0.102: Connection refused
然后到102主机上查看端口，发现bindIp是127.0.0.1，问题应该就是这里了。bindIp是127.0.0.1，因此导致了10.0.0.101主机连不过去：

[root@test102 ~]# netstat -tlunp|grep mongo
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 1065/mongod #显示的是127.0.0.1:27017
解决方法：
修改102主机的mongo.conf加入“bindIp: 0.0.0.0 ”，然后重启102主机的MongoDB

[root@test102 bin]# cat /etc/mongodb/mongo.conf
systemLog:
destination: file
path: "/opt/mongodbdata/mongod.log"
logAppend: true
storage:
journal:
enabled: true
dbPath: /opt/mongodbdata
setParameter:
enableLocalhostAuthBypass: true
processManagement:
fork: true
pidFilePath: "/opt/mongodbdata/mongod.pid"
replication:
replSetName: CrystalTest
security:
authorization: enabled
keyFile: "/etc/mongodb/mongodb-keyfile"
net:
port: 27017
bindIp: 0.0.0.0 #加入这一行
再查看端口：

[root@test102 mongodb]# netstat -tlunp|grep 27017
tcp 0 0 0.0.0.0:27017 0.0.0.0:* LISTEN 3433/mongod #变成了0 0.0.0.0:27017
[root@test102 mongodb]#
然后在101主机上telnet，可以连过去了：

[root@test101 ~]# telnet 10.0.0.102 27017
Trying 10.0.0.102...
Connected to 10.0.0.102.
Escape character is ‘^]‘.
^C^C
Connection closed by foreign host.
[root@test101 ~]#
重新在PRIMARY主机10.0.0.101添加102主机，就成功了：

CrystalTest:PRIMARY> rs.add("10.0.0.102:27017")
{
"ok" : 1,
"operationTime" : Timestamp(1539056959, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1539056959, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}总结遇到的几次MongoDB副本集初始化失败问题
标签：headcentosnectelnetnodalt修改mongodtry

总结遇到的几次MongoDB副本集初始化失败问题

redis 和 mongodb 比起来优缺点是什么?

一、优点：

1、支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）

2、支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

3、支持通过Replication进行数据复制，通过master-slave机制，可以实时进行数据的同步复制，支持多级复制和增量复制，master-slave机制是Redis进行HA的重要手段。

二、缺点：

1、Redis只能使用单线程，性能受限于CPU性能，故单实例CPU最高才可能达到5-6wQPS每秒（取决于数据结构，数据大小以及服务器硬件性能，日常环境中QPS高峰大约在1-2w左右）。

2、支持简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。

3、Redis在string类型上会消耗较多内存，可以使用dict（hash表）压缩存储以降低内存耗用。

扩展资料：

redis使用注意事项：

1、注意垃圾回收：Redis是一个提供持久化功能的内存数据库，如果不指定上面值的过期时间，并且也不进行定期的清理工作，那么Redis内存占用会越来越大，当有一天超过了系统可用内存，那么swap上场，离性能陡降的时间就不远了。

2、使用key值前缀来作命名空间：虽然说Redis支持多个数据库（默认32个，可以配置更多），但是除了默认的0号库以外，其它的都需要通过一个额外请求才能使用。所以用前缀作为命名空间可能会更明智一点。

3、Redis并不支持Sharding，但是当数据量超过单机内存时，不得不考虑Sharding的事（注意Slave不是用来做Sharding操作的，只是数据的一个备份和读写分离而已）。

参考资料来源：百度百科-Redis

参考资料来源：百度百科-mongodb

redis 和 mongodb 比起来优缺点是什么?

一、优点：

1、支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算）

2、支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

二、缺点：

2、支持简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。

3、Redis在string类型上会消耗较多内存，可以使用dict（hash表）压缩存储以降低内存耗用。

扩展资料：

redis使用注意事项：

参考资料来源：百度百科-Redis

参考资料来源：百度百科-mongodb

谈谈mongodb,mysql的区别和具体应用场景

（1）mysql数据库：
属于关系型数据库。
在不同的引擎上有不同的存储方式。
查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。
开源数据库的份额在不断增加，mysql的份额页在持续增长。
缺点就是在海量数据处理的时候效率会显著变慢。
（2）mongodb数据库：
非关系型数据库(nosql
),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性（self-describing），呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。
存储方式：虚拟内存+持久化。
查询语句：是独特的mongodb的查询方式。
适合场景：事件的记录，内容管理或者博客平台等等。
架构特点：可以通过副本集，以及分片来实现高可用。
数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。
成熟度与广泛度：新兴数据库，成熟度较低，nosql数据库中最为接近关系型数据库，比较完善的db之一，适用人群不断在增长。
分析一下mysql和mongodb应用场景
1.如果需要将mongodb作为后端db来代替mysql使用，即这里mysql与mongodb
属于平行级别，那么，这样的使用可能有以下几种情况的考量：
(1)mongodb所负责部分以文档形式存储，能够有较好的代码亲和性，json格式的直接写入方便。(如日志之类)
(2)从data
models设计阶段就将原子性考虑于其中，无需事务之类的辅助。开发用如nodejs之类的语言来进行开发，对开发比较方便。
(3)mongodb本身的failover机制，无需使用如mha之类的方式实现。
2.将mongodb作为类似redis
，memcache来做缓存db，为mysql提供服务，或是后端日志收集分析。
考虑到mongodb属于nosql型数据库，sql语句与数据结构不如mysql那么亲和
，也会有很多时候将mongodb做为辅助mysql而使用的类redis
memcache
之类的缓存db来使用。
亦或是仅作日志收集分析。

谈谈mongodb,mysql的区别和具体应用场景

mongodb和mysql的区别

MongoDB(文档型数据库)：提供可扩展的高性能数据存储

一、

1、基于分布式文件存储

2、高负载情况下添加更多节点，可以保证服务器性能

3、将数据存储为一个文档

二、比较

1、稳定性

2、索引，索引放在内存中，能够提升随机读写的性能。如果索引不能完全放在内存，一旦出现随机读写比较高的时候，就会频繁地进行磁盘交换，MongoDB的性能就会急剧下降

3、占用的空间很大，因为它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，

在MongoDB中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果，

一个是索引会出现性能问题，

另外一个就是在一定的时间后，所占空间会莫明其妙地增大，所以要定期把数据库做修复，定期重新做索引，这样会提升MongoDB的稳定性和效率。

在最新的版本里，它已经在实现在线压缩，估计应该在2.0版左右，应该能够实现在线压缩，可以在后台执行现在repair DataBase的一些操作。如果那样，就解决了目前困扰

我们的大问题。

4、MongoDB对数据间的事务关系支持比较弱

5、运维不方便

MongoDB的优势

1. 适合那些对数据库具体数据格式不明确或者数据库数据格式经常变化的需求模型，而且对开发者十分友好。

2.自带一个分布式文件系统，可以很方便地部署到服务器机群上。

MongoDB里有一个Shard的概念，就是方便为了服务器分片使用的。每增加一台Shard，MongoDB的插入性能也会以接近倍数的方式增长，磁盘容量也很可以很方便地扩充。

3. 自带了对map-rece运算框架的支持，这也很方便进行数据的统计。类似于group by

mongodb与mysql命令对比传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，

MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。

MongoDB对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点。

mongodb和mysql5.7的json哪个更好，优缺点比较

与关系型数据库相比，MongoDB的优点：

①弱一致性（最终一致），更能保证用户的访问速度：

举例来说，在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的精确值。这在某些情况下，例如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延迟。他们需要的是一个“大约”的数字以及更快的处理速度。

但某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：

每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。

使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。

②文档结构的存储方式，能够更便捷的获取数据。

对于一个层级式的数据结构来说，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难。

举例1：

就拿一个“字典项”来说，虽然并不十分复杂，但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库中的主键和外键表现出来，但把它看作一个“文档”而不是“一系列有关系的表”岂不更好？使用 “dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便且快速。

举例2：在一个关系型数据库中，一篇博客（包含文章内容、评论、评论的投票）会被打散在多张数据表中。在MongoDB中，能用一个文档来表示一篇博客，评论与投票作为文档数组，放在正文主文档中。这样数据更易于管理，消除了传统关系型数据库中影响性能和水平扩展性的“JOIN”操作。