来源：开源中国 作者：OSC-王练 DB-Engines 发布了 2018 年 7 月份的数据库排名，排名前三的依然是 Oracle、MySQL 和 Microsoft SQL Server 。 前 20 名的数据库中，对比上个月，第 13 位和第 14 位的 Splunk 和 MariaDB 互换了位置，第 15 和第 16 位的 SAP Adaptive Server 和 Solr 位置进行了对调。 MongoDB 是此榜单中涨幅最大的一个，上涨 6.54 个百分点。若保持趋势，则有望挑战 PostgreSQL 的位置。 PostgreSQL 本月出现回落，下跌 4.86 的百分点。 18716 完整排名请查看：https://db-engines.com/en/ranking 前三强走势： 18717 PostgreSQL 和 MongoDB 走势： 18718 DB-Engines 排名的数据依据 5 个不同的因素： [*]Google 以及 Bing 搜索引擎的关键字搜索数量 [*]Google Trends 的搜索数量 [*]Indeed 网站中的职位搜索量 [*]LinkedIn 中提到关键字的个人资料数 [*]Stackoverflow 上相关的问题和关注者数量 这份榜单分析旨在为数据库相关从业人员提供一个技术方向的参考，其中涉及到的排名情况并非基于产品的技术先进程度或市场占有率等因素。无论排名先后，选择适合与企业业务需求相比配的技术，才是最重要的。

问题描述回复1、华为DDS对应的的阿里和亚马逊的哪个服务？华为云DDS，对标阿里的云数据库MongoDB；对标亚马逊的DynamoDB2、华为DDS命名中为什么不直接使用MongoDB？MongoDB是由MongoDB公司运营的一款开源数据库软件，该公司有明确的商标保护。华为处于尊重原厂、遵守商标保护法的角度，采用DDS命名，寓意MongoDB是面向文档的NoSQL数据库3、华为DDS目前和阿里的最大区别是什么？阿里的MongoDB服务化开始时间较早，在数据库生态方面较全，例如大数据分析对接等功能。华为云计划今年内在生态上追平4、华为DDS目前和阿里的最大的相同点是什么？均支持MongoDB集群（Sharding）、副本集(ReplicaSet)、单节点（Single）三种架构。分别满足高可用/高扩展性需求、高可用需求、非核心业务高性价比需求的用户选型。目前华为云DDS副本集支持包年包月购买，集群支持按需购买，单节点正在公测5、华为DDS是否支持跨AZ高可用？跨AZ特性依赖于ECS是否有跨AZ的资源，6月份华东区三AZ资源到位。预计7月20日左右上线副本集跨三AZ的能力6、为什么DDS副本集、集群不考虑跨两AZ的设计？MonogoDB集群/副本集的三节点高可用架构，存在“多数派选举机制”：若将1个节点放在1个AZ，另外2个节点放在1个AZ，当另外2个节点挂了，数据库也是不可用，因此意义不大；原生MongoDB副本集/集群架构不支持实例级别的两AZ部署，需要服务改造，目前所有云商均未提供该能力7、华为DDS跟社区版MongoDB有什么区别吗？目前由于数据库通过云化，服务化封装后，关闭了一些功能，另外华为是一家非常重视安全的公司，将一些存在安全隐患的功能也关闭了，但我们会根据市场需求，陆续通过内核改造，安全加固的方式陆续开放出来，详细区别请点击查看8、什么情况下选择集群（sharding）架构？   集群是基于多个副本集（每个副本沿用三节点高可用模式）组成。集群的主要特点是横向扩展能力强，能满足用户不断增长的数据量需求，目前DDS可支持1T~12T的数据量。因此当客户对可用性要求较高、数据量较大（>2T）、未来扩展性要求较高的情况下，推荐用户使用集群架构9、什么情况下选择副本集（replica）架构？副本集是三节点高可用的结构，DDS副本集目前最大可支持1T的数据存储量。因此，当客户对可用性要求高、数据量不大（<1T）、未来扩展性要求不高的情况下，推荐用户使用副本集架构10、什么情况下选择单节点（single）架构？单节点是一个成本低、可用性相对较弱架构选型，当前最大可支持1T的数据存储量。因此，当客户对可用性要求不高（比如非核心业务/测试场景/个人学习场景，能接受数据丢失）、数据量不大的情况下，推荐用户使用单节点架构11、集群（sharding）架构里的mongos、config、shard组件分别有什么作用？三者如何配合工作的？DDS分片集群架构由路由（mongos）、配置（config）和分片（shard）组成。数据读写请求经mongos分发，通过查询config信息，并行分配到相应shard，可轻松应对高并发场景，且config和shard均采用三副本架构，保证高可用。12、副本集的三节点高可用架构，是如何保证高可用的？DDS副本集架构由主节点（Primary）、备节点（Secondary）和隐藏节点（Hidden）组成。用户可以直接操作主节点和备节点，当主节点故障时，系统自动选出新的主节点，当备节点不可用时，隐藏节点接管服务，保证高可用13、华为DDS是怎么收费的？集群目前支持按需购买，计划7月20日左右支持包周期；副本集支持按需和包周期购买；单节点目前在公测阶段。价格与友商持平，主流价格低于友商：点击查看14、华为DDS支持MongoDB的那个版本？为什么没有小版本说明？是否会支持更多版本？目前支持的版本为3.2，子版本不呈现给用户，一方面由于子版本较多，不利于统一维护，另外随着更稳定的子版本发布，我们希望能够统一维护，帮助用户分批升级。6月20日左右，DDS可支持3.4版本15、华为DDS上MongoDB的admin库下创建不collection？基于最佳实践的考虑，DDS不允许admin下mongodb创建集合。16、华为DDS上为何Hidden不让用户看到，而secendary可以让客户看到？因为首先要实现高可用,是需要3节点的（MysQL的高可用其实也是3节点，只是有一个仲裁的角色藏在后台，用户看不到），secondary可能会被用户用于只读（虽然这样做有很多问题需要考虑），所以Hidden不可缺少，但一般需要一个保留住特殊节点，避免用户侧发出额外的工作负载，这样让hidden可以做一些特殊操作，比如：备份可以在hidden上做，而不影响Primary和secondary17、建立数据库连接失败的原因有哪些？1.数据库客户端版本与DDS支持的版本不匹配；2.账号密码错误；3.开启SSL，但是用普通方式连接：点击查看18、哪里可以查看更多场常见问题？点击查看

本帖最后由 昵称 于 2018-5-27 19:04 编辑MongoDB采用基于角色的访问控制（RBAC Role-Based Access Control）来管理对MongoDB系统的访问。 用户被授予一个或多个角色来确定用户对数据库资源和操作的访问权限。 在分配的角色之外，用户无权访问系统。 启用访问控制 MongoDB默认不启用访问控制。 使用--auth（命令行参数）或security.authorization（配置文件中参数）设置启用授权。 启用内部验证还可以启用客户端授权。 一旦启用访问控制，用户必须进行身份验证。 15967 角色 角色授予在指定资源上执行指定操作的权限。 可以在角色中明确指定每个权限，或者从另一个角色继承。 权限 权限由指定资源和资源上允许的操作组成。 资源是数据库，集合，文档或集群。 如果资源是集群，则关联的操作会影响系统的状态，而不会影响特定的数据库或集合 操作 定义了指定资源上允许的操作。比如 find, insert, update,listIndexes, createUser, replSetGetStatus等 继承权限 定义一个角色，可以包含一个或多个角色，在这种情况下角色会继承所包含角色的所有权限 一个角色可以继承本数据库的其他角色的权限，在admin数据库上创建的角色可以继承任何数据库创建的角色 查看角色的权限 在showPrivileges 和 showBuiltinRoles 权限都设置为true的情况下，用户可以通过rolesInfo命令查询角色权限 用户和角色 在用户创建的时候，可以分配角色，也可以给存在的用户授予或者撤销角色 分配了角色的用户会得到该角色的所有权限，一个用户可有多个角色，通过分配给一个用户不同数据库的角色。在一个数据库创建的用户可以具有其他数据库的操作权限 第一个创建的系统用户具有管理其他用户的权限 内置角色和用户自定义角色 Mongodb提供了内置角色，提供数据库系统用户通常需要的一些权限. 参考 MongoDB内置角色 如果内置角色不足以满足需要，MongoDB提供了方法创建或者修改用户自定义角色

本帖最后由 自在极意 于 2018-5-21 21:06 编辑增加用户 概观 MongoDB采用基于角色的访问控制（RBAC）来确定用户的访问权限。 用户被授予一个或多个角色，用于确定用户对MongoDB资源的访问权限或特权以及用户可以执行的操作。 用户应该只具有确保最小权限系统所需的最小权限集。 MongoDB系统的每个应用程序和用户都应映射到不同的用户。 此访问隔离有助于访问撤销和持续的用户维护。 先决条件 如果您为部署启用了访问控制，则可以使用localhost异常来创建系统中的第一个用户。 这第一个用户必须有权创建其他用户。 从MongoDB 3.0开始，由于本地主机异常，您只能在admin数据库上创建用户。 一旦创建第一个用户，您必须以该用户身份进行身份验证才能添加后续用户。 在启用部署的访问控制时，启用Auth提供有关添加用户的更多详细信息。 对于例行用户创建，您必须拥有以下权限：要在数据库中创建新用户，必须在该数据库资源上执行createUser操作。要向用户授予角色，您必须对角色的数据库执行grantRole操作。userAdmin和userAdminAnyDatabase内置角色在其各自的资源上提供createUser和grantRole操作。 例子 要在MongoDB部署中创建用户，请连接到部署，然后使用db.createUser（）方法或createUser命令添加用户。 用户名/密码认证 以下操作使用指定的名称，密码和角色在reporting数据库中创建用户 [code]use reporting db.createUser( { user: "reportsUser", pwd: "12345678", roles: [ { role: "read", db: "reporting" }, { role: "read", db: "products" }, { role: "read", db: "sales" }, { role: "readWrite", db: "accounts" } ] } )[/code] 身份验证见：https://docs.mongodb.com/master/tutorial/enable-authentication/ Kerberos身份验证 必须使用外部认证机制（如Kerberos）对MongoDB进行身份验证的用户必须在$ external数据库中创建，这允许mongos或mongod咨询外部来源进行身份验证。对于Kerberos身份验证，您必须将Kerberos主体添加为用户名。 您不需要指定密码。以下操作将Kerberos主体[email]reportingapp@EXAMPLE.NET[/email]添加到记录数据库的只读访问权限。 [code]use $external db.createUser( { user: "reportingapp@EXAMPLE.NET", roles: [ { role: "read", db: "records" } ] } )[/code] 有关Kerberos配置的更多信息见： https://docs.mongodb.com/master/tutorial/control-access-to-mongodb-with-kerberos-authentication/ https://docs.mongodb.com/master/tutorial/control-access-to-mongodb-windows-with-kerberos-authentication/ LDAP身份验证 必须使用外部认证机制（如LDAP）对MongoDB进行身份验证的用户必须在$ external数据库中创建，这允许mongos或mongod咨询外部来源进行身份验证。 对于LDAP认证，您必须指定一个用户名。 您不需要指定密码，因为这是由LDAP服务处理的。 以下操作为reporting用户添加对records数据库的只读访问权限。 [code] monospace;="" background:="" url("https:="" media.mongodb.org="" code-block-bg.png")="" rgb(245,="" 246,="" 247);="" line-height:="" 24px;="" border-top:="" none;="" border-right:="" border-bottom:="" border-left:="" 5px="" solid="" rgb(73,="" 71,="" 71);="" border-image:="" initial;="" border-radius:="" 0px;="" color:="" rgb(34,="" 34,="" 34);"="">use $external db.createUser( { user: "reporting", roles: [ { role: "read", db: "records" } ] } )[/code] 有关LDAP细节见： https://docs.mongodb.com/master/tutorial/configure-ldap-sasl-activedirectory/ https://docs.mongodb.com/master/tutorial/configure-ldap-sasl-openldap/

写重试3.6版本中的新功能。如果遇到网络错误，或者在副本集或分片群集中找不到健康的主节点，则允许MongoDB进行一次写重试操作。写重试入具有以下要求 1:拓扑要求：只允许在副本集或集群的环境下进行写重试操作，单节点不支持写重试2.存储引擎要求：写重试需要支持文档级锁的存储引擎，如wiredTiger 或 in-memory。注：MMAPv1 存储引擎不支持写重试MongoDB各语言驱动版本要求：JAVA 3.6Python 3.6C 1.9Node 3.0C# 2.5Ruby 2.5PHP 1.43.MongoDB 版本集群或副本集每个节点的版本需要大于等于3.6，并且每个节点的featureCompatibilityVersion 值也必须大于等于3.6启动写重试功能1.连接mongodb时指定mongodb://localhost/?retryWrites=true2.启动mongo shell时指定mongo --retryWrites持续的网络错误 MongoDB可重试写操作只能进行一次重试尝试。 这有助于解决暂时的网络错误和副本集选举，但不能解决持续的网络错误。故障转移期如果Mongodb无法在副本集或分片集分中找到健康的主节点，则MongoDB Driver将等待serverSelectionTimeoutMS毫秒后进行写重试，若还是无法连接则放弃写入。

本帖最后由 昵称 于 2018-5-20 23:01 编辑[indent]要对 MongoDB 中的客户端进行身份认证, 必须向 MongoDB 添加相应的用户。 [/indent] 用户管理接口 要添加用户, MongoDB 提供db createUser ()方法。添加用户时, 通过为用户分配角色来授予权限。 还可以更新现有用户, 例如更改密码和授予或撤消角色。 注意：在数据库中创建的第一个用户应该是具有管理其他用户权限的用户管理员。 身份认证数据库 添加用户时, 将在特定数据库中创建用户。此数据库是用户的身份认证数据库。 用户可以在不同的数据库中具有权限。即, 用户的权限不限于其身份认证数据库。通过指定用户角色到其他数据库中, 在一个数据库中创建的用户可以具有对其他数据库读取访问的权限。 用户的名称和身份认证数据库作为该用户的唯一标识符。即, 如果两个用户同名但在不同的数据库中创建, 则它们是两个独立的用户。如果您打算创建具有多个数据库权限的单个用户, 请创建该用户角色指定到相应的数据库中, 而不是在不同的数据库中多次创建用户。 用户认证 要对用户进行身份认证, 必须提供与该用户关联的用户名、密码和身份认证数据库。 要使用mongo shell 进行身份认证, 请执行以下操作之一: [*]使用mongo命令行连接到mongod 或 mongos实例时，身份认证选项 (--username, --password, and --authenticationDatabase) [*]首先连接到mongod 或 mongos实例, 然后对身份认证数据库。运行身份认证命令db.auth() 注意：在一次连接请求中，将多次身份认证为不同的用户时,不会去除以前经过身份认证的用户的凭据。这可能导致连接的权限超出了用户的预期, 并导致逻辑会话中的操作引发错误。 集中管理用户数据 MongoDB 存储所有用户信息, 包括用户名称、 用户密码和 用户的身份认证数据库, 在admin数据库的system.user集合中。 不要直接访问该集合, 而是使用用户管理命令。 分片集群用户 要创建分片集群的用户, 请连接到 mongos实例并添加用户。然后, 客户端通过mongos实例对这些用户进行身份认证。 MongoDB 将这些分片集群用户数据存储在配置服务器的admin数据库中。2.6版本之前, 对分片集群上的数据库进行身份认证的凭据驻留在该数据库的主shard上。 shard本地用户 某些维护操作 (如cleanupOrphaned、reconfig ()) 需要直接连接到shard上操作。若要执行这些操作, 必须直接连接到shard上， 并使用shard本地用户进行身份验证。 要创建shard本地管理用户, 须直接连接到shard上并创建用户。存储shard的admin的数据库中。 这些shard本地用户完全独立于通过mongos添加到分片集群的用户。shard本地用户作用于shard的范围, 不能通过mongos访问。 直接连接到shard只应用于特定于shard的维护和配置。通常, 客户端应通过mongos连接到分片集群。 Localhost Exception localhost exception允许您启用访问控制, 然后在系统中创建第一个用户。使用localhostexception, 在启用访问控制后, 连接到本地主机端口并在admin数据库中创建第一个用户。第一个用户必须具有创建其他用户的权限, 例如具有 userAdmin 或 userAdminAnyDatabase 角色的用户。 MongoDB 3.4 扩展了localhostexception允许执行方法 db. createRole ()。此方法允许通过 ldap 授权的用户在 MongoDB 中创建一个ldap 中定义的角色。 MongoDB 3.0 localhost exception发生了变化, 建立的连接仅仅具有在admin数据库中创建第一个用户的权限。在以前的版本中, 使用localhostexception获取访问权限的连接对 MongoDB 实例的访问是无限制的。 只有在 MongoDB 实例中没有创建用户时, localhost exception才适用。 对于分片集群, localhost exception分别适用于每个分片以及整个集群。创建分片集群并通过 mongos 实例添加用户管理员后, 仍然必须防止对各个shard进行未经授权的访问，可以对集群中的每个分片执行下列步骤之一: [*]创建一个系统用户 [*]在启动时禁用localhost exception. 设置 enableLocalhostAuthBypass = 0

内置角色 MongoDB提供了内置角色，可以提供数据库系统中通常需要的不同访问级别。 内置数据库用户角色和数据库管理角色角色存在于每个数据库中。 admin数据库包含其他角色。 数据库用户角色 每个数据库都包含如下角色 read提供读取所有非系统集合和system.indexes，system.js和system.namespaces系统集合的数据的能力。 readWrite提供读取角色的所有权限以及修改所有非系统集合和system.js集合上的数据的能力。 数据库管理角色 每个数据库都包含以下数据库管理角色： dbAdmin提供执行管理任务的能力，如与schema相关的任务，indexing和收集统计信息。 此角色不授予用户和角色管理的权限。 dbOwner提供对数据库执行任何管理操作的能力。 此角色结合了readWrite，dbAdmin和userAdmin角色授予的权限。 userAdmin提供在当前数据库上创建和修改角色和用户的能力。 由于userAdmin角色允许用户向任何用户（包括他们自己）授予任何特权，因此角色还间接为数据库或（如果限制为管理数据库，则为集群提供超级用户访问权限）集群提供超级用户访问权限。 集群管理角色 admin数据库包含以下用于管理整个系统而不是特定数据库的角色。 这些角色包括但不限于副本集和分片群集管理功能。 clusterAdmin提供最佳的群集管理访问。 此角色结合了由clusterManager，clusterMonitor和hostManager角色授予的权限。 此外，该角色还提供dropDatabase操作。 clusterManager在集群上提供管理和监视操作。 具有此角色的用户可以分别访问分别用于分片和复制的配置和本地数据库。 clusterMonitor为监控工具提供只读访问权限，如MongoDB Cloud Manager和Ops Manager监控代理。 hostManager提供监视和管理服务器的能力。 备份恢复角色admin数据库包含以下用于备份和恢复数据的角色： backup提供备份数据所需的权限。 此角色提供足够的权限来使用MongoDB Cloud Manager备份代理，Ops Manager备份代理或使用mongodump。 restore提供使用mongorestore恢复数据所需的特权，而不使用--oplogReplay选项或system.profile收集数据。 全数据库角色管理数据库中的这些角色适用于除mongod实例中的local数据库和config数据库之外的所有数据库： readyAnyDatabase提供与read相同的只读权限，除了它适用于群集中除local和config数据库以外的所有权限。 该角色还在整个集群上提供listDatabases操作。 readWriteAnyDatabase提供与readWrite相同的读取和写入权限，除了它适用于群集中除local和config数据库外的所有数据。 该角色还在整个集群上提供listDatabases操作。 userAdminAnyDatabase提供与userAdmin相同的用户管理操作访问权限，除了它适用于群集中除local和config数据库以外的所有操作。 dbAdminAnyDatabase提供与dbAdmin相同的数据库管理操作访问权限，除了它适用于群集中除local数据库和config数据库之外的所有数据库管理操作。 该角色还在整个集群上提供listDatabases操作。 超级用户以下角色为所有资源提供完整权限： root提供对操作和所有readWriteAnyDatabase，dbAdminAnyDatabase，userAdminAnyDatabase，clusterAdmin，restore和backup组合的资源的访问。 内部角色 system提供对数据库中的任何对象采取任何操作的权限。

15643

15418 15419

本帖最后由 lipo 于 2018-5-15 20:25 编辑Sharding模式下操作限制 [*]分片模式下不能使用的操作类型 [*]group操作符在sharding模式下无效，需要使用mapReduce或者aggregate替代。 [*]db.eval()操作在mongo3.0后版本无法使用。（被废弃） [*]geoSearch命令在分片后的模式中无法使用。 [*]$where操作符不能引用db中对象。 [*]查询的限制 [*]在mongos上使用非片键作为索引查询分片后的集合时，会覆盖不到所有数据，即查到数据可能会不全。 [*]将要分片的集合的大小限制 [*]不是所有的未分片集合都能应用分片，未分片集合的大小必须不得超过某个最大值。这个最大值可以通过配置的chunksize以及片键平均大小来估算(16777216 bytes为Bson文件最大的大小)，分片成功后的集合解除此限制： [code]maxSplits = 16777216 (bytes) / [/code][code]maxCollectionSize (MB) = maxSplits * (chunkSize / 2)[/code] [*]对单个Document的操作限制 [*]对已分片的单个Document做update或者remove操作时，必须带片键，否则会报错 [*]唯一索引的限制 [*]MongoDB不支持跨shard的唯一索引，除非此唯一索引前缀由所有的片键组成 Chunk的限制 [*]MongoDB对于chunk内超过250000条Document的chunk，或者Chunk size超过所配置Chunk size1.3倍的Chunk，均无法迁移。 [*]所配置的chunkSize可以通过db.collections.stats()内的avgObjSize查询。 片键的限制 [*]片键大小不能超过512byte。 [*]片键类型不能为multikey，文本类型key，或者geo类型的key。 [*]片键是不可变的。 [*]单调的增加片键，会影响**的吞吐量，若要避免此情况，需要使用hash的片键 [*]

本帖最后由 Mongo_奇 于 2018-5-14 20:52 编辑oplog的作用： oplog是副本集之间数据同步的纽带。本质上是一个特殊的固定集合用来记录数据库中所有更改数据的操作。备节点通过复制主节点的oplog并应用其中的操作来和主节点保持一致。oplog在local.oplog.rs中保存。 oplog的大小： Mongodb默认将其大小设置为可用disk空间的5%（默认最小为1G，最大为50G）,可以在配置文件中设置：oplogSizeMB，只有第一次生效。 oplog状态查询： replica:PRIMARY> db.getReplicationInfo() { "logSizeMB" : 10240, "usedMB" : 0.01, "timeDiff" : 1873, "timeDiffHours" : 0.52, "tFirst" : "Mon May 14 2018 09:27:51 GMT+0000 (UTC)", "tLast" : "Mon May 14 2018 09:59:04 GMT+0000 (UTC)", "now" : "Mon May 14 2018 11:28:09 GMT+0000 (UTC)" } 如何合理的设置oplog大小，以上一步的查询结果为例： 1. 计算oplog的增长速度：从输出可以看出oplog的保存了0.52小时共计520MB的数据，也就是说，业务量不变的情况下1小时大约会产生1000MB数据。[indent] [/indent][indent]2. 确定oplog时间窗： oplog时间窗可以理解需要保留oplog最大的timeDiffHours。考虑这种场景，数据库每12小时触发一次备份，恢复备份时间需要2小时。此时要给备节点进行恢复操作，则oplog需要保存十二小时的数据才能保证备节点可以和主节点完成同步。[/indent][indent]3. 计算oplog的大小： 假设oplog的增长速率为1000MB/h，需要至少保存12小时的oplog，则oplog的大小应该设为：12h*1000MB/h=12000MB[/indent] oplogSize的修改： 3.6版本之前修改比较复杂，可以参考官方文档： https://docs.mongodb.com/v3.2/tutorial/change-oplog-size/ 3.6版本之后（包括3.6版本）可以直接通过命令来修改： db.adminCommand({replSetResizeOplog: 1, size: 16000})

LVM对lv提供了快照“snapshot”备份功能，这种功能也只对LVM 有效。 当一个 snapshot创建的时候，仅拷贝原始卷里的源数据，这不是物理上的数据拷贝，因此snapshot的创建特别快，当原始卷里的数据有写入时，备份卷开 始记录原始卷哪些数据发生了变化，然后在原始卷新数据覆盖旧数据时，将旧数据拷贝到snapshot的预留空间里，起到备份数据的作用，就保证了所有数据 和创建备份卷之前的数据一致性。 而对于snapshot的读操作，如果是读取数据块是没有修改过的，那么会将读操作直接重定向到原始卷上，如果是要读取已经修改过的块，那么就读取拷贝到snapshot中的块。所以当原始卷破坏了之后还能用snapshot备份的数据还原。 快照创建成功后，源和快照共享同一份物理数据拷贝，直到数据发生写操作，此时源上老数据或者新增数据将被写向新的存储空间。为了记录和追踪块的变化和复制信息，需要一个位图(bitmap)，它用于确定实际拷贝数据的位置，以及确定从源还是目标来获取数据。并发(concurrent) 它与改变块非常相似，但它总是物理地拷贝数据。当即时拷贝执行时，没有数据被复制。取而代之，它创建一个位图来记录数据的复制情况，并在后台进行真正的数据物理复制。 写时复制快 照在快照时间点之后，没有物理数据复制发生，仅仅复制了原始数据物理位置的元数据。因此，快照创建非常快，可以瞬间完成。然后，快照副本跟踪原始卷的数据变化（即原始卷写操作），一旦原始卷数据块发生写操作，则先将原始卷数据块读出并写入快照卷，然后用新数据块覆盖原始卷。这样我们访问快照卷上的数据仍旧 是写操作前的，可以保证我们备份数据的一致性。 采取COW实现方式时，snapshot的大小并不需要和原始卷一样大。那设置成多大呢？第一、根据原始卷数据的改变大小范围来设置；第二、根据 原始卷数据的更新频率来定。一旦 snapshot的空间记录满了原始卷块变换的信息，那么这个snapshot就无法使用了。当然，如果你的snapshot大小和原始卷一样大，甚至还 要大，那snapshot备份就绝对的不会崩溃啦。 主要操作： [root@desktop21 /]# vgs VG #PV #LV #SN Attr VSize VFree vol0 2 4 1 wz--n-55.22g 26.22g [root@desktop21 /]# lvcreate -L 3G -n syslv vol0 Logical volume "syslv" created [root@desktop21 /]# lvdisplay /dev/vol0/syslv --- Logical volume --- LVName /dev/vol0/syslv VGName vol0 LVUUID xQXHqK-N3Oj-y9Z1-TBU6-hAsI-ek3V-PkmVmL LV WriteAccess read/write LVStatus available #open 0 LV Size 3.00 GiB （lv大小3G） CurrentLE 96 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Blockdevice 253:6 [root@desktop21 /]# lvcreate -s -n snapsyslv -L 50M/dev/vol0/syslv Rounding up size to full physical extent 64.00 MiB Logical volume "snapsyslv" created [root@desktop21 /]# lvdisplay /dev/vol0/snapsyslv --- Logical volume --- LVName /dev/vol0/snapsyslv VGName vol0 LVUUID snoXql-gI1Q-TSsF-F3LN-SyRI-HInY-8cZM3r LV WriteAccess read/write LV snapshot status activedestination for /dev/vol0/syslv LVStatus available #open 0 LVSize 3.00 GiB Current LE 96 COW-tablesize 64.00 MiB （我的PE为32M，创建的只能是32的倍数） COW-tableLE 2 Allocated to snapshot 0.03% （使用率为0.03%） Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Blockdevice 253:7 [root@desktop21 /]# lvs /dev/vol0/snapsyslv LV VG Attr LSize Origin Snap% Move LogCopy% Convert snapsyslv vol0 swi-a- 64.00m syslv 0.07 三、改变原始卷的数据，查看备份卷的变化 1、登录到syslv所在的系统，新建文件测试 [root@desktop64 ~]# dd if=/dev/zero of=testfile bs=1M count=20 20+0 records in 20+0 records out 20971520 bytes (21 MB) copied, 0.0329396 s, 637 MB/s [root@desktop21 /]# lvs /dev/vol0/snapsyslv LV VG Attr LSize Origin Snap% Move LogCopy% Convert snapsyslv vol0 swi-a- 64.00m syslv 33.83 [root@desktop64 ~]# dd if=/dev/zero of=testfile bs=1M count=50 50+0 records in 50+0 records out 52428800 bytes (52 MB) copied, 0.132893 s, 395 MB/s [root@desktop21 /]# lvs /dev/vol0/snapsyslv LV VG Attr LSize Origin Snap% Move LogCopy% Convert snapsyslv vol0 Swi-I- 64.00m syslv 100.00 [root@desktop21 /]# lvdisplay /dev/vol0/snapsyslv --- Logical volume --- LVName /dev/vol0/snapsyslv VGName vol0 LVUUID snoXql-gI1Q-TSsF-F3LN-SyRI-HInY-8cZM3r LV WriteAccess read/write LV snapshot status INACTIVEdestination for /dev/vol0/syslv （挂了） LVStatus available #open 0 LVSize 3.00 GiB CurrentLE 96 COW-tablesize 64.00 MiB COW-tableLE 2 Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Blockdevice 253:7 [root@desktop21 /]# lvchange -ay /dev/vol0/snapsyslv Can't change snapshot logical volume "snapsyslv" [root@desktop21 /]# lvremove /dev/vol0/snapsyslv Do you really want to remove active logical volume snapsyslv?[y/n]: y Logical volume "snapsyslv" successfullyremoved

本帖最后由 昵称 于 2018-5-14 00:02 编辑[postbg]bg3.png[/postbg] 身份认证是验证客户端身份的过程。当启用访问控制 (即授权) 时, MongoDB 要求所有客户端对自己进行身份认证, 以确定它们的访问权限。尽管身份认证和授权紧密相连, 但身份认证与授权不同。身份认证验证用户的身份;授权决定验证用户对资源和操作的访问权限。 身份认证方法 要作为用户进行身份认证, 必须提供与该用户关联的用户名、密码和身份认证数据库(一般为admin数据库) 。 使用mongo shell 进行身份认证, 执行以下操作之一: • 使用mongo命令行身份认证选项 (--username, --password, and--authenticationDatabase) 连接到 mongod 或 mongos 实例 [code]mongo –host {ip}:{port} –username {user} –password {pwd} –authenticationDatabase {auth_db}[/code] • 首先连接到 mongod 或 mongos 实例,然后在认证数据库下运行认证 命令 [code]mongo –host {ip}:{port} use {auth_db} db.auth(“{user}”, “{pwd}”)[/code] 重要 在一次连接请求中，将多次身份认证为不同的用户时,不会去除以前经过身份认证的用户的凭据。这可能导致连接的权限超出了用户的预期, 并导致逻辑会话中的操作引发错误。 身份认证机制 MongoDB 支持多种身份认证机制, 客户端可以使用这些机制验证其身份。这些机制允许 MongoDB 集成到您现有的身份认证系统中。 MongoDB 支持多种身份认证机制: • SCRAM(默认) • MongoDBChallenge and Response (MONGODB-CR) (已弃用 MongoDB 3.6) • x.509 证书身份认证。 除了支持上述机制外, MongoDB 企业还支持以下机制: • LDAP代理身份认证 • Kerberos身份认证。 内部身份认证 除了客户端认证外, MongoDB 还可以要求副本集或分片集群的成员在各自的副本集或分片集群上验证其成员身份。 可以对副本集和分片集群的成员进行身份认证。对于成员的内部身份认证, MongoDB 可以使用 keyfiles 或 x. 509 证书。Keyfiles Keyfiles 使用 SCRAM challenge andresponse身份认证机制. keyfiles 的内容用作为成员的共享密钥。密钥的长度必须介于6到1024个字符之间, 并且只能包含 base64 集中的字符。MongoDB 去除带空格字符 (例如 x0d, x09, and x20), 为了跨平台的方便。因此,下列操作产生相同的键:[code]echo -e "my secret key" > key1 echo -e "my secret key\n" > key2 echo -e "my secret key" > key3 echo -e "my\r\nsecret\r\nkey\r\n" > key4 [/code] 在 UNIX 系统上, 密钥文件不能具有group或world权限。在Windows 系统上, 不检查密钥文件权限。 密钥文件的内容在所有连接到彼此的 mongod 和 mongos 实例上必须相同. 必须将密钥文件存储在副本集或分片集群的每个成员上。要指定密钥文件, 在配置文件中使用 security.keyFile设置或使用命令行参数选项 --keyFile x. 509 副本集或分片集群的成员可以使用 x. 509 证书进行内部身份认证, 而不是使用 keyfiles。MongoDB支持用于安全 TLS/SSL 连接的 x. 509 证书身份认证。 成员证书要求： 用于验证分片集群或副本集的成员身份的成员证书必须具有以下属性: [*]单个CertificateAuthority (CA) 必须为分片集群或副本集的成员颁发所有的 x. 509 证书。 [*]在成员证书的中找到的Distinguished Name (DN)必须为以下属性的至少一个指定非空值: Organization(O), the Organizational Unit (OU) 或theDomain Component (DC) [*]Organization属性(O)、Organizational Unit属性 (OU) 和DomainComponent (DC)必须与其他集群成员的证书匹配。要匹配, 证书必须与这些属性的所有规范属性 (甚至这些属性的非规范属性) 匹配。属性的顺序无关紧要。 在下面的示例中, 两者包含匹配的规范属性以及非规范属性。[code]CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2[/code] 但是, 下面两个项包含属性的不匹配, 因为其中包含两个规范属性, 另一个则只有一个规范属性。[code]CN=host1,OU=Dept1,OU=Sales,O=MongoDB CN=host2,OU=Dept1,O=MongoDB[/code] CommonName (CN)或Subject Alternative Name (SAN) 必须与集群的其他成员使用的服务器的主机名相匹配。例如, 集群的证书可以具有以下subject:[code]subject= CN=,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=,OU=Dept1,O=MongoDB,ST=NY,C=US subject= CN=,OU=Dept1,O=MongoDB,ST=NY,C=US [/code] 如果证书包含Extended Key Usage (EKU)设置, 则该值必须包括clientAuth (“TLS Web ClientAuthentication”)。 可以不使用 Extended Key Usage (EKU) 证书的配置[code]extendedKeyUsage = clientAuth[/code] MongoDB 配置 若要为内部身份认证指定 x. 509, 除了 TLS/SSL 配置外, 对于副本集或分片集群的每个成员, 包括配置:如果使用配置文件，须配置 security.clusterAuthMode 和 net.ssl.clusterFile如果使用命令行选项 --clusterAuthMode --sslClusterFile 成员证书和PEMKeyFile要为客户端证书身份认证配置 MongoDB, mongod 和 mongos 需要指定PEMKeyFile 以向客户端证明其身份, 方法是通过配置文件中的 net.ssl.PEMKeyFile参数或命令行选项--sslPEMKeyFile如果未为内部成员身份认证指定 clusterFile 证书, MongoDB 将尝试使用PEMKeyFile证书进行成员身份认证。为了使用PEMKeyFile证书进行内部身份认证以及客户端身份认证,必须:忽略extendedKeyUsage配置指定extendedKeyUsage配置。包括clientAuth 和 serverAuth[s][/s] 分片集群的身份认证 在分片集群中, 客户端通常直接连接mongos 实例进行身份认证。但是, 某些维护操作可能需要直接对特定的shard进行身份认证。

本帖最后由 自在极意 于 2018-5-13 17:43 编辑概述 MongoDB给用户提供了单个集合的批量操作，包括批量**，更新和删除操作。 顺序操作与无序操作 使用有序的操作，Mongodb串行执行操作。如果在写入操作的一个过程中发生错误，Mongodb将返回而不处理列表中的剩余写入操作。 使用无序的操作，Mangodb可以并行执行操作。如果在写入操作的一个过程中发生错误，Mongodb将继续处理列表中的剩余写入操作。 串行操作通常比并行操作慢，因为使用有序列表，每个操作必须等待先前的操作完成。 默认情况下，bulkwrite()执行有序操作。若要指定无序写入操作，请在选项文档中设置ordered: false。 bulkwrite方法介绍 bulkwrite支持如下写操作： [code]db.collection.insertOne()db.collection.updateOne()db.collection.updateMany()db.collection.replaceOne()db.collection.deleteOne()db.collection.deleteMany()[/code] 每个写操作把文档封装成数组传递给bulkwrite 例如，下面执行多个写入操作： characters 集合包含以下文档： [code]{ "_id" : 1, "char" : "Brisbane", "class" : "**", "lvl" : 4 }, { "_id" : 2, "char" : "Eldon", "class" : "alchemist", "lvl" : 3 }, { "_id" : 3, "char" : "Meldane", "class" : "ranger", "lvl" : 3 }[/code] 如下bulkwrite对集合执行多个操作 [code]try {db.characters.bulkWrite([{ insertOne :{"document" :{"_id" : 4, "char" : "Dithras", "class" : "barbarian", "lvl" : 4}}},{ insertOne :{"document" :{"_id" : 5, "char" : "Taeln", "class" : "fighter", "lvl" : 3}}},{ updateOne :{"filter" : { "char" : "Eldon" },"update" : { $set : { "status" : "Critical Injury" } }}},{ deleteOne :{ "filter" : { "char" : "Brisbane"} }},{ replaceOne :{"filter" : { "char" : "Meldane" },"replacement" : { "char" : "Tanys", "class" : "oracle", "lvl" : 4 }}}]);}catch (e) {print(e);}[/code] 返回结果如下[code]{"acknowledged" : true,"deletedCount" : 1,"insertedCount" : 2,"matchedCount" : 2,"upsertedCount" : 0,"insertedIds" : {"0" : 4,"1" : 5},"upsertedIds" : {}}[/code] 批量装入策略 大批量的**操作，包括初始数据**或常规数据导入，可能会影响shard集群性能。对于批量**，考虑以下优化策略： 分片预拆分 如果shard集合是空的，那么集合只有一个初始chunk，它位于单个shard上。Mongodb必须耗费大量时间来接收数据、创建拆分，并将分割的chunk分发到可用shard钟。为了避免这种性能成本，可以预先配置集合分割策略，分割操作见 https://docs.mongodb.com/manual/tutorial/split-chunks-in-sharded-cluster/。 Mongos无序写入 为了提高对shard集群的写入性能，可以将bulkwrite参数有序集设为false。mongos将会同时对多个shard进行写操作。对于空集合，依然需要配置集合的分割策略，相关操作如上连接所示。

总览：当你想把某个mongodb实例中的数据导出，然后再导入到另一mongodb的实例的时候，有两种工具可以选择。导出：mongodump和mongoexport，导入mongorestore和mongoimport。那当我们想导入导出数据时到底应该选择哪种工具呢？下面我们详细分析两种工具的不同点。 mongoexport,mongoimport导出导入的数据格式更丰富 mongoexport可以把实例中的数据导出成JSON, CSV格式的数据。JSON，CSV格式的数据方便人眼阅读，并且很多程序都能处理这些格式的数据。如果要使用一些程序对实例中的数据进行分析，那么JSON,CSV格式的数据便有很大的优势，各种分析处理程序都支持这两种通用的文件格式。而mongodump只能把数据保存为BSON的格式，BSON大家可以把它想象成JSON的二进制模式,既然是二进制模式那肯定人眼是无法直接阅读的，为了能够人眼阅读，需要使用bsondump(mongodb的开源工具)将BSON格式的数据转换成JSON格式的数据，用法很简单 bsondump test.bson > test.json，即可转换成人眼能够阅读的JSON格式数据。 mongoexport导出的数据会丢掉一些数据类型前面说了mongoexport 导出的数据是JSON,CSV格式的数据，而mongodb实例本身里面的数据类型其实是BSON的数据类型。而JSON是无法真正表达所有BSON的数据类型，只能表达BSON数据类型的一个子集，精确的说JSON对某些BSON数据类型使用的是严格模式(strict mode).例如BSON里面对于时间有Date这种数据类型，而转成JSON格式的时候就是一个字符串类型来代表Date，显然这种表示方式会丢掉一些数据类型。所以对于线上正式环境，如果数据类型很多，尽量避免使用mongoexport，mongoimport导出导入数据。以免丢掉源库中的某些数据类型。 mongoexport，mongoimport需要的权限更少 mongoexport导出数据，只需要目标库的read role权限，mongoimport 导入数据只需要目标库readWrite role权限。Mongodump导出数据需要目标库read权限，admin以及local数据库read权限。Mongorestore导入数据需要readWrite权限。显示mongodump需要的权限更多。 mongodump,mongorestore能够使用oplog 如果导出过程比较长，而这段时间变更的数据怎么办呢，大家脑海里冒出来的就是使用oplog来同步这段时间的数据。如果要使用oplog那就只有mongodump和mongorestroe了，这对工具在加了—oplog参数后会将导出这段时间的任何数据变更记录到oplog.bson里面，就可以做到任意时间的数据同步了。而mongoexport和mongoimport就没有这个功能了。 mongoexport,mongoimport不会导出shard模式下的元数据信息Shard模式下。Mongodb实例分为mongos，config，shard。其中config记录的是管理整个集群数据的元数据信息，例如哪些数据存在哪些shard,各个shard的名字以及其中成员信息。对应这些信息mongoexport是不会导出来的，它只是导出数据，然后使用mongoimport将这些数据一条一条**到目标库，而不管目标库的shard个数，因为这些都是目标库自己内部处理的。而mongodump，mongorestroe则可以并行分别导出shard,config数据，这样导出导入数据速度更快，当然也有一个问题如果目标库和源库的shard成员信息不一样，mongorestore导入数据后，还需要将config里面的数据改为目标库对应的信息。否则集群是无法使用的。 总结： 上面就是两对导入导出工具在大方面的不同了，至于细节，大家可以在mongodb官网上阅读他们的使用指南，看他们各自支持的参数。当你面对你的应用环境时到底选择哪种工具，可以参考下这些大方面的不同点，然后选择合适的工具完成你的需要。