MongoDB操作最佳实践(七)

网络

 

始终在可信任的网络规则环境中运行MongoDB以阻止所有未知的访问。与MongoDB系统通信的预定义进程数量很多：应用程序服务、监视进程和在副本集或分片集群中运行的其他MongoDB进程。

默认情况下，MongoDB进程将绑定到系统上的所有可用网络接口。如果系统具有多个网络接口，则将MongoDB进程绑定到私有或内部网络接口。

MongoDB安全教程提供了有关MongoDB默认端口号、MongoDB防火墙、VPN和其他主题的详细信息。查看本指南后面的Security部分，了解有关保护部署的最佳实践的更多信息。

当在虚拟机上运行时，使用准虚拟化驱动程序来实现优化的网络和存储接口，该接口以最小的开销在虚拟机和管理程序之间传递指令。

内网集群网络压缩

作为一个分布式数据库，MongoDB在查询路由和节点间复制过程中依赖于有效的网络传输。MongoDB 3.4引入了压缩用于集群内通信的有线协议的新选项。基于快速压缩算法，网络流量可以被压缩高达70%，在带宽受限的环境中提供了明显的性能优势，并且降低了网络成本。

压缩在默认情况下是关闭的，但是可以通过将networkMessageCompressors设置为snappy来启用。对网络流量进行压缩和解压缩需要CPU资源——通常需要较低的单位数字百分比开销。压缩对于那些性能受到带宽瓶颈并且有足够CPU容量的环境是理想的选择。

通过了生产验证的建议

MongoDB 生产说明中维护了关于操作系统、文件系统、存储设备和其他与系统相关的主题指定配置的最新建议。

持续可用性

在正常操作条件下，MongoDB系统将根据系统的性能和功能运行。然而，某些不可避免的故障或意外行为会以不利的方式影响系统。硬盘驱动、网卡、电源和其他硬件组件将发生故障。这些风险可以通过冗余硬件组件来减轻。类似地，MongoDB系统通过其软件组件提供可配置的冗余以及可配置的数据冗余。

日志记录

MongoDB实现了写操作之前的日志记录，以便在存储引擎中实现快速崩溃恢复和持久性。在服务器崩溃的情况下，在重新启动服务器进程时恢复日志条目。

日志的行为取决于配置的存储引擎：

• WiredTiger日志确保在checkpoints间隔里写入持久化到磁盘。WiredTiger使用checkpoints 将数据闪存到磁盘，默认情况下是在前一个闪存之后或在写入2GB数据之后每隔60秒闪存一次。因此，在缺省情况下，WiredTiger在没有日志的情况下运行时会损失超过60秒的写操作的数据——如果使用复制到其他节点以获得额外的持久性的话，这种损失的风险通常要小得多。WiredTiger提前写入日志对于在未清理的关闭事件中保持数据文件处于一致状态是不必要的，因此在没有启用日志记录的情况下运行是安全的，但是为了确保持久性，应该使用“replica safe”的write concern策略（有关更多信息，请参阅指南后面的Write Availability部分）。
• 默认情况下，MMAPv1向磁盘提交的日志至少每隔100ms发出一次，如果日志位于单独的设备上，则至少每隔30ms发出一次。除了提供持久化，该日志记录还防止了系统不正常关闭时的错误。默认情况下，MongoDB使用MMAPv1时是启用日志记录的。如果没有日志限制，任何生产部署都不应该运行。

 

 

WiredTiger和MMAPv1存储引擎的另一个特点是能够压缩磁盘上的日志，从而减少存储空间。

对于其他保证，管理员可以配置日志记录的write concern策略，从而让MongoDB仅在将数据提交到日志之后才确认写操作成功。当使用write concern大于1和v1复制协议3时，应用程序将直到写入日志记录在指定的数量的从数据库上时才收到确认，并且当使用“majority”的write concern策略时，还必须在主节点上日志记录。

 

在单独的存储阵列上存放MongoDB的日志文件和数据文件有助于提高性能。日志的I/O模式本质上是顺序的，并且非常适合为快速顺序写入而优化的存储设备，而数据文件非常适合为随机读取和写入而优化的存储设备。简单地将日志文件放在单独的存储设备上通常通过减少磁盘争用来提高性能。

 

从文档中了解关于日志的更多信息。

数据冗余

MongoDB使用本地复制维护多个数据副本，称为副本集。用户应该使用副本集来帮助防止数据库停机。在MongoDB中，副本故障转移是完全自动的，因此在发生故障恢复节点时不需要手动干预。

副本集由多个副本节点组成。在任何给定时间，一个成员充当主副本，而其他成员充当从副本。如果主成员由于任何原因（例如，主机系统的故障）而失败，则自动将从成员之一选为主成员并开始接受所有写入。

复杂的算法控制选举过程，确保只有最合适的从成员被提升为主成员，并减少不必要的故障转移（也称为“误报”）的风险。选举算法处理一系列参数，包括历史分析，以识别那些应用了来自主要、心跳和连接状态的最新更新的复制集成员，以及分配给复制集成员的用户定义的优先级。例如，只有在主数据中心发生故障时，管理员才能将位于辅助数据中心的所有副本配置为候选。一旦选择了新的主副本集成员，剩余的从成员将自动开始从新的主副本进行复制。如果原始主副本重新联机，它将认识到它不再是主副本，并将重新配置它自己成为从副本集成员。

MongoDB副本集中的副本节点的数量是可配置的，并且如果多台机器发生故障，大量副本节点可以提供针对数据库停机的增强保护。当节点关闭时，MongoDB将继续运行。DBA或系统管理员应该恢复或替换失败的副本，以减轻系统临时降低的弹性。

副本集还通过向系统管理员提供操作硬件和软件维护的选项，而不破坏整个系统来提供操作灵活性。使用滚动升级，在管理员降级主机以完成升级之前，可以依次升级副本集的辅助成员。当使用Ops Manager或Cloud Manager时，这个过程是完全自动的——在本指南的后面讨论。

在使用副本集开发时考虑以下因素：

 

• 确保副本集的成员将始终能够选举主节点。必须有严格多数的投票群组成员可用，并且彼此联系，以选举新的主节点。因此，您应该运行奇数个成员，但如果您确实具有偶数个成员，则阻止一个成员投票，或将仲裁者（仅用于参与主服务器的选举的复制集的成员）添加到您的应用服务器之一，以便存在奇数个投票成员。在一个副本集中至少应该有三个副本，其中包含数据的副本。

 

• 最佳实践是至少有3个数据中心，这样一来在任何单个站点丢失后整体是可用的。如果只有两个站点是可能的，那么就知道在任何网络分区的情况下大多数成员将在哪里，并试图确保副本集可以从位于该主数据中心的成员中选择一个主站点。

 

• 考虑在副本集中包含隐藏成员。隐藏副本集成员永远不能成为主要成员，通常用于备份，或者运行需要与常规操作工作负载隔离的应用程序，如分析和报告。也可以部署延迟复制集成员，这些成员对指定的时间延迟应用更改，以提供从非故意的操作，例如意外删除集合。

 

有关复制集的更多信息可以在Replication MongoDB文档页面上找到。

多数据中心复制

MongoDB副本集允许在数据中心内部和跨数据中心进行弹性部署设计，这些设计可以防止服务器、机架和区域级别的故障。在自然或人为灾难的情况下，当MongoDB副本集跨数据中心部署时，单个数据中心的故障可以在没有停机的情况下得到处理。

 

写入保证

MongoDB允许管理员在向数据库发出写操作时指定持久性保证级别，这称为write concern。可以根据每个连接、每个数据库、每个集合、甚至每个操作基础配置以下选项。选择如下：

 

• Write Acknowledged：这是默认的write concern。mongod将确认写操作的执行结果，允许客户端捕获网络、复制密钥、文档验证和其他异常。
• Journal Acknowledged：mongod只有在将操作提交给主日志后才确认写操作结果。这保证了写操作可以在mongod崩溃中幸存，并确保写操作在磁盘上是持久的。
• Replica Acknowledged:还可以等待对其他副本集成员的写确认。MongoDB支持对指定数量的副本进行写入。这也确保了写操作成功写入了从节点的日志记录中。因为副本可以跨数据中心内的机架和多个数据中心部署，所以确保写传播到其他副本可以提供非常健壮的耐用性。
• Majority：此write concern等待写操作成功写入了于大多数复制集成员。这也确保了写入记录在日志中的这些副本上——包括在主副本上。
• Data Center Awareness: 使用标记集，可以创建复杂的策略以确保在确认成功之前写入数据以指定副本的组合。例如，可以创建需要写入两个大陆上的至少三个数据中心，或者指定数据中心的两个机架上的两个服务器。有关更多信息，请参阅MongoDB文档中的Data Center Awareness。

 

Read Preferences

 

从主副本读取是默认配置，因为它保证了一致性。如果需要更高的读取吞吐量，建议利用MongoDB的自动分片来跨多个主要成员分配读取操作。

在某些应用程序中，副本集可以提高MongoDB部署的可伸缩性。例如，分析和业务智能（BI）应用程序可以对从副本执行查询，从而减少主副本的开销，并使MongoDB能够服务于单个部署的操作和分析工作负载。另一个配置选项基于ping距离将读取指向最接近用户的副本，这可以显著减少读取延迟。以读取稍微过时的数据为代价的全局分布式应用程序中的操作。

一个非常有用的选项是primaryPreferred，它仅在主副本不可用时才发出对从副本的读取。这种配置允许在短时间故障转移过程中读取的持续可用性。

有关可配置读取主题的更多信息，请参阅副本集Read Preference上的MongoDB文档页面。

 

Read Concerns

为了确保隔离和一致性，readConcern可以设置为多数，以指示如果数据已经复制到副本集中的大多数节点，则数据应该只返回到应用程序，因此在出现故障时不能回滚。

MongoDB 3.4增加了一个新的readConcern级别“Linearizable”。Linearizable的 read concern确保节点仍然是在读取时设置的副本的主要成员，并且如果随后选择另一个节点作为新的主要成员，则它所返回的数据不会回滚。配置此 read concern级别会对延迟产生显著影响，因此应该提供maxTimeMS值以便超时长时间运行的操作。

readConcern对于MMAPv1不可用。

主节点选举

如果主节点不可用，则如果使用除默认主节点之外的read preference选项，则读取可以继续，但是对该副本集的任何写入都将失败，直到：

 

如果主节点仅在短时间内不可用（例如，由于瞬时网络故障），那么最好的方法是等待它在线返回。然而，如果主节点不会很快复原，那么您希望系统快速地选择并促进新的主节点接管。显然，根据服务需求、系统配置和数据库运行的环境，可以达到平衡。

MongoDB 3.2引入了一种增强的复制协议，该协议在主节点故障时提供更快的服务恢复，以及更严格的持久性保证。增强的复制协议扩展了Raft一致性算法，以提供更大的部署灵活性，同时保持与早期MongoDB版本中提供的复制构造的兼容性。特别注意的是，该协议维护对复制集仲裁者、复制集成员选择优先级以及从其他辅助节点复制辅助成员的支持，以启用链式复制。

增强的复制协议通过优化用于检测副本集主节点故障和选择新主节点故障的算法，来减少故障转移间隔。故障转移时间取决于几个因素，包括网络延迟。对于系统来说，避免不必要的故障转移，并且为不同部署的需要提供灵活性非常重要。使用electionTimeoutMillis参数来优化您的系统以获得最佳的故障转移行为：

• 值越大，故障转移越慢，但是降低了对网络延迟和主节点上负载的敏感性。
• 值越小，故障转移越快，但是增加了对网络延迟和主要负载的敏感性。

 

electionTimeoutMillis默认值是 1 0,000

毫秒（10秒）——在大多数环境中，这将提供一个健壮的集群，该集群能够容忍正常的网络可变性，但是如果您有更严格的故障转移需求和可预测的网络基础设施，那么您可以使用更低的值进行测试。

 

扩展MongoDB系统

分片的水平扩展

MongoDB使用称为分片的技术对数据库提供水平扩展，这对应用程序是透明的。MongoDB跨多个称为分片的副本集分发数据。通过自动平衡，MongoDB确保随着数据量的增加或集群大小的增加或减小，数据在分片之间均匀分布。分片允许MongoDB部署扩展到超过单个服务器的限制，例如RAM或磁盘I/O中的瓶颈，而不会增加应用程序的复杂性。

MongoDB支持三种类型的分片策略，使管理员能够适应不同的查询模式：

 

• 基于范围的分片：文档基于片键在分片之间分布。具有相互接近的片键的文档可能位于同一分片上。这种方法非常适合需要优化基于范围的查询的应用程序。
• 基于哈希值的分片： 文档基于片键的MD5哈希值均匀地分布。具有相互接近的片键的文档不太可能位于同一碎片上。这种方法保证了写在分片之间的均匀分布——只要片键具有高的基数——使得它对于写密集型工作负载是最佳的。
• 区域：MongoDB区域（在早期MongoDB版本中描述为tag-aware分片）允许精确控制数据物理存储的位置，适应一系列部署场景——例如地理、硬件配置或应用程序。管理员可以通过修改碎片键范围来不断重新调整数据放置规则，MongoDB将自动将数据迁移到其新专区。MongoDB 3.4在Ops Manager和Cloud Manager中添加了新的帮助函数和附加选项来配置区域，这对于管理大型部署是必不可少的。

 

虽然分片功能非常强大，但是它可以为MongoDB部署增加操作复杂性，并且它还有额外的基础设施需求。因此，用户应该根据需要并在实际操作需求指示时进行切分。

 

在下列情况下，用户应该考虑部署分片集群：

 

• RAM限制：系统活动工作集的大小加上索引预计将超过系统中最大RAM量的容量。
• 磁盘I/O限制：系统将具有大量的写入活动，并且操作系统将无法足够快地写入数据以满足需求，或者I/O带宽将限制写入到磁盘的速度。
• 存储限制：数据集将增长到超过系统中单个节点的存储容量。
• 位置感知需求：数据集需要分配给指定数据中心以支持低延迟的本地读写。或者，创建将热数据和冷数据分离到指定卷上的多温度存储基础设施。

 

满足这些标准或者将来可能达到这些标准的应用程序应该预先设计分片，而不是等到它们消耗了可用容量才进行分片。最终受益于分片的应用程序在设计数据模型时应该考虑要分片的集合和对应的片键。如果系统已经达到或超过其容量，那么在不影响应用程序性能的情况下部署分片将是一个挑战。

 

分片最佳实践

选择分片的用户应该考虑以下最佳实践：

选择一个好的片键。在选择作为片键的字段时，至少有三个关键标准需要考虑：

1. 基数：默认情况下，数据分布以64MB的块进行管理。低基数（例如，用户的国籍）将会因为片的数量少而将文档分组到一起，这反过来将需要频繁地重新平衡块，并且单个国家可能超过64MB的块大小。相反，片键应该有高基数。

2.  插入扩展：写应该基于片键均匀地分布在所有分片上。例如，如果片键是单调递增的，则所有插入将转到相同的分片，即使它们显示出高基数，从而导致插入热点。相反，片键应该是均匀分布的。

3. 查询隔离：查询应该以指定分片为目标，以最大化可伸缩性。如果查询不能与指定分片隔离，则所有分片将以称为分散/聚集的模式进行查询，这比查询单个分片效率低。

 

有关选择片键的更多信息，请参阅选择片键的注意事项。

在需要之前扩容。集群维护的风险更低，并且如果在系统过度使用之前添加了容量，则更容易管理。

运行三个或更多个Config服务器来提供冗余。生产部署必须使用三个或多个Config服务器。Config服务器应该部署在一个对各种故障都具有健壮性和弹性的拓扑中。

使用副本集。分片和复本集是完全兼容的。复本集应该在所有部署中使用，并且分片应该在适当的时候使用。分片允许数据库利用多个服务器来提供数据容量和系统吞吐量。复本集跨服务器、服务器机架甚至数据中心维护数据的冗余副本。

使用多mongos实例

对批量插入应用最佳实践。将数据预分割成多个块，以便在插入过程中不需要平衡。或者，在大容量负载期间禁用平衡器。此外，使用多个mongos实例并行加载以提高吞吐量。有关更多信息，请参阅MongoDB文档中的Sharded Cluster中的Create Chunks。

 

 

动态数据平衡器

当数据加载到MongoDB中时，系统可能需要使用称为平衡器的进程在集群中的分片之间动态地重新平衡块。平衡操作试图通过每次只移动一个文档块来最小化对集群性能的影响，并且当超过分布阈值时只迁移块。当执行平衡时，可以禁用平衡器或者进行配置，以进一步最小化对性能的影响。

地理分布

可以配置分片，以便将指定范围的片键值映射到物理分片位置。区域分割允许MongoDB管理员控制MongoDB集群中文档的物理位置，即使部署跨越不同区域中的多个数据中心。

可以将副本集、区域分片、read preferences和write concern的特性结合起来，以便提供地理上分布的部署，使用户能够读取和写入本地数据中心。管理员可以将分片集合限制为一组特定的碎片，从而有效地为不同用户联合这些分片。例如，可以标记所有美国数据并将其分配给位于美国的碎片。

要了解更多信息，请下载MongoDB多数据中心部署指南。