Skip to main content

【译】MongoDB之数据库配置

00:00/00:00

特别喜欢的一首歌,总让我想起一些人。虽然很久没联系,心里仍然知道,不管身处何地,我们都能理解对方。Missing you。ps:最近越来越懒了,每周的博客应该要更走心一点咯

命令行和配置文件接口都为MongoDB管理员们提供了大量的选项和配置来控制数据库系统的运维。本文档提供了通用配置的概述和针对一般用户案例的最佳实践配置示例。

虽然两个接口都提供了对相同集合选项和配置的存取,但是本文档主要使用配置文件接口。如果我们使用一个初始的脚本运行MongoDB或者直接从一个针对您操作系统的包中安装的MongoDB,那么我们非常可能已经在/etc/mongod.conf中已经有一个配置文件了。通过查看etc/init.d/mongod或者/etc/rc.d/mongod脚本的内容来确定这个,以保证初始化脚本使用合适的配置文件来启动mongod。

如果想要使用该配置文件启动MongoDB实例,发送一个下列形式的命令:

mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf

我们可以通过修改系统中/ect/mongod.conf文件中的值来控制我们数据库实例的配置。

配置数据库

考虑下面使用YAML形式的基本配置:

processManagement:
   fork: true
net:
   bindIp: 127.0.0.1
   port: 27017
storage:
   dbPath: /srv/mongodb
systemLog:
   destination: file
   path: "/var/log/mongodb/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true

或者使用更老的.ini配置文件形式:

fork = true
bind_ip = 127.0.0.1
port = 27017
quiet = true
dbpath = /srv/mongodb
logpath = /var/log/mongodb/mongod.log
logappend = true
journal = true

对于大多数单机的服务器,这些基本配置已经足够。具体解释如下:

  • forktrue时,可以启用一个mongod的守护模式,可以使得MongoDB从当前session中脱离(例如,“forks”),允许我们将数据库运行为一个常规的服务器。
  • bindIp127.0.0.1,强制服务器只会监听在localhost IP上的请求。只有绑定到应用级系统可以通过由系统网络过滤(例如,防火墙)提供的存取控制的安全接口。

从2.6版本开始,从官方.deb.rpm包安装的mongod默认将bind_ip配置设置为127.0.0.1

  • port27017,为数据库实例默认的MongoDB端口,MongoDB可以绑定到任意端口,我们可以使用网络过滤工具基于端口来过滤存取。(注意:UNIX之类的系统要求超级管理员权限才能将进程放到小于1024的端口上。
  • quiettrue。这个选项只会允许输出/日志文件中最关键的条目,在生产系统中不推荐使用。如果我们确实设置了这个选项,我们可以使用setParameter来在运行时修改这个配置。
  • dbPath/srv/mongodb,指定了MongoDB将会存储数据文件的地址。srv/mongodb/var/lib/mongodb都是非常常用的地址。运行mongod的用户账号将会需要对这个目录的读写权限。
  • systemLog.path/var/log/mongodb.log为mongod写入输出的地址、如果我们不设置这个值,mongod将会把所有的输出写入到标准输出中(例如,stdout)
  • logAppendtrue,保证mongod在服务器启动操作之后不会复写一个已有的日志文件。
  • storage.journal.enabledtrue,启动日志。日志保证了单一实例的写持久性。64位版本的mongod默认启动日志,因此,这个配置可能会是冗余的。

给定了默认的配置之后,这些值的一部分可能是多余的。然而,在许多情况下,显式地指定这些配置将会提高整体的系统智能性。

安全考量

下面的集合配置选项对于限制读取mongod实例而言非常有用。考虑下面的配置,分别有YAML格式和之前配置文件格式的:

YAML格式:

security:
   authorization: enabled
net:
   bindIp: 127.0.0.1,10.8.0.10,192.168.4.24

或者使用之前的配置文件形式:

bind_ip = 127.0.0.1,10.8.0.10,192.168.4.24
auth = true

考虑这些配置选项的解释如下:

  • bindIp有3个值,127.0.0.1,localhost接口;10.8.0.10,一个私有IP地址,一般用于局域网和VPN接口;以及192.168.4.24,一个私有网络接口一般用于局域网。由于生产系统的MongoDB实例需要从多个数据库服务器上读取,所以将MongoDB绑定到多个接口以保证我们的应用服务器可以存取。同时,将这些接口限制到可控的接口并且在网络层是可保护的是非常重要的。
  • authorizationtrue,能够启动MongoDB中的认证系统。如果启动之后,我们第一次的时候将会需要通过localhost接口连接登录以创建用户凭证。

复制集和分片配置

复制集配置

复制集配置是非常直接的,只要求replSetName有一个与该集合所有成员之间一致的值。考虑下面的内容:

YAML形式:

replication:
   replSetName: set0

或者之前的配置文件形式:

replSet = set0

为每个复制集设置一个描述性的名字。一旦配置好之后。使用mongo shell来向复制集中增加主机。

增加下面的keyFile选项来启用复制集的认证:

YAML形式:

security:
   keyFile: /srv/mongodb/keyfile

或者之前的配置文件形式:

keyFile = /srv/mongodb/keyfile

设置 keyFile可以启动认证并且指定一个 key文件用于复制集成员在互相认证时使用。key文件的内容随意,但是在复制集的所有成员和连接到复制集的mongos实例中必须相同。key文件在大小上必须小于1kb,可能只能包含base64的字符,而且在Unix系统中这个文件不允许有组或者world的权限。

分片配置

分片要求mongod实例对配置服务器和分片有不同的mongod配置。配置服务器存储集群的元数据,而分片则存储数据。

如果想要在配置文件中配置 配置服务器的mongod实例,在sharding.clusterRole设置中指定configsvr

从3.4版本开始,MongoDB删除了对镜像配置服务器和的支持,配置服务器必须部署作为复制集。

 sharding:
    clusterRole: configsvr
 net:
    bindIp: 10.8.0.12
    port: 27001
replication:
    replSetName: csRS

想要将配置服务器部署为复制集的话,配置服务器必须运行WiredTiger存储引擎。初始化复制集和增加成员。

如果想要配置分片的mongod实例,将sharding.clusterRole设置指定为shardsvr。如果作为复制集运行,指定复制集名称:

sharding:
   clusterRole: shardsvr
replication:
   replSetName: shardA

如果运行为一个复制集,初始化分片复制集,然后增加成员。

对于路由(例如,mongos),使用下面的设置配置至少一个mongos进程:

sharding:
   configDB: csRS/10.8.0.12:27001

我们可以在复制集名称的后面,通过以句号分割列表的形式指定主机名称和端口来指定其它配置服务器额外成员。

在相同的系统上运行多个数据库实例

在多数情况下,在一个单一的系统中运行多个mongod实例是不推荐的。在一些类型的部署和处于测试目的,我们也许需要在同一个系统中运行多个mongod。

在这些情况下,对每个实例使用一个基础的配置,但是考虑下面的配置值:

YAML形式:

storage:
   dbPath: /srv/mongodb/db0/
processManagement:
   pidFilePath: /srv/mongodb/db0.pid

或者,如果使用之前的配置文件形式:

dbpath = /srv/mongodb/db0/
pidfilepath = /srv/mongodb/db0.pid

dbPath的值控制了mongod实例数据目录的位置。保证每个数据库有一个唯一并且标识好的数据目录。pidfilepath控制mongod进程防止其进程id文件的位置。由于进程id跟踪特定的mongod文件,因此该文件是唯一并且容易标识的是非常重要的,便于启动和停止这些进程。

创建其它的初始化脚本以及/或者调整现有的MongoDB配置,根据需要初始化脚本来控制这些进程。

SSD或者更高性能的磁盘的单租户系统可以为多个mongod实例提供可接受的性能级别。此外,我们也许会发现在单一系统上多个小工作集的数据库可能能正常运行。

诊断配置

下面的配置选项控制了用于诊断目的的不同mongod行为:

  • operationProfiling.mode设置了数据库分析器级别。由于分析器可能会影响性能,因此分析器默认是不开启的。除非这个设置是开启,查询是不会被记录和分析的。
  • operationProfiling.slowOpThresholdMs配置了决定“慢查询”的预制,用于日志系统和分析系统。默认值是100毫秒。如果数据库分析器无法返回有用的结果时可以设置一个更小的值,如果只需要记录最长运行时间的查询时,设置一个更大的值。
  • systemLog.verbosity控制了mongod写入到日志中日志输出的大小。只有在我们遇到一个无法再正常的日志级别上调试的问题时是用这个选项。

从3.0版本开始,我们也可以使用systemLog.component.<name>.verbosity>设置来指定特定组件的冗余级别。具体可用的组件见官方文档

参考文献

打赏
微信扫一扫支付
微信logo微信扫一扫, 打赏作者吧~

mickey

记录生活,写给几十年后的自己。