Merge branch 'master' of github.com:tjworks/docs

Author: jerry-shao

locale/zh/LC_MESSAGES/faq/diagnostics.po

@@ -27,9 +27,9 @@ msgid ""
 "list of FAQs </faq>` or post your question to the `MongoDB User Mailing List"
 " <https://groups.google.com/forum/?fromgroups#!forum/mongodb-user>`_."
 msgstr ""
-"如果你没能发现你需要的答案，检查 :doc:`complete FAQs列表 </faq>` "
-"或者向 ` MongoDB 用户邮件列表提交你的问题 "
-" <https://groups.google.com/forum/?fromgroups#!forum/mongodb-user>`_."
+"如果你没能发现你需要的答案，检查 :doc:`complete FAQs 列表 </faq>` "
+"或者向 ` MongoDB 用户邮件列表"
+" <https://groups.google.com/forum/?fromgroups#!forum/mongodb-user>`_ 提交你的问题."
 
 #: ../source/faq/diagnostics.txt:17
 msgid ""
@@ -285,6 +285,10 @@ msgid ""
 "documents, then indexes will more likely stay in RAM, but it depends on your"
 " particular usage."
 msgstr ""
+"MongoDB使用操作系统将数据从磁盘读取到内存中。它单纯的 :ref:` 内存映射 <faq-storage-memory-mapped-files>` "
+"所有的数据文件并且使用操作系统缓存数据。在内存运行效率低的情况下，操作系统"
+"会通常从内存中清除最近最少使用数据(LRU)，例如如果客户端比访问文档更频繁的访"
+"问索引，这是索引将更可能的驻存在内存中，但是这取决于您的特定用法。"
 
 #: ../source/faq/diagnostics.txt:211
 msgid ""
@@ -293,17 +297,21 @@ msgid ""
 "on your access patterns, what indexes you have, and the size of your "
 "documents."
 msgstr ""
+"要计算你需要多少内存，你必须预估工作集的大小，或者客户端经常使用的那部分数据。"
+"这取决于你的访问模式，你有哪些索引和你的文档的大小。"
 
 #: ../source/faq/diagnostics.txt:216
 msgid ""
 "If page faults are infrequent, your working set fits in RAM. If fault rates "
 "rise higher than that, you risk performance degradation. This is less "
 "critical with SSD drives than with spinning disks."
 msgstr ""
+"如果页面错误是罕见的，你的工作集和内存相互适合。如果错误比率升高，高于你的风险，"
+"性能会下降。固态硬盘（SSD）的临界值比旋转型磁盘（spinning disks）更少。"
 
 #: ../source/faq/diagnostics.txt:222
 msgid "How do I read memory statistics in the UNIX ``top`` command"
-msgstr ""
+msgstr "我如何在UNIX的 ``top`` 命令中显示内存统计？"
 
 #: ../source/faq/diagnostics.txt:224
 msgid ""
@@ -314,33 +322,43 @@ msgid ""
 " doesn't have other processes running, ``RSIZE`` (resident bytes) is the "
 "total memory of the machine, as this counts file system cache contents."
 msgstr ""
+"因为 :program:`mongod` 使用 :ref:`内存-映射 文件 <faq-storage-memory-mapped-files>` ，"
+"在 ``top`` 中显示内存统计需要用特殊的方法解释。在一个大型数据库中， ``VSIZE`` （虚拟字节）"
+"往往是整个数据库的大小。如果 :program:`mongod` 没有其他的进行运行， ``RSIZE`` （常驻字节）"
+"是机器的内存总额，和文件系统缓存内容的数目一样。"
 
 #: ../source/faq/diagnostics.txt:232
 msgid ""
 "For Linux systems, use the ``vmstat`` command to help determine how the "
 "system uses memory. On OS X systems use ``vm_stat``."
 msgstr ""
+"在Linux系统上，使用 ``vmstat`` 命令来帮助确定系统如何使用内存。在 OS X系统"
+"上使用 ``vm_stat`` 命令。"
 
 #: ../source/faq/diagnostics.txt:236
 msgid "Sharded Cluster Diagnostics"
-msgstr ""
+msgstr "分片集群的诊断"
 
 #: ../source/faq/diagnostics.txt:238
 msgid ""
 "The two most important factors in maintaining a successful sharded cluster "
 "are:"
 msgstr ""
+"成功维护分片集群最重要的两个因素是："
 
 #: ../source/faq/diagnostics.txt:240
 msgid ""
 ":ref:`choosing an appropriate shard key <sharding-internals-shard-keys>` and"
 msgstr ""
+":ref:`选择一个恰当的片键 <sharding-internals-shard-keys>` "
 
 #: ../source/faq/diagnostics.txt:242
 msgid ""
 ":ref:`sufficient capacity to support current and future operations "
 "<sharding-capacity-planning>`."
 msgstr ""
+":ref:`足够的性能来支持当前和未来的业务 "
+"<sharding-capacity-planning>`."
 
 #: ../source/faq/diagnostics.txt:245
 msgid ""
@@ -350,17 +368,23 @@ msgid ""
 "the current resources become saturated. Continue reading for specific issues"
 " you may encounter in a production environment."
 msgstr ""
+"在你的部署中选择最合理的 :term:`片键` ，并且确保总是在你的集群现有的资源趋于饱和"
+"之前增加额外的容量，可以避免大部分在分片过程中遇到的问题。继续阅读在生产环境中遇"
+"到的特殊问题。"
 
 #: ../source/faq/diagnostics.txt:254
 msgid "In a new sharded cluster, why does all data remains on one shard?"
 msgstr ""
+"在一个新的分片集群，为什么所有的数据仍然在一个分片？"
 
 #: ../source/faq/diagnostics.txt:256
 msgid ""
 "Your cluster must have sufficient data for sharding to make sense. Sharding "
 "works by migrating chunks between the shards until each shard has roughly "
 "the same number of chunks."
 msgstr ""
+"你的集群必须有足够的数据去做有意义的分片。分片工作在分片之间迁移数据块,直到"
+"每个分片都有数量大致相同的数据块。"
 
 #: ../source/faq/diagnostics.txt:260
 msgid ""
@@ -371,6 +395,10 @@ msgid ""
 "behaviors help prevent unnecessary chunk migrations, which can degrade the "
 "performance of your cluster as a whole."
 msgstr ""
+"数据块默认的大小是64M。集群中数据块的不平衡程度超过 :ref:`迁移阀值 <sharding-migration-thresholds>` "
+"之前，MongoDB不会开始迁移。虽然可以通过 :setting:`~sharding.chunkSize` 设置"
+"默认的数据块大小，这些行为有助于防止不必要的数据块迁移，这回降低你的集群的"
+"整体性能。"
 
 #: ../source/faq/diagnostics.txt:267
 msgid ""
@@ -380,6 +408,9 @@ msgid ""
 "shard. Either lower the :ref:`chunk size <sharding-chunk-size>` setting, or "
 "add more data to the cluster."
 msgstr ""
+"如果你刚刚部署了分片集群，请确认你有足够足够的数据使得分片生效。如果没有足够的"
+"数据创建多于8个64M的数据块，那么所有的数据仍然在一个分片上。或者降低你的"
+" :ref:`chunk size <sharding-chunk-size>` 设置，或者向集群中增加足够的数据。"
 
 #: ../source/faq/diagnostics.txt:273
 msgid ""
@@ -389,19 +420,25 @@ msgid ""
 " You can either wait until your application inserts data *or* :doc:`split "
 "chunks manually </tutorial/split-chunks-in-sharded-cluster>`."
 msgstr ""
+"作为一个相关的问题，系统只有在插入或者更新的时候分离数据块，这意味着，如果你"
+"配置了分片，但是没有继续进行插入或者更新操作，数据库将不会创建任何数据块。"
+"你可以等到应用插入数据或者 :doc:`手动分块 </tutorial/split-chunks-in-sharded-cluster>` 。"
 
 #: ../source/faq/diagnostics.txt:279
 msgid ""
 "Finally, if your shard key has a low :ref:`cardinality <sharding-shard-key-"
 "cardinality>`, MongoDB may not be able to create sufficient splits among the"
 " data."
 msgstr ""
+"最后，如果你的片键有一个低 :ref:`基数能力 <sharding-shard-key-cardinality>` "
+"，MongoDB 可能无法在数据之间创造足够的隔离。"
 
 #: ../source/faq/diagnostics.txt:284
 msgid ""
 "Why would one shard receive a disproportion amount of traffic in a sharded "
 "cluster?"
 msgstr ""
+"为什么一个分片在分片集群中接收到的通信量不均衡？"
 
 #: ../source/faq/diagnostics.txt:286
 msgid ""
@@ -410,86 +447,110 @@ msgid ""
 "this is the result of a shard key that does not effectively allow "
 ":ref:`write scaling <sharding-shard-key-write-scaling>`."
 msgstr ""
+"在某些情况下，一个单独的分片或者一个分片集群中的子集会接收比例不均衡的通信和"
+"工作负载。几乎所有的情况下，都是片键不能有效的允许"
+":ref:`写扩展 <sharding-shard-key-write-scaling>`."
 
 #: ../source/faq/diagnostics.txt:291
 msgid ""
 "It's also possible that you have \"hot chunks.\" In this case, you may be "
 "able to solve the problem by splitting and then migrating parts of these "
 "chunks."
 msgstr ""
+"也有可能是由于你的实例中有\"热块\"（hot chunks）。 在这种情况下，你能够通过分离然后迁移"
+"部分数据块解决这个问题。"
 
 #: ../source/faq/diagnostics.txt:295
 msgid ""
 "In the worst case, you may have to consider re-sharding your data and "
 ":ref:`choosing a different shard key <sharding-internals-choose-shard-key>` "
 "to correct this pattern."
 msgstr ""
+"在最坏的情况下，你可能需要考虑重新分片你的数据并且"
+" :ref:`选择一个不同的片键 <sharding-internals-choose-shard-key>` "
+"来适应这个模式。"
 
 #: ../source/faq/diagnostics.txt:300
 msgid "What can prevent a sharded cluster from balancing?"
-msgstr ""
+msgstr "什么会破坏分片集群的平衡？"
 
 #: ../source/faq/diagnostics.txt:302
 msgid ""
 "If you have just deployed your sharded cluster, you may want to consider the"
 " :ref:`troubleshooting suggestions for a new cluster where data remains on a"
 " single shard <sharding-troubleshooting-not-splitting>`."
 msgstr ""
+"如果你刚刚部署了你的分片集群，你可能要考虑"
+" :ref:` 在新集群中数据保持在但以分片的故障处理建议"
+" <sharding-troubleshooting-not-splitting>` 。"
 
 #: ../source/faq/diagnostics.txt:306
 msgid ""
 "If the cluster was initially balanced, but later developed an uneven "
 "distribution of data, consider the following possible causes:"
 msgstr ""
+"如果集群最初是平衡的，但是随后的开发中数据分布不均，参考以下的可能原因："
 
 #: ../source/faq/diagnostics.txt:309
 msgid ""
 "You have deleted or removed a significant amount of data from the cluster. "
 "If you have added additional data, it may have a different distribution with"
 " regards to its shard key."
 msgstr ""
+"你可能从集群中删除或移除大量数据。如果你增加了额外的数据，它可能有对于片键会"
+"有不同的分布"
 
 #: ../source/faq/diagnostics.txt:313
 msgid ""
 "Your :term:`shard key` has low :ref:`cardinality <sharding-shard-key-"
 "cardinality>` and MongoDB cannot split the chunks any further."
 msgstr ""
+"你的 :term:`片键` 具有低的 :ref:`基数能力 <sharding-shard-key-"
+"cardinality>` ， MongoDB 不能再分隔数据块。"
 
 #: ../source/faq/diagnostics.txt:316
 msgid ""
 "Your data set is growing faster than the balancer can distribute data around"
 " the cluster. This is uncommon and typically is the result of:"
 msgstr ""
+"你的数据增长比均衡器在集群中分布数据的速度更快。这是罕见的，典型的结果是："
 
 #: ../source/faq/diagnostics.txt:320
 msgid ""
 "a :ref:`balancing window <sharding-schedule-balancing-window>` that is too "
 "short, given the rate of data growth."
 msgstr ""
+" :ref:`均衡窗口 <sharding-schedule-balancing-window>` 太短， "
+"给定数据增长比率。"
 
 #: ../source/faq/diagnostics.txt:323
 msgid ""
 "an uneven distribution of :ref:`write operations <sharding-shard-key-write-"
 "scaling>` that requires more data migration. You may have to choose a "
 "different shard key to resolve this issue."
 msgstr ""
+"一个不均衡的 :ref:`写操作 <sharding-shard-key-write-"
+"scaling>` 需要更多的数据迁移。你可能不得不选择一个不同的片键来解决这个问题。"
 
 #: ../source/faq/diagnostics.txt:328
 msgid ""
 "poor network connectivity between shards, which may lead to chunk migrations"
 " that take too long to complete. Investigate your network configuration and "
 "interconnections between shards."
 msgstr ""
+"分片之间较差的网络连接，可能会导致数据块迁移完成时间太长。检查你的网络配置和"
+"分片的相互连接。"
 
 #: ../source/faq/diagnostics.txt:333
 msgid "Why do chunk migrations affect sharded cluster performance?"
-msgstr ""
+msgstr "为什么数据块迁移会影响分片集群的性能？"
 
 #: ../source/faq/diagnostics.txt:335
 msgid ""
 "If migrations impact your cluster or application's performance, consider the"
 " following options, depending on the nature of the impact:"
 msgstr ""
+"如果迁移影响了你的集群或者应用的性能，根据产生影响的类型考虑下列选项："
 
 #: ../source/faq/diagnostics.txt:338
 msgid ""
@@ -498,25 +559,34 @@ msgid ""
 "balancing activity during peak hours. Ensure that there is enough time "
 "remaining to keep the data from becoming out of balance again."
 msgstr ""
+"如果迁移只是偶尔的打断你的集群，可以限制"
+":ref:`均衡窗口 <sharding-schedule-balancing-window>` 来阻止高峰时段的平衡"
+"活动。确保有足够的剩余时间来保持数据在再次失去平衡之前。"
 
 #: ../source/faq/diagnostics.txt:344
 msgid ""
 "If the balancer is always migrating chunks to the detriment of overall "
 "cluster performance:"
 msgstr ""
+"如果均衡器总是迁移数据影响到集群的整体性能："
 
 #: ../source/faq/diagnostics.txt:347
 msgid ""
 "You may want to attempt :doc:`decreasing the chunk size </tutorial/modify-"
 "chunk-size-in-sharded-cluster>` to limit the size of the migration."
 msgstr ""
+"你可能需要尝试"
+" :doc:`减小数据块的大小 </tutorial/modify-chunk-size-in-sharded-cluster>` "
+"来限制迁移的大小。"
 
 #: ../source/faq/diagnostics.txt:350
 msgid ""
 "Your cluster may be over capacity, and you may want to attempt to :ref:`add "
 "one or two shards <sharding-procedure-add-shard>` to the cluster to "
 "distribute load."
 msgstr ""
+"你的集群可能过载，你可能需要尝试"
+" :ref:`增加一到两个分片 <sharding-procedure-add-shard>` 到集群中来分担负荷。"
 
 #: ../source/faq/diagnostics.txt:354
 msgid ""
@@ -526,3 +596,6 @@ msgid ""
 "your cluster  with a shard key that provides better :ref:`write scaling "
 "<sharding-shard-key-write-scaling>`."
 msgstr ""
+"也可能是你的片键导致你的应用直接写入到一个单一分片。这种活动模式需要"
+"均衡器在写入不久之后去迁移更多的数据。可以考虑用一个片键重新部署你的"
+"集群以提供更好的 :ref:`写扩展 <sharding-shard-key-write-scaling>`。 "

locale/zh/LC_MESSAGES/reference/write-concern.po

@@ -173,11 +173,12 @@ msgid ""
 "If you disable basic write operation acknowledgment but require journal "
 "commit acknowledgment, the journal commit prevails, and the server will "
 "require that :program:`mongod` acknowledge the write operation."
-msgstr ""
+msgstr "如果你禁用了基本的写操作通知，但是需要日志提交通知， the journal commit prevails, and the server will "
+"require that :program:`mongod` acknowledge the write operation."
 
 #: ../source/reference/write-concern.txt:78
 msgid "<Number greater than 1>"
-msgstr ""
+msgstr "大于 1 的数字"
 
 #: ../source/reference/write-concern.txt:80
 msgid ""