0
0

MongoDB内容分享（三）：MongoDB 索引-Index、集群、安全

概述

索引支持在MongoDB中高效地执行查询。如果没有索引，MongoDB必须执行全集合扫描，即扫描集合中的每个文档，以选择与查询语句匹配的文档。这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。

如果查询存在适当的索引，MongoDB可以使用该索引限制必须检查的文档数。

索引是特殊的数据结构，它以易于遍历的形式存储集合数据集的一小部分。索引存储特定字段或一组字段的值，按字段值排序。索引项的排序支持有效的相等匹配和基于范围的查询操作。此外，MongoDB还可以使用索引中的排序返回排序结果。

官网文档

了解：

MongoDB索引使用B树数据结构（确切的说是B-Tree，MySQL是B+Tree）

索引的类型

单字段索引

MongoDB支持在文档的单个字段上创建用户定义的升序/降序索引，称为单字段索引（Single Field Index）。

对于单个字段索引和排序操作，索引键的排序顺序（即升序或降序）并不重要，因为MongoDB可以在任何方向上遍历索引。

image

复合索引

MongoDB还支持多个字段的用户定义索引，即复合索引（Compound Index）。

复合索引中列出的字段顺序具有重要意义。例如，如果复合索引由 { userid: 1, score: -1 } 组成，则索引首先按userid正序排序，然后在每个userid的值内，再在按score倒序排序。

image

其他索引

地理空间索引（Geospatial Index）、文本索引（Text Indexes）、哈希索引（Hashed Indexes）。

地理空间索引（Geospatial Index）

为了支持对地理空间坐标数据的有效查询，MongoDB提供了两种特殊的索引：返回结果时使用平面几何的二维索引和返回结果时使用球面几何的二维球面索引。

文本索引（Text Indexes）

MongoDB提供了一种文本索引类型，支持在集合中搜索字符串内容。这些文本索引不存储特定于语言的停止词（例如“the”、“a”、“or”），而将集合中的词作为词干，只存储根词。

哈希索引（Hashed Indexes）

为了支持基于散列的分片，MongoDB提供了散列索引类型，它对字段值的散列进行索引。这些索引在其范围内的值分布更加随机，但只支持相等匹配，不支持基于范围的查询。

索引的管理操作

索引的查看

说明:

返回一个集合中的所有索引的数组。

语法：

db.collection.getIndexes()

提示：该语法命令运行要求是MongoDB 3.0+

【示例】

查看comment集合中所有的索引情况

> db.comment.getIndexes()
[
        {
                "v" : 2,
                "key" : {
                        "_id" : 1
                },
                "name" : "_id_",
                "ns" : "articledb.comment"
        }
]

结果中显示的是默认

_id

索引。

默认_id索引：

MongoDB在创建集合的过程中，在 

_id

字段上创建一个唯一的索引，默认名字为

_id_

，该索引可防止客户端插入两个具有相同值的文档，您不能在_id字段上删除此索引。

注意：该索引是唯一索引，因此值不能重复，即

_id

值不能重复的。在分片集群中，通常使用

_id

作为片键。

创建索引

说明:

在集合上创建索引。

语法:

db.collection.createIndex(keys,options)

参数:
ParameterTypeDescription

keys

document包含字段和值对的文档，其中字段是索引键，值描述该字段的索引类型。对于字段上的升序索引，请指定值1；对于降序索引，请指定值-1。比如： 

{字段:1或-1}

，其中1 为指定按升序创建索引，如果你想按降序来创建索引指定为 -1 即可。另外，MongoDB支持几种不同的索引类型，包括文本、地理空间和哈希索引。

options

document可选。包含一组控制索引创建的选项的文档。有关详细信息，请参见选项详情列表。
options（更多选项）列表：
ParameterTypeDescriptionbackgroundBoolean建索引过程会阻塞其它数据库操作，background可指定以后台方式创建索引，即增加"background" 可选参数。 "background" 默认值为

false

。uniqueBoolean建立的索引是否唯一。指定为true创建唯一索引。默认值为

false

.namestring索引的名称。如果未指定，MongoDB的通过连接索引的字段名和排序顺序生成一个索引名称。dropDupsBoolean3.0+版本已废弃。在建立唯一索引时是否删除重复记录,指定 true 创建唯一索引。默认值为

false

sparseBoolean对文档中不存在的字段数据不启用索引；这个参数需要特别注意，如果设置为true的话，在索引字段中不会查询出不包含对应字段的文档.。默认值为 

false

.expireAfterSecondsinteger指定一个以秒为单位的数值，完成 TTL设定，设定集合的生存时间。vindex version索引的版本号。默认的索引版本取决于mongod创建索引时运行的版本。weightsdocument索引权重值，数值在 1 到 99,999 之间，表示该索引相对于其他索引字段的得分权重。default_languagestring对于文本索引，该参数决定了停用词及词干和词器的规则的列表。 默认为英语language_overridestring对于文本索引，该参数指定了包含在文档中的字段名，语言覆盖默认的language，默认值为language.

提示：

注意在 3.0.0 版本前创建索引方法为 

db.collection.ensureIndex()

，之后的版本使用了 

db.collection.createIndex()

方法，ensureIndex() 还能用，但只是 createIndex() 的别名。

【示例】

单字段索引

对 userid 字段建立索引：

> db.comment.createIndex({userid:-1})
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}

参数1：按升序创建索引

可以查看一下：

> db.comment.getIndexes()
[
        {
                "v" : 2,
                "key" : {
                        "_id" : 1
                },
                "name" : "_id_",
                "ns" : "articledb.comment"
        },
        {
                "v" : 2,
                "key" : {
                        "userid" : -1
                },
                "name" : "userid_-1",
                "ns" : "articledb.comment"
        }
]

索引名字为

userid_1

compass查看:

image

复合索引

对 userid 和 nickname 同时建立复合（Compound）索引：

> db.comment.createIndex({userid:-1,nickname:-1})
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 2,
        "numIndexesAfter" : 3,
        "ok" : 1
}

查看一下索引：

> db.comment.getIndexes()
[
        {
                "v" : 2,
                "key" : {
                        "_id" : 1
                },
                "name" : "_id_",
                "ns" : "articledb.comment"
        },
        {
                "v" : 2,
                "key" : {
                        "userid" : -1
                },
                "name" : "userid_-1",
                "ns" : "articledb.comment"
        },
        {
                "v" : 2,
                "key" : {
                        "userid" : -1,
                        "nickname" : -1
                },
                "name" : "userid_-1_nickname_-1",
                "ns" : "articledb.comment"
        }
]

compass中：

image

索引的移除

说明：可以移除指定的索引，或移除所有索引

指定索引的移除

语法：

db.collection.dropIndex(index)

参数:
ParametarTypeDescription

index

string or document指定要删除的索引。可以通过索引名称或索引规范文档指定索引。若要删除文本索引，请指定索引名称。
【示例】

删除 comment 集合中 userid 字段上的升序索引：

> db.comment.dropIndex({userid:-1})
{ "nIndexesWas" : 3, "ok" : 1 }
所有索引的移除

语法：

db.comment.dropIndexes()

【示例】

删除 spit 集合中所有索引。

> db.comment.dropIndexes()
{
        "nIndexesWas" : 2,
        "msg" : "non-_id indexes dropped for collection",
        "ok" : 1
}

提示：

_id

的字段的索引是无法删除的，只能删除非

_id

字段的索引。

索引的使用

执行计划

分析查询性能（Analyze Query Performance）通常使用执行计划（解释计划、Explain Plan）来查看查询的情况，如查询耗费的时间、是否基于索引查询等。

那么，通常，我们想知道，建立的索引是否有效，效果如何，都需要通过执行计划查看。

语法：

db.collection.find(query,options).explain(options)

【示例】

查看根据userid查询数据的情况：

> db.comment.find({userid:"1003"}).explain()
{
        "queryPlanner" : {
                "plannerVersion" : 1,
                "namespace" : "articledb.comment",
                "indexFilterSet" : false,
                "parsedQuery" : {
                        "userid" : {
                                "$eq" : "1003"
                        }
                },
                "winningPlan" : {
                        "stage" : "COLLSCAN",
                        "filter" : {
                                "userid" : {
                                        "$eq" : "1003"
                                }
                        },
                        "direction" : "forward"
                },
                "rejectedPlans" : [ ]
        },
        "serverInfo" : {
                "host" : "master",
                "port" : 27017,
                "version" : "4.0.10",
                "gitVersion" : "c389e7f69f637f7a1ac3cc9fae843b635f20b766"
        },
        "ok" : 1
}

关键点看： 

"stage" : "COLLSCAN"

, 表示全集合扫描

image

下面对userid建立索引

> db.comment.createIndex({userid:1})
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}

再次查看执行计划：

> db.comment.find({userid:"1003"}).explain()
{
        "queryPlanner" : {
                "plannerVersion" : 1,
                "namespace" : "articledb.comment",
                "indexFilterSet" : false,
                "parsedQuery" : {
                        "userid" : {
                                "$eq" : "1003"
                        }
                },
                "winningPlan" : {
                        "stage" : "FETCH",
                        "inputStage" : {
                                "stage" : "IXSCAN",
                                "keyPattern" : {
                                        "userid" : 1
                                },
                                "indexName" : "userid_1",
                                "isMultiKey" : false,
                                "multiKeyPaths" : {
                                        "userid" : [ ]
                                },
                                "isUnique" : false,
                                "isSparse" : false,
                                "isPartial" : false,
                                "indexVersion" : 2,
                                "direction" : "forward",
                                "indexBounds" : {
                                        "userid" : [
                                                "[\"1003\", \"1003\"]"
                                        ]
                                }
                        }
                },
                "rejectedPlans" : [ ]
        },
        "serverInfo" : {
                "host" : "master",
                "port" : 27017,
                "version" : "4.0.10",
                "gitVersion" : "c389e7f69f637f7a1ac3cc9fae843b635f20b766"
        },
        "ok" : 1
}

关键点看： 

"stage" : "IXSCAN"

,基于索引的扫描

compass查看：

image

涵盖的扫描

Covered Queries

当查询条件和查询的投影仅包含索引字段时，MongoDB直接从索引返回结果(不再去找集合)，而不扫描任何文档或将文档带入内存。 这些覆盖的查询可以非常有效。

image

【示例】

>  db.comment.find({userid:"1003"},{userid:1,_id:0})
{ "userid" : "1003" }
{ "userid" : "1003" }
> db.comment.find({userid:"1003"},{userid:1,_id:0}).explain()
{
        "queryPlanner" : {
                "plannerVersion" : 1,
                "namespace" : "articledb.comment",
                "indexFilterSet" : false,
                "parsedQuery" : {
                        "userid" : {
                                "$eq" : "1003"
                        }
                },
                "winningPlan" : {
                        "stage" : "PROJECTION",
                        "transformBy" : {
                                "userid" : 1,
                                "_id" : 0
                        },
                        "inputStage" : {
                                "stage" : "IXSCAN",
                                "keyPattern" : {
                                        "userid" : 1
                                },
                                "indexName" : "userid_1",
                                "isMultiKey" : false,
                                "multiKeyPaths" : {
                                        "userid" : [ ]
                                },
                                "isUnique" : false,
                                "isSparse" : false,
                                "isPartial" : false,
                                "indexVersion" : 2,
                                "direction" : "forward",
                                "indexBounds" : {
                                        "userid" : [
                                                "[\"1003\", \"1003\"]"
                                        ]
                                }
                        }
                },
                "rejectedPlans" : [ ]
        },
        "serverInfo" : {
                "host" : "master",
                "port" : 27017,
                "version" : "4.0.10",
                "gitVersion" : "c389e7f69f637f7a1ac3cc9fae843b635f20b766"
        },
        "ok" : 1
}

Compass中：

image

副本集-Replica Sets

简介

MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高 可用性，是所有生产部署的基础。

也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异 步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动 切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。

冗余和数据可用性

复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别 的容错功能，以防止丢失单个数据库服务器。

在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不 同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他 副本，例如灾难恢复，报告或备份。

MongoDB中的复制

副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。 在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。

主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某 些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有 更改，即oplog。

image

辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据 集。 如果主要人员不在，则符合条件的中学将举行选举以选出新的主要人员。

主从复制和副本集区别

主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂 掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多 个备份节点(从、secondary)。

副本集的三个角色

副本集有两种类型三种角色

两种类型：

  • 主节点（Primary）类型：数据操作的主要连接点，可读写。
  • 次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。

三种角色：

主要成员（Primary）：主要接收所有写操作。就是主节点。

副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可 以读操作（但需要配置）。是默认的一种从节点类型。

仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副 本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。

image

关于仲裁者的额外说明：

您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过 响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可 以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。

如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用 硬件。

仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要 人员。

如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。

如果你的副本+主节点的个数是奇数，可以不加仲裁者。

副本集架构目标

一主一副本一仲裁

image

副本集的创建

第一步：创建主节点

建立存放数据和日志的目录

#-----------myrs
#主节点
mkdir -p /mongodb/replica_sets/myrs_27017/log \ &
mkdir -p /mongodb/replica_sets/myrs_27017/data/db

新建或修改配置文件

vim /mongodb/replica_sets/myrs_27017/mongod.conf

myrs_27017：

systemLog:
  #MongoDB发送所有日志输出的目标指定为文件
  destination: file
  #mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
  path: "/mongodb/replica_sets/myrs_27017/log/mongod.log"
  #当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
  logAppend: true
storage:
  #mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
  dbPath: "/mongodb/replica_sets/myrs_27017/data/db"
  journal:
    #启用或禁用持久性日志以确保数据文件保持有效和可恢复。
    enabled: true
processManagement:
  #启用在后台运行mongos或mongod进程的守护进程模式。
  fork: true
  #指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
  pidFilePath: "/mongodb/replica_sets/myrs_27017/log/mongod.pid"
net:
  #服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
  #bindIpAll: true
  #服务实例绑定的IP
  bindIp: localhost,192.168.72.2
  #bindIp
  #绑定的端口
  port: 27017
replication:
  #副本集的名称
  replSetName: myrs

启动节点服务：

[root@master ~]#  /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 2038
child process started successfully, parent exiting

第二步：创建副本节点

建立存放数据和日志的目录

#-----------myrs
#副本节点
mkdir -p /mongodb/replica_sets/myrs_27018/log \ &
mkdir -p /mongodb/replica_sets/myrs_27018/data/db

新建或修改配置文件：

mkdir /mongodb/replica_sets/myrs_27018/
cd /mongodb/replica_sets/myrs_27017/
cp mongod.conf /mongodb/replica_sets/myrs_27018/mongod.conf

myrs_27018：

把myrs_27017中的端口号改为27018即可

:% s/27017/27018/g

启动节点服务：

[root@master mongodb]#  /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 2217
child process started successfully, parent exiting

第三步：创建仲裁节点

建立存放数据和日志的目录

#-----------myrs
#仲裁节点
mkdir -p /mongodb/replica_sets/myrs_27019/log \ &
mkdir -p /mongodb/replica_sets/myrs_27019/data/db

仲裁节点：

新建或修改配置文件：

mkdir /mongodb/replica_sets/myrs_27019/
cd /mongodb/replica_sets/myrs_27017/
cp mongod.conf /mongodb/replica_sets/myrs_27019/mongod.conf

myrs_27019：

把myrs_27017中的端口号改为27019即可

:% s/27017/27019/g

启动节点服务：

[root@master myrs_27019]#  /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf
about to fork child process, waiting until server is ready for connections.
forked process: 2342
child process started successfully, parent exiting
  • 使用命令行查看mongo服务
[root@master myrs_27019]# ps -ef | grep mongo
root       2038      1  0 20:25 ?        00:00:04 /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
root       2217      1  0 20:37 ?        00:00:01 /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
root       2342      1  0 20:43 ?        00:00:00 /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf
root       2388   1880  0 20:45 pts/0    00:00:00 grep --color=auto mongo

第四步：初始化配置副本集和主节点

使用客户端命令连接任意一个节点，但这里尽量要连接主节点(27017节点)：

/usr/local/mongodb/bin/mongo --host=192.168.72.200 --port=27017

结果，连接上之后，很多命令无法使用，，比如 show dbs 等，必须初始化副本集才行

准备初始化新的副本集：

语法：

rs.initiate(configuration)

选项:
ParameterTypeDescription

configuration

documentOptional. A document that specifies configuration for the new replica set. If a configuration is not specified,MongoDB uses a default replica set configuration.
【示例】

使用默认的配置来初始化副本集：

rs.initiate()

执行结果：

> rs.initiate()
{
        "info2" : "no configuration specified. Using a default configuration for the set",
        "me" : "localhost:27019",
        "ok" : 1,
        "operationTime" : Timestamp(1656343919, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1656343919, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}
myrs:OTHER>
myrs:PRIMARY>

提示：

  1. “ok”的值为1，说明创建成功。
  2. 命令行提示符发生变化，变成了一个从节点角色，此时默认不能读写。稍等片刻，回车，变成主节 点。

第五步：查看副本集的配置内容

说明：

返回包含当前副本集配置的文档。

语法：

rs.conf(configuration)

提示：

rs.config() 是该方法的别名。

configuration：可选，如果没有配置，则使用默认主节点配置。

【示例】

在27017上执行副本集中当前节点的默认节点配置

myrs:PRIMARY> rs.conf()
{
        "_id" : "myrs",
        "version" : 1,
        "protocolVersion" : NumberLong(1),
        "writeConcernMajorityJournalDefault" : true,
        "members" : [
                {
                        "_id" : 0,
                        "host" : "localhost:27019",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {

                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                }
        ],
        "settings" : {
                "chainingAllowed" : true,
                "heartbeatIntervalMillis" : 2000,
                "heartbeatTimeoutSecs" : 10,
                "electionTimeoutMillis" : 10000,
                "catchUpTimeoutMillis" : -1,
                "catchUpTakeoverDelayMillis" : 30000,
                "getLastErrorModes" : {

                },
                "getLastErrorDefaults" : {
                        "w" : 1,
                        "wtimeout" : 0
                },
                "replicaSetId" : ObjectId("62b9cd6f2c5c46b2620c8b1b")
        }
}
  • "_id" : "myrs" ：副本集的配置数据存储的主键值，默认就是副本集的名字
  • "members" ：副本集成员数组，此时只有一个： "host" : "180.76.159.126:27017" ，该成员不是仲裁节点： "arbiterOnly" : false ，优先级（权重值）： "priority" : 1
  • "settings" ：副本集的参数配置。

提示：副本集配置的查看命令，本质是查询的是 system.replset 的表中的数据：

myrs:PRIMARY> use local
switched to db local
myrs:PRIMARY> show collections
oplog.rs
replset.election
replset.minvalid
replset.oplogTruncateAfterPoint
startup_log
system.replset
system.rollback.id
myrs:PRIMARY> db.system.replset.find()
{ "_id" : "myrs", "version" : 1, "protocolVersion" : NumberLong(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "localhost:27019", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {  }, "slaveDelay" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : {  }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("62b9cd6f2c5c46b2620c8b1b") } }

第六步：查看副本集状态

返回包含状态信息的文档。此输出使用从副本集的其他成员发送的心跳包中获得的数据反映副本集的当 前状态

rs.status()

【示例】

在27017上查看副本集状态：

myrs:PRIMARY> rs.status()
{
        "set" : "myrs",
        "date" : ISODate("2022-06-27T15:37:26.398Z"),
        "myState" : 1,
        "term" : NumberLong(1),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "heartbeatIntervalMillis" : NumberLong(2000),
        "optimes" : {
                "lastCommittedOpTime" : {
                        "ts" : Timestamp(1656344241, 1),
                        "t" : NumberLong(1)
                },
                "readConcernMajorityOpTime" : {
                        "ts" : Timestamp(1656344241, 1),
                        "t" : NumberLong(1)
                },
                "appliedOpTime" : {
                        "ts" : Timestamp(1656344241, 1),
                        "t" : NumberLong(1)
                },
                "durableOpTime" : {
                        "ts" : Timestamp(1656344241, 1),
                        "t" : NumberLong(1)
                }
        },
        "lastStableCheckpointTimestamp" : Timestamp(1656344211, 1),
        "members" : [
                {
                        "_id" : 0,
                        "name" : "localhost:27019",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 566,
                        "optime" : {
                                "ts" : Timestamp(1656344241, 1),
                                "t" : NumberLong(1)
                        },
                        "optimeDate" : ISODate("2022-06-27T15:37:21Z"),
                        "syncingTo" : "",
                        "syncSourceHost" : "",
                        "syncSourceId" : -1,
                        "infoMessage" : "",
                        "electionTime" : Timestamp(1656343919, 2),
                        "electionDate" : ISODate("2022-06-27T15:31:59Z"),
                        "configVersion" : 1,
                        "self" : true,
                        "lastHeartbeatMessage" : ""
                }
        ],
        "ok" : 1,
        "operationTime" : Timestamp(1656344241, 1),
        "$clusterTime" : {
                "clusterTime" : Timestamp(1656344241, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        }
}

说明：

  1. "set" : "myrs" ：副本集的名字
  2. "myState" : 1：说明状态正常
  3. "members" ：副本集成员数组，此时只有一个： "name" : "180.76.159.126:27017" ，该成员的角色是 "stateStr" : "PRIMARY", 该节点是健康的： "health" : 1 。

添加副本节点

在主节点添加从节点，将其他成员加入到副本集

rs.add(host, arbiterOnly)

选项:
ParameterTypeDescriptionhoststring or document要添加到副本集的新成员。指定为字符串或配置文档：1）如果是一个字符串，则需要指定新成员的主机名和可选的端口号；2）如果是一个文档，请指定在members数组中找到的副本集成员配置文档。您必须在成员配置文档中指定主机字段。有关文档配置字段的说明，详见下方文档："主机成员的配置文档"arbiterOnlyboolean可选的。仅在值为字符串时适用。如果为true，则添加的主机是仲裁者。
主机成员的配置文档：

{
  _id:<int>,
  host:<string>,
  arbiterOnly:<boolean>,
  buildIndexes:<boolean>,
  hidden:<boolean>,
  priority:<number>,
  tags:<document>,
  slaveDelay:<int>,
  votes:<number>
}

示例：

将27018的副本节点加添加到副本集汇总：

rs.add("localhost:27018")

添加仲裁从节点

rs.add(host,arbiterOnly)
或
rs.addArb(host)

例子：
rs.addArb("localhost:27019")

副本集的数据读写操作

副本节点 (SECONDARY) 默认不能 read , 更不可能 write 数据, 需要

rs.slaveOk()

myrs:SECONDARY> show dbs; 

"errmsg" : "not master and slaveOk=false",

# 非主节点同时 slaveOk=false 无法读写

数据会自动同步, 但是会有延迟

仲裁者节点, 不存放任何数据 -> 

rs.slaveOk()

也看不到数据

主节点的选举原则

MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件

  1. 主节点故障
  2. 主节点网络不可达 (默认心跳信息为 10 秒)
  3. 人工干预 rs.stepDown(600)

一旦触发选举，就要根据一定规则来选主节点

选举规则是根据票数来决定谁获胜

  • 票数最高，且获得了“大多数”成员的投票支持的节点获胜。 - “大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员， 则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary， 复制集将无法提供写服务，处于只读状态。
  • 若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。 - 数据的新旧是通过操作日志 oplog 来对比的。

在获得票数的时候，优先级（priority）参数影响重大。

可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加 0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员 更有资格成为主要成员，更低的值可使成员更不符合条件。

默认情况下，优先级的值是 1

故障测试

副本节点故障测试

关闭 

27018

副本节点

  • 主节点和仲裁节点对 27018 的心跳失败。因为主节点还在，因此，没有触发投票选举。
  • 如果此时，在主节点写入数据。再启动从节点，会发现，主节点写入的数据，会自动同步给从节点。
主节点故障测试

关闭27017节点

  • 从节点和仲裁节点对27017的心跳失败，当失败超过10秒，此时因为没有主节点了，会自动发起投票。
  • 而副本节点只有27018，因此，候选人只有一个就是27018，开始投票。
  • 27019向27018投了一票，27018本身自带一票，因此共两票，超过了“大多数”
  • 27019是仲裁节点，没有选举权，27018不向其投票，其票数是0.

最终结果，27018成为主节点。具备读写功能。 在27018写入数据查看。

仲裁节点和主节点故障

先关掉仲裁节点27019， 关掉现在的主节点27018 登录27017后

  • 27017仍然是从节点，副本集中没有主节点了，导致此时，副本集是只读状态， 无法写入。
  • 为啥不选举了？ - 因为27017的票数，没有获得大多数，即没有大于等于2，它只有默认的一票（优先级 是1）- 如果要触发选举，随便加入一个成员即可。 - 如果只加入27019仲裁节点成员，则主节点一定是27017，因为没得选了，仲裁节点不参与选举， 但参与投票- 如果只加入27018节点，会发起选举。因为27017和27018都是两票，则按照谁数据新，谁当主节点。
仲裁节点和从节点故障

先关掉仲裁节点 

27019

，关掉现在的副本节点 

27018

10秒后，

27017

主节点自动降级为副本节点。（服务降级）

副本集不可写数据了，已经故障了。

SpringDataMongoDB连接副本集

副本集语法：

mongodb://host1,host2,host3/articledb?connect=replicaSet&slaveOk=true&replicaSet=副本集名字

其中：

  • slaveOk=true：开启副本节点读的功能，可实现读写分离。
  • connect=replicaSet：自动到副本集中选择读写的主机。如果slaveOk是打开的，则实现读写分离。

示例：

连接replica set三台服务器（端口27017，27018，27019），直接连接第一个服务器，无论是replica set一部分或者主服务器或者从服务器，写入操作应用在主服务器并且分布查询到从服务器。

修改配置文件application.yml

spring: 
    #数据源配置
    data:
        mongodb: 
            #主机地址
            #host: localhost
            #数据库
            #database: test
            #默认端口号是27017
            #port: 27017
            #也可以使用uri连接
            uri: mongodb://localhost:27017,localhost:27018,localhost:27019/test?connect=replicaSet&slaveOk=true&replicaSet=myrs
标签： mongodb
本文转载自: https://blog.csdn.net/qq_45038038/article/details/134834024
版权归原作者 之乎者也· 所有， 如有侵权，请联系我们删除。
登录后发布评论

“MongoDB内容分享（三）：MongoDB 索引-Index、集群、安全”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

功能安全实战系列-DFA(Dependent Failure Analysis)分析

Apifox接口项目搭建、管理优化方案报告

关于Pycharm 2024 激活出现的问题

VSCode Git Graph 插件使用教程

RabbitMQ 优点和缺点

Kafka 的零拷贝原理

Hadoop的汽车销量数据分析系统

文章导航