Cross-link commands and methods for adding and removing shards

changelogs/generatechangelogs.py

@@ -52,7 +52,7 @@ def get_jira_issues(fixVersion):
     # Run the JIRA query
     query = "project in {0} and fixVersion = {1} and resolution = 'Fixed' ORDER BY key ASC".format(
         projects, fixVersion)
-    issues = auth_jira.search_issues(query, maxResults=200)
+    issues = auth_jira.search_issues(query, maxResults=500)
 
     logger.info("building changelog for {0} with {1} issue(s)".format(
         fixVersion, len(issues)))

conf.py

@@ -76,7 +76,7 @@ def has(self, *args):
 ])
 
 source_constants = {
-    'version-dev': '4.9',   # Current development branch
+    'version-dev': '4.3',   # Current development branch
     'package-name-org': 'mongodb-org',
     'package-name-enterprise': 'mongodb-enterprise',
     'version': version,

config/build_conf.yaml

@@ -10,8 +10,8 @@ project:
   branched: true
   siteroot: true
 version:
-  release: '5.0.0'
-  branch: '5.0'
+  release: '4.4.2'
+  branch: '4.4'
 system:
   files:
     - 'pdfs.yaml'

config/redirects

@@ -1,8 +1,8 @@
 define: base https://docs.mongodb.com
 define: versions v2.2 v2.4 v2.6 v3.0 v3.2 v3.4 v3.6 v4.0 v4.2 v4.4 master
+symlink: upcoming -> v4.4
 symlink: manual -> v4.4
-symlink: upcoming -> v4.4	
-symlink: master -> v4.4
+symlink: v4.4 -> master
 
 [v2.2]: /${version}/core/read-operations-introduction -> ${base}/${version}/core/read-operations
 [v2.2]: /${version}/core/write-operations-introduction -> ${base}/${version}/core/write-operations
@@ -1454,6 +1454,9 @@ raw: /master/release-notes/3.0-general-improvements -> ${base}/release-notes/3.0
 [*-v4.0]: /${version}/reference/operator/aggregation/asinh -> ${base}/${version}/reference/operator/aggregation
 [*-v4.0]: /${version}/reference/operator/aggregation/acosh -> ${base}/${version}/reference/operator/aggregation
 [*-v4.0]: /${version}/reference/operator/aggregation/atanh -> ${base}/${version}/reference/operator/aggregation
+[*-v4.0]: /${version}/reference/operator/aggregation/sinh -> ${base}/${version}/reference/operator/aggregation
+[*-v4.0]: /${version}/reference/operator/aggregation/cosh -> ${base}/${version}/reference/operator/aggregation
+[*-v4.0]: /${version}/reference/operator/aggregation/tanh -> ${base}/${version}/reference/operator/aggregation
 [*-v4.0]: /${version}/reference/operator/aggregation/degreesToRadians -> ${base}/${version}/reference/operator/aggregation
 [*-v4.0]: /${version}/reference/operator/aggregation/radiansToDegrees -> ${base}/${version}/reference/operator/aggregation
 
@@ -1664,6 +1667,9 @@ raw: /v2.8/release-notes/2.8-changes -> ${base}/v3.0/release-notes/3.0
 [v3.0-v4.0]: /${version}/reference/operator/aggregation/asinh -> ${base}/${version}/reference/operator/aggregation
 [v3.0-v4.0]: /${version}/reference/operator/aggregation/acosh -> ${base}/${version}/reference/operator/aggregation
 [v3.0-v4.0]: /${version}/reference/operator/aggregation/atanh -> ${base}/${version}/reference/operator/aggregation
+[v3.0-v4.0]: /${version}/reference/operator/aggregation/sinh -> ${base}/${version}/reference/operator/aggregation
+[v3.0-v4.0]: /${version}/reference/operator/aggregation/cosh -> ${base}/${version}/reference/operator/aggregation
+[v3.0-v4.0]: /${version}/reference/operator/aggregation/tanh -> ${base}/${version}/reference/operator/aggregation
 [v3.0-v4.0]: /${version}/reference/operator/aggregation/degreesToRadians -> ${base}/${version}/reference/operator/aggregation
 [v3.0-v4.0]: /${version}/reference/operator/aggregation/radiansToDegrees -> ${base}/${version}/reference/operator/aggregation
 

config/sphinx_local.yaml

@@ -89,7 +89,6 @@ theme:
     - /release-notes/4.0
     - /release-notes/4.2
     - /release-notes/4.4
-    - /release-notes/5.0
     - /security
     - /sharding
     - /changeStreams

snooty.toml

@@ -1,11 +1,11 @@
 name = "manual"
 
 [constants]
-package-branch = "5.0" # For rc = testing.  For GA, will be 4.2.
-windows-dir-version = "5.0" # The wizard installs in 4.2 branch
+package-branch = "4.4" # For rc = testing.  For GA, will be 4.2.
+windows-dir-version = "4.4" # The wizard installs in 4.2 branch
 package-name-org = "mongodb-org"
 package-name-enterprise = "mongodb-enterprise"
-version = "5.0"
+version = "4.4"
 release = "{+release+}"
 pgp-version = "{+version+}"
 pgp-fingerprint = "E162F504A20CDF15827F718D4B7C549A058F8B6B"

source/administration/production-notes.txt

@@ -97,7 +97,7 @@ Recommended Platforms
 ~~~~~~~~~~~~~~~~~~~~~
 
 While MongoDB supports a variety of platforms, the following operating
-systems are recommended for production use:
+systems are recommended for production use on ``x86_64`` architecture:
 
 - Amazon Linux 2
 - Debian 9 and 10

source/core/data-modeling-introduction.txt

@@ -22,7 +22,7 @@ Flexible Schema
 
 Unlike SQL databases, where you must determine and declare a table's
 schema before inserting data, MongoDB's :term:`collections
-<collection>`, by default, does not require its :doc:`documents
+<collection>`, by default, do not require their :doc:`documents
 </core/document>` to have the same schema. That is:
 
 - The documents in a single collection do not need to have the same set

source/core/index-compound.txt

@@ -39,10 +39,22 @@ operation that resembles the following prototype:
 
 .. include:: /includes/fact-index-specification-field-value.rst
 
-.. important:: You may not create compound indexes that have
-   ``hashed`` index type. You will receive an error if you attempt to
-   create a compound index that includes :doc:`a hashed index
-   field </core/index-hashed>`.
+.. important:: 
+
+   Starting in MongoDB 4.4: 
+
+   - Compound indexes may contain **a single** :doc:`hashed index field 
+     </core/index-hashed>`. 
+   - You will receive an error if you attempt to create a compound index 
+     that contains more than one :doc:`hashed index field 
+     </core/index-hashed>`.
+
+   In MongoDB 4.2 or earlier: 
+
+   - Compound indexes may **not** contain a :doc:`hashed index field 
+     </core/index-hashed>`. 
+   - You will receive an error if you attempt to create a compound index
+     that contains a :doc:`hashed index field </core/index-hashed>`.
 
 Consider a collection named ``products`` that holds documents that
 resemble the following document:

source/core/index-creation.txt

@@ -129,21 +129,25 @@ Index Build Impact on Database Performance
 ------------------------------------------
 
 Index Builds During Write-Heavy Workloads
-  Building indexes during time periods where the target collection
-  is under heavy write load can result in reduced write 
-  performance and longer index builds.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  Consider designating a maintenance window during which applications
-  stop or reduce write operations against the collection. Start the
-  index build during this maintenance window to mitigate the
-  potential negative impact of the build process.
+Building indexes during time periods where the target collection
+is under heavy write load can result in reduced write 
+performance and longer index builds.
+
+Consider designating a maintenance window during which applications
+stop or reduce write operations against the collection. Start the
+index build during this maintenance window to mitigate the
+potential negative impact of the build process.
 
 Insufficient Available System Memory (RAM)
-  .. include:: /includes/fact-index-build-default-memory-limit.rst
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. include:: /includes/fact-index-build-default-memory-limit.rst
 
-  If the host machine has limited available free RAM, you may need
-  to schedule a maintenance period to increase the total system RAM
-  before you can modify the :binary:`~bin.mongod` RAM usage.
+If the host machine has limited available free RAM, you may need
+to schedule a maintenance period to increase the total system RAM
+before you can modify the :binary:`~bin.mongod` RAM usage.
 
 .. _index-operations-replicated-build:
 .. _index-operations-simultaneous-build:
@@ -190,21 +194,6 @@ The build process is summarized as follows:
 For sharded clusters, the index build occurs only on shards
 containing data for the collection being indexed.
 
-.. warning::
-
-  Avoid dropping any index on a collection while an index is being 
-  replicated on the secondaries.
-
-  If you attempt to drop an index from a collection on a :term:`primary` 
-  node while the collection has a background index building on the 
-  :term:`secondary` nodes, the two indexing operations will conflict 
-  with each other. 
-
-  As a result, reads will be halted across all namespaces and
-  replication will halt until the background index build completes. 
-  When the build finishes the dropIndex action will execute, then 
-  reads and replication will resume. 
-
 For a more detailed description of the index build process, 
 see :ref:`index-build-process`.
 

source/core/index-intersection.txt

@@ -133,15 +133,18 @@ For example, the ``orders`` collection has the following indexes:
    { status: 1 }
    { ord_date: -1 }
 
-MongoDB cannot use index intersection for the following query with sort:
+MongoDB cannot use index intersection for the following query because
+the :method:`~cursor.sort()` requires an index separate from the query
+predicate:
 
 .. code-block:: javascript
 
    db.orders.find( { qty: { $gt: 10 } } ).sort( { status: 1 } )
 
-That is, MongoDB does not use the ``{ qty: 1 }`` index for the query,
-and the separate ``{ status: 1 }`` or the ``{ status: 1, ord_date: -1
-}`` index for the sort.
+That is, MongoDB cannot use either of these index intersections: 
+
+- ``{ qty: 1 }`` and ``{ status: 1 }``
+- ``{ qty: 1 }`` and ``{ status: 1, ord_date: -1 }``
 
 However, MongoDB can use index intersection for the following query
 with sort since the index ``{ status: 1, ord_date: -1 }`` can fulfill

source/core/index-multikey.txt

@@ -210,6 +210,20 @@ $expr
 
 :query:`$expr` does not support multikey indexes.
 
+Indexes Built on MongoDB 3.2 or Earlier
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Indexes built on MongoDB 3.2 or earlier do not contain the necessary
+flags to support optimized multikey index use. To benefit from the
+performance enhancements of multikey indexes, you must either:
+
+- Rebuild the older-format indexes on MongoDB 3.4 or later. See
+  :method:`db.collection.reIndex()`.
+
+- On a replica set, :doc:`resync the replica set members
+  </tutorial/resync-replica-set-member/>` containing older-format
+  indexes.
+
 Examples
 --------
 

source/core/replica-set-oplog.txt

@@ -257,3 +257,10 @@ the ``local.oplog.rs`` collection from a standalone MongoDB instance,
 and we recommend that you do not drop the collection from a standalone 
 MongoDB v4.0 instance. The :ref:`mongod` requires the oplog for both 
 :ref:`replication` and recovery of a node if the node goes down.
+
+Starting in MongoDB 4.4.2, it is no longer possible to perform manual
+write operations to the :doc:`oplog </core/replica-set-oplog>` on a
+cluster running as a :ref:`replica set <replication>`. Performing write
+operations to the oplog when running as a
+:term:`standalone instance <standalone>` should only be done with
+guidance from MongoDB Support.

source/core/security-explicit-client-side-encryption.txt

@@ -93,12 +93,12 @@ implementing explicit client-side field level encryption.
 
 The MongoDB 4.2 :binary:`~bin.mongo` shell adds an additional option
 to the :method:`Mongo()` method for instantiating a database
-connection with automatic client-side field level encryption. 
+connection with explicit client-side field level encryption. 
 For a complete example, see 
 :ref:`mongo-connection-client-side-encryption-enabled`.
 
 Applications must specify the following components when instantiating
-the database connection to enable automatic client-side field level
+the database connection to enable explicit client-side field level
 encryption:
 
 - A :ref:`key vault <field-level-encryption-keyvault>` of data

source/core/sharding-shard-key.txt

@@ -213,7 +213,7 @@ the cluster. See also :ref:`sharding strategy <sharding-strategy>`.
 
 At minimum, consider the consequences of the
 :ref:`cardinality<shard-key-range>`, :ref:`frequency<shard-key-frequency>`, and
-rate of :ref:`change<shard-key-monotonic>` of a potential shard key.
+:ref:`monotonicity<shard-key-monotonic>` of a potential shard key.
 
 .. note::
 
@@ -269,11 +269,12 @@ inserts may look similar to the following:
 The cluster in this example would *not* scale horizontally, as incoming writes
 would only route to a subset of shards.
 
-A shard key with high cardinality does not guarantee even distribution of data
-across the sharded cluster, though it does better facilitate horizontal
-scaling. The :ref:`frequency <shard-key-frequency>` and :ref:`rate of
-change <shard-key-monotonic>` of the shard key also contributes to data
-distribution. Consider each factor when choosing a shard key.
+Choosing a shard key with high cardinality does not, on its own, 
+guarantee even distribution of data across the sharded cluster. The 
+:ref:`frequency <shard-key-frequency>` and 
+:ref:`monotonicity <shard-key-monotonic>` of the shard key also 
+contribute to data distribution. Take each factor into account when 
+choosing a shard key.
 
 If your data model requires sharding on a key that has low cardinality,
 consider using a :term:`compound index` using a field that
@@ -298,19 +299,21 @@ distribution of inserts may look similar to the following:
 
 .. include:: /images/sharded-cluster-ranged-distribution-frequency.rst
 
-A shard key with low frequency does not guarantee even distribution of data
-across the sharded cluster. The :ref:`cardinality <shard-key-cardinality>` and
-:ref:`rate of change <shard-key-monotonic>` of the shard key also contributes
-to data distribution. Consider each factor when choosing a shard key.
+Choosing a shard key with low frequency does not, on its own, guarantee 
+even distribution of data across the sharded cluster. 
+The :ref:`cardinality <shard-key-cardinality>` and 
+:ref:`monotonicity <shard-key-monotonic>` of the shard key also 
+contribute to data distribution. Take each factor into account when 
+choosing a shard key.
 
 If your data model requires sharding on a key that has high frequency
 values, consider using a :term:`compound index` using a unique or
 low frequency value.
 
 .. _shard-key-monotonic:
 
-Monotonically Changing Shard Keys
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Shard Key Monotonicity
+~~~~~~~~~~~~~~~~~~~~~~
 
 A shard key on a value that increases or decreases monotonically is more
 likely to distribute inserts to a single shard within the cluster.
@@ -336,11 +339,12 @@ distribution of inserts may look similar to the following:
 If the shard key value was monotonically decreasing, then all inserts would
 route to ``Chunk A`` instead.
 
-A shard key that does not change monotonically does not guarantee even
-distribution of data across the sharded cluster. The
-:ref:`cardinality<shard-key-cardinality>` and
-:ref:`frequency<shard-key-frequency>` of the shard key also contributes to
-data distribution. Consider each factor when choosing a shard key.
+Choosing a shard key that does not change monotonically does not, on 
+its own, guarantee even distribution of data across the sharded cluster. 
+The :ref:`cardinality<shard-key-cardinality>` and
+:ref:`frequency<shard-key-frequency>` of the shard key also contribute
+to data distribution. Take each factor into account when choosing a 
+shard key.
 
 If your data model requires sharding on a key that changes
 monotonically, consider using :doc:`/core/hashed-sharding`.

source/includes/4.4-downgrade-clean-shutdown.rst

@@ -0,0 +1,8 @@
+Run the following command from the :binary:`~bin.mongo` shell to 
+perform a clean shutdown, or refer to 
+:ref:`terminate-mongod-processes` for additional ways to safely  
+terminate the :binary:`~bin.mongod` process:
+
+.. code-block:: javascript
+
+   db.adminCommand( { shutdown: 1 } )

source/includes/changelogs/releases/3.6.21.rst

@@ -6,7 +6,8 @@
 Sharding
 ~~~~~~~~
 
-:issue:`SERVER-51808` invariant failure: readConcern level != Available
+- :issue:`SERVER-51808` invariant failure: readConcern level != Available
+- :issue:`SERVER-51885` Blacklist balancing_sessions_collection.js from sharding_csrs_continuous_config_stepdown
 
 Replication
 ~~~~~~~~~~~
@@ -21,9 +22,8 @@ Replication
 Query
 ~~~~~
 
-- :issue:`SERVER-50291` Add query knob to enumerate $or children in a different order
 - :issue:`SERVER-51083` Problem with regex index bounds
-- :issue:`SERVER-51120` Find queries with MERGE_SORT incorrectly sort the results when the collation is specified 
+- :issue:`SERVER-51120` Find queries with SORT_MERGE incorrectly sort the results when the collation is specified 
 
 Storage
 ~~~~~~~
@@ -43,11 +43,13 @@ Build and Packaging
 Internals
 ~~~~~~~~~
 
-- :issue:`SERVER-41872` PlanEnumerator AndAssignment::choices ordering not stable and is relevant to set of plans generated
+- :issue:`SERVER-45624` Pre-split and distribute chunks of sessions collection
+- :issue:`SERVER-50123` Record number of physical cores on all platforms
 - :issue:`SERVER-50216` Adjust sys-perf frequencies
 - :issue:`SERVER-50605` Add {logMessage: "msg"} test-only command
 - :issue:`SERVER-50736` Make OpenSSL explicitly accept SNIs presented in ClientHello
 - :issue:`SERVER-50818` Coverity analysis defect 114987: Wrapper object use after free
 - :issue:`SERVER-51106` Make the isMaster command a derived class of hello
+- :issue:`SERVER-51303` Lookup stage followed by $match on type uses wrong field in matching condition 
 - :issue:`TOOLS-2590` [v3.6] sslAllowInvalidHostnames bypass ssl/tls server certification validation entirely
 

source/includes/changelogs/releases/4.0.21.rst

@@ -42,7 +42,8 @@ Query
 - :issue:`SERVER-39392` Invariant in PlanStage::dispose always evaluates as true
 - :issue:`SERVER-45233` Indexed inequalities to arrays return incorrect results
 - :issue:`SERVER-50291` Add query knob to enumerate $or children in a different order
-- :issue:`SERVER-51120` Find queries with MERGE_SORT incorrectly sort the results when the collation is specified 
+- :issue:`SERVER-51083` Problem with regex index bounds
+- :issue:`SERVER-51120` Find queries with SORT_MERGE incorrectly sort the results when the collation is specified 
 
 Aggregation
 ~~~~~~~~~~~
@@ -86,6 +87,8 @@ Internals
 - :issue:`SERVER-50736` Make OpenSSL explicitly accept SNIs presented in ClientHello
 - :issue:`SERVER-50818` Coverity analysis defect 114987: Wrapper object use after free
 - :issue:`SERVER-51106` Make the isMaster command a derived class of hello
+- :issue:`SERVER-51608` [4.0] backport implicitly_retry_on_background_op_in_progress.js
+- :issue:`SERVER-51802` Add requires_majority_read_concern tag to decrypt_tool.js on v4.0
 - :issue:`TOOLS-2589` [v4.0] sslAllowInvalidHostnames bypass ssl/tls server certification validation entirely
 - :issue:`WT-6421` Avoid parsing metadata checkpoint for clean files
 - :issue:`WT-6559` Use the session id from the new session to determine statistics bucket