forked from mongodb/docs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path4.4.txt
2372 lines (1669 loc) · 79.1 KB
/
4.4.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
=============================
Release Notes for MongoDB 4.4
=============================
.. default-domain:: mongodb
.. contents:: On this page
:local:
:backlinks: none
:depth: 1
:class: twocols
Minor Releases
--------------
.. _4.4.9-release-notes:
4.4.9 - Upcoming
~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-57630`: Enable SSL_OP_NO_RENEGOTIATION on Ubuntu 18.04
when running against OpenSSL 1.1.1
- :issue:`SERVER-34938`: Secondary slowdown or hang due to content
pinned in cache by single oplog batch
- :issue:`WT-8005`: Fix a prepare commit bug that could leave the
history store entry unresolved
- :issue:`WT-7995`: Fix the global visibility that it cannot go beyond
checkpoint visibility
- :issue:`WT-7984`: Fix a bug that could cause a checkpoint to omit a
page of data
- `All JIRA issues closed in 4.4.9
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.9%27>`_
- :ref:`4.4.9-changelog`
.. _4.4.8-release-notes:
4.4.8 - Aug 4, 2021
~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-58936`: Unique index constraints may not be enforced
- :issue:`SERVER-58258`: Wait for initial sync to clear state before
asserting 'replSetGetStatus' reply has no 'initialSync' field
- :issue:`SERVER-52906`: moveChunk after failed migration that rolled
back cloning indexes can hang indefinitely due to missing shard key
index
- :issue:`WT-7837`: Clear updates structure in wt_hs_insert_updates to
avoid firing assert
- :issue:`WT-6729`: Quiesce eviction prior running rollback to stable's
active transaction check
- `All JIRA issues closed in 4.4.8
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.8%27>`_
- :ref:`4.4.8-changelog`
.. _4.4.7-release-notes:
4.4.7 - Jul 16, 2021
~~~~~~~~~~~~~~~~~~~~
.. warning::
MongoDB version 4.4.7 is not recommended for production use due to a
critical issue, :issue:`SERVER-58936`, fixed in later versions.
Use the latest available patch release version.
Issues fixed:
- :issue:`SERVER-57476`: Operation may block on prepare conflict while
holding oplog slot, stalling replication indefinitely
- :issue:`SERVER-56054`: Change minThreads value for replication writer
thread pool to 0
- :issue:`SERVER-53760`: $unwind + $sort pipeline produces large number
of file handles when spilling to disk
- :issue:`SERVER-47699`: Change yield type used by range deleter from
YIELD_MANUAL to YIELD_AUTO
- :issue:`WT-7185`: Avoid aborting a transaction if it is force evicting
and oldest
- `All JIRA issues closed in 4.4.7
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.7%27>`_
- :ref:`4.4.7-changelog`
.. _4.4.6-release-notes:
4.4.6 - May 10, 2021
~~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-53604`: Include original aws iam arn in authenticate
audit logs
- :issue:`SERVER-52564`: Deadlock between step down and
MongoDOperationContextSession
- :issue:`WT-7442`: RTS to open dhandle only when the dhandle has
unstable updates
- :issue:`WT-7426`: Set write generation number when the page image gets
created
- :issue:`WT-7373`: Improve slow random cursor operations on oplog
- `All JIRA issues closed in 4.4.6
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.6%27>`_
- :ref:`4.4.6-changelog`
.. _4.4.5-release-notes:
4.4.5 - Apr 8, 2021
~~~~~~~~~~~~~~~~~~~
.. warning::
MongoDB version 4.4.5 is not recommended for production use due to a
critical issue, :issue:`WT-7426`, fixed in later versions.
Use the latest available patch release version.
Issues fixed:
- :issue:`SERVER-55298`: Reproduce and Investigate BSONObjectTooLarge
error
- :issue:`SERVER-53566`: Investigate and reproduce "opCtx != nullptr
&& _opCtx == nullptr" invariant
- :issue:`SERVER-51281`: mongod live locked
- :issue:`SERVER-46686`: Explain does not respect maxTimeMS
- :issue:`SERVER-45836`: Provide more LDAP details (like server IP) at
default log level
- `All JIRA issues closed in 4.4.5
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.5%27>`_
- :ref:`4.4.5-changelog`
.. _4.4.4-release-notes:
4.4.4 - Feb 16, 2021
~~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-48471`: Hashed indexes may be incorrectly marked
multikey and be ineligible as a shard key
- :issue:`SERVER-50769`: server restarted after
expr{"expr":"_currentApplyOps.getArrayLength() > 0","file":"src/mongo/db/pipeline/document_source_change_stream_transform.cpp","line":535}}
- :issue:`SERVER-52919`: Wire compression not enabled for initial sync
- :issue:`WT-7109`: Retain no longer supported configuration options for
backward compatibility
- :issue:`WT-7117`: RTS to skip modifies that are more recent than
on-disk base update while restoring an update
- `All JIRA issues closed in 4.4.4
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.4%27>`_
- :ref:`4.4.4-changelog`
.. _4.4.3-release-notes:
4.4.3 - Jan 4, 2021
~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-33966`: redundant $sort in aggregation prevents best
$limit $sort consolidation
- :issue:`SERVER-40361`: Reduce memory footprint of plan cache entries
- :issue:`SERVER-52654`: new signing keys not generated by the
monitoring-keys-for-HMAC thread
- :issue:`SERVER-52824`: Support AWS roles with paths
- :issue:`SERVER-52929`: Correctly handle compound indexes with 32 keys
- `All JIRA issues closed in 4.4.3
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.3%27>`_
- :ref:`4.4.3-changelog`
.. _4.4.2-release-notes:
4.4.2 - Nov 18, 2020
~~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-48067`: Reduce memory consumption for unique index
builds with large numbers of non-unique keys
- :issue:`SERVER-48523`: Unconditionally check the first entry in the
oplog when attempting to resume a change stream
- :issue:`SERVER-50365`: Stuck with long-running transactions that can't
be timed out
- :issue:`SERVER-50394`: mongod audit log attributes DDL operations to
the __system user in a sharded environment
- :issue:`SERVER-51041`: Throttle starting transactions for secondary
reads
- :issue:`SERVER-51120`: Find queries with MERGE_SORT incorrectly sort
the results when the collation is specified
- `All JIRA issues closed in 4.4.2
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.2%27>`_
- :ref:`4.4.2-changelog`
.. _4.4.1-release-notes:
4.4.1 - Sep 9, 2020
~~~~~~~~~~~~~~~~~~~
Issues fixed:
- :issue:`SERVER-48531`: 3 way deadlock can happen between chunk
splitter, prepared transactions and stepdown thread.
- :issue:`SERVER-48641`: Deadlock due to the MigrationDestinationManager
waiting for write concern with the session checked-out
- :issue:`SERVER-49546`: setFCV to 4.4 should insert range deletion
tasks in batches rather than one at a time
- :issue:`SERVER-49694`: On a sharded cluster, nearest or hedged reads
may not be routed to a near shard replica.
- :issue:`SERVER-50137`: MongoDB crashes with Invariant failure due to
oplog entries generated in 3.4
- :issue:`SERVER-50140`: Initial sync cannot survive unclean restart of
the sync source
- :issue:`SERVER-50170`: Fix server selection failure on mongos
- :issue:`WT-6623`: Set the connection level file id in recovery file
scan
- `All JIRA issues closed in 4.4.1
<https://jira.mongodb.org/issues/?jql=project%20in%20(SERVER%2CTOOLS%2CWT)%20AND%20resolution%3D%27Fixed%27%20and%20fixversion%3D%274.4.1%27>`_
- :ref:`4.4.1-changelog`
.. _4.4-rel-notes-agg:
Aggregation
-----------
Union All (``$unionWith`` Stage)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MongoDB 4.4 adds the :pipeline:`$unionWith` aggregation stage,
providing the ability to combines pipeline results from multiple
collections into a single result set.
For details, see :pipeline:`$unionWith`.
Custom Aggregation Expressions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting in version 4.4, MongoDB provides the following new operators
that allow users to define custom aggregation expressions:
- :group:`$accumulator`
- :expression:`$function`
With the addition of these new operators, you can use aggregation to
write custom JavaScript expressions instead of relying on
:dbcommand:`mapReduce` and :query:`$where`.
.. note::
Even before version 4.4, various map-reduce expressions could also
be rewritten using :doc:`other aggregation pipeline operators
</meta/aggregation-quick-reference>`, such as :pipeline:`$group`,
:pipeline:`$merge`, etc., without requiring custom functions.
For more information, see
:doc:`/reference/map-reduce-to-aggregation-pipeline`.
.. _4.4-rel-notes-new-agg-operators:
New Aggregation Operators
~~~~~~~~~~~~~~~~~~~~~~~~~
.. list-table::
:header-rows: 1
:widths: 20 80
* - Operator
- Description
* - :group:`$accumulator`
- Returns the result of a user-defined
:ref:`accumulator operator <agg-operators-group-accumulators>`.
* - :expression:`$binarySize`
- Returns the size of a given string or binary data value's
content in bytes.
* - :expression:`$bsonSize`
- Returns the size in bytes of a given document (i.e. bsontype
``Object``) when encoded as :term:`BSON`.
* - :expression:`$first`
- Returns the first element in an array.
* - :expression:`$function`
- Defines a custom aggregation expression.
* - :expression:`$last`
- Returns the last element in an array.
* - :expression:`$isNumber`
- Returns boolean ``true`` if the specified expression resolves
to an :bsontype:`integer <Int32>`, :bsontype:`decimal
<Decimal128>`, :bsontype:`double <Double>`, or :bsontype:`long
<Int64>`.
Returns boolean ``false`` if the expression resolves to any other
:doc:`BSON type </reference/mongodb-extended-json>`, ``null``, or
a missing field
* - :expression:`$replaceOne`
- Replaces the first instance of a matched string in a given input.
* - :expression:`$replaceAll`
- Replaces all instances of a matched string in a given input.
General Aggregation Improvements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``$out``
````````
Starting in MongoDB 4.4, :pipeline:`$out` can output to a collection in
a different database. In earlier versions, :pipeline:`$out` can output
to a collection to the same database where the aggregation is run.
``$indexStats``
```````````````
Starting in MongoDB 4.4 (also available starting in 4.2.4),
:pipeline:`$indexStats` includes the following fields in its output:
.. list-table::
:header-rows: 1
:widths: 35 65
* - Field
- Description
* - :ref:`shard <indexStats-output-shard>`
- Name of the shard, if applicable.
* - :ref:`spec <indexStats-output-spec>`
- Index specification document
* - :ref:`building <indexStats-output-building>`
- A boolean flag that indicates if the index is currently being built.
``$merge``
``````````
.. include:: /includes/fact-merge-same-collection-behavior.rst
.. include:: /includes/fact-merge-same-collection-warning.rst
.. _4.4-agg-planCachesStats-changes:
``$planCacheStats`` Changes
```````````````````````````
.. include:: /includes/extracts/4.4-changes-planCache-changes.rst
``$collStats`` Changes
``````````````````````
Starting in MongoDB 4.4, :pipeline:`$collStats` accepts the
``queryExecStats`` field as an argument document. Providing this field
returns the following fields in the output:
.. include:: /includes/fact-queryexecstats-reference.rst
``explain`` Changes
```````````````````
Starting in MongoDB 4.4, when you run the
:method:`db.collection.explain().aggregate() <db.collection.explain()>`
method in ``executionStats`` and ``allPlansExecution`` modes, each
:doc:`pipeline stage </aggregation>` listed in the :doc:`explain output
</reference/explain-results>` includes :data:`nReturned
<explain.executionStats.nReturned>` and
:data:`executionTimeMillisEstimate
<explain.executionStats.executionStages.executionTimeMillisEstimate>`.
Replica Sets
------------
Resumable Initial Sync
~~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, a secondary performing initial sync can attempt
to resume the sync process if interrupted by a *transient* (i.e.
temporary) network error, collection drop, or collection rename. The
sync source must also run MongoDB 4.4 to support resumable initial sync.
If the sync source runs MongoDB 4.2 or earlier, the secondary must
restart the initial sync process as if it encountered a non-transient
network error.
By default, the secondary tries to resume initial sync for 24 hours.
MongoDB 4.4 adds the
:parameter:`initialSyncTransientErrorRetryPeriodSeconds` server
parameter for controlling the amount of time the secondary attempts to
resume initial sync. If the secondary cannot successfully resume the
initial sync process during the configured time period, it selects a new
healthy source from the replica set and restarts the initial
synchronization process from the beginning.
Prior to MongoDB 4.4, the secondary would restart the entire initial
sync if it encountered an error during the process.
Streaming Replication
~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, *sync from* sources send a continuous
stream of :doc:`oplog </core/replica-set-oplog>` entries to their
syncing secondaries.
Prior to MongoDB 4.4, secondaries fetched batches of :doc:`oplog
</core/replica-set-oplog>` entries by issuing a request to their *sync
from* source and waiting for a response. This required a network roundtrip
for each batch of :doc:`oplog </core/replica-set-oplog>` entries. MongoDB
4.4 adds the :parameter:`oplogFetcherUsesExhaust` startup parameter for
disabling streaming replication and using the older replication behavior.
For details, see :ref:`replica-set-streaming-replication`.
Rollback Directory
~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/4.4-changes-rollback-directory.rst
Minimum Oplog Retention Period
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/4.4-changes-minimum-oplog-retention-period.rst
To configure the minimum oplog retention period when starting the
:binary:`~bin.mongod`, either:
- Add the :setting:`storage.oplogMinRetentionHours` setting to the
:binary:`~bin.mongod` :ref:`configuration
file <configuration-options>`.
*-or-*
- Add the :option:`--oplogMinRetentionHours
<mongod --oplogMinRetentionHours>` command line option.
To configure the minimum oplog retention period on a running
:binary:`~bin.mongod`, use :dbcommand:`replSetResizeOplog`. Setting
the minimum oplog retention period while the :binary:`~bin.mongod`
is running overrides any values set on startup. You must update
the value of the corresponding configuration file setting or
command line option to persist those changes through a server
restart.
.. important::
The oplog can grow without constraint so as to retain oplog entries
for the configured number of hours. This may result in reduction or
exhaustion of system disk space due to a combination of high write
volume and large retention period.
.. seealso::
:doc:`/core/replica-set-oplog`
Indexes Build Simultaneously on Data-Bearing Replica Set Members
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. include:: /includes/extracts/4.4-changes-index-builds-simultaneous-fcv.rst
.. include:: /includes/extracts/4.4-changes-index-builds-simultaneous-nolink.rst
By default, index builds use a commit quorum of all data-bearing voting
members. To start an index build with a non-default commit quorum,
MongoDB 4.4 adds the :ref:`commitQuorum
<createIndexes-cmd-commitQuorum>` parameter to
:dbcommand:`createIndexes` or its shell helpers
:method:`db.collection.createIndex()` and
:method:`db.collection.createIndexes()`.
To modify the quorum required for an in-progress index
build, MongoDB 4.4 introduces the new :dbcommand:`setIndexCommitQuorum`
command.
See :ref:`index-operations-replicated-build` for more information.
Replica Set Reconfiguration Changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Changes to ``replSetReconfig``
``````````````````````````````
.. include:: /includes/extracts/4.4-replSetReconfig-majority.rst
.. include:: /includes/extracts/4.4-replSetReconfig-single-node-voting-change.rst
Changes to ``replSetGetConfig``
```````````````````````````````
.. include:: /includes/extracts/4.4-replSetGetConfiguration-commitmentStatus.rst
.. |moreinfo| replace:: For more information, see the
:ref:`replSetGetConfig <replSetGetConfig-commitmentStatus>` command.
Changes to Replica Configuration Document
`````````````````````````````````````````
.. include:: /includes/extracts/4.4-replSetGetConfig-term-field.rst
Preferred Initial Sync Source
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, you can specify the preferred initial sync
source using the :parameter:`initialSyncSourceReadPreference` parameter.
You can only set this parameter on :binary:`~bin.mongod` startup, using
either the :setting:`setParameter` configuration file setting or the
:option:`--setParameter <mongod --setParameter>` command line option.
:parameter:`initialSyncSourceReadPreference` supports following read
preference modes:
- :readmode:`primary`
- :readmode:`primaryPreferred` (Default for voting replica set members)
- :readmode:`secondary`
- :readmode:`secondaryPreferred`
- :readmode:`nearest` (Default for newly added *or* non-voting replica set members)
If the replica set has disabled :rsconf:`chaining
<settings.chainingAllowed>`, the default
:parameter:`initialSyncSourceReadPreference` read preference mode
is :readmode:`primary`.
You cannot specify a tag set or ``maxStalenessSeconds`` to
:parameter:`initialSyncSourceReadPreference`.
.. seealso::
:ref:`replica-set-initial-sync-source-selection`
.. _4.4-mirrored-reads:
Mirrored Reads
~~~~~~~~~~~~~~
Starting in version 4.4, MongoDB provides :ref:`mirrored reads
<mirrored-reads>` to pre-warm electable secondary members' cache with
the most recently accessed data. With mirrored reads, the primary can
mirror a subset of :ref:`operations
<mirrored-reads-supported-operations>` that it receives and send them
to a subset of electable secondaries. Pre-warming the cache of a
secondary can help restore performance more quickly after an election.
.. note::
The primary's response to the client is not affected by the
mirror reads. The mirrored reads are "fire-and-forget" operations
by the primary; i.e., the primary does not await the response for
the mirrored reads.
Mirrored Reads Parameter
````````````````````````
MongoDB 4.4 adds the following mirrored reads parameter. You can set
the parameter at startup using the :setting:`setParameter`
configuration file setting or the :option:`--setParameter <mongod
--setParameter>` command line option or at runtime with
:dbcommand:`setParameter` command:
.. list-table::
:widths: 20 80
:header-rows: 1
* - Parameter
- Description
* - :parameter:`mirrorReads`
- Specifies the ``samplingRate`` and ``maxTimeMS`` settings for
mirrored reads.
``{ samplingRate: <float>, maxTimeMS: <int> }``
A ``samplingRate`` of ``0`` turns off mirrored reads.
Mirrored Reads Metrics
``````````````````````
The command :dbcommand:`serverStatus` and its corresponding
:binary:`~bin.mongo` shell method :method:`db.serverStatus()` return
:serverstatus:`mirroredReads` if you specify the field's inclusion
in the operation:
.. code-block:: javascript
db.runCommand( { serverStatus: 1, mirroredReads: 1 } )
or
.. code-block:: javascript
db.serverStatus( { mirroredReads: 1 } )
Replica Set Write Acknowledgement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, replica set members in the
:replstate:`STARTUP2` state do not participate in write majorities.
.. seealso::
:doc:`/core/replica-set-write-concern`
Sharded Clusters
----------------
Refinable Shard Keys
~~~~~~~~~~~~~~~~~~~~
Starting in 4.4, MongoDB provides the
:dbcommand:`refineCollectionShardKey` command. With the new command,
you can refine a collection's shard key by adding a suffix field or
fields to the existing key. Refining a collection's shard key allows
for a more fine-grained data distribution and can address situations
where the existing key has led to :ref:`jumbo (i.e. indivisible)
chunks <jumbo-chunks>` due to insufficient cardinality.
For example, you may have an existing ``orders`` collection with the
shard key ``{ customer_id: 1 }``. You can change the shard key by
adding a suffix ``order_id`` field to the shard key so that ``{
customer_id: 1, order_id: 1 }`` becomes the new shard key, allowing
data distribution by both ``customer_id`` and ``order_id`` fields.
To use the :dbcommand:`refineCollectionShardKey` command, the sharded
cluster must have :ref:`feature compatibility version (fcv) <view-fcv>`
of ``4.4``. For more information, see the
:dbcommand:`refineCollectionShardKey` command.
.. note::
After you refine the shard key, it may be that not all documents in
the collection have the suffix field(s). To populate the missing
shard key field(s), see :ref:`shard-key-missing`.
Before refining the shard key, ensure that all or most documents in
the collection have the suffix fields, if possible, to avoid having
to populate the field afterwards.
In earlier versions, once you select a shard key, you cannot modify the
shard key.
.. important:: Missing Shard Keys
With the ability to refine a shard key with a suffix, it may be that
not all documents in the collection have the suffix fields. Starting in
version 4.4, documents in a sharded collection can be missing the shard
key fields. In earlier versions, shard key fields must exist in every
document for a sharded collection. For details, see
:ref:`shard-key-missing`.
Hedged Reads
~~~~~~~~~~~~
To minimize latencies, :binary:`~bin.mongos` instances, by default, can
use :ref:`hedge reads <mongos-hedged-reads>`. With hedged reads, the
:binary:`~bin.mongos` instances can route read operations to multiple
members per each queried shard and return results from the first
respondent per shard. By default, :binary:`~bin.mongos` instances
support using hedged reads. To turn off a :binary:`~bin.mongos`
instance's support for hedged reads, set the
:parameter:`readHedgingMode` parameter for the :binary:`~bin.mongos`.
Hedged reads are specified per operation as part of the read
preference. Non-``primary`` :doc:`read preferences
</core/read-preference>` support hedged reads. Read preference
:readmode:`nearest` specifies hedged read by default.
For more information, see:
- :ref:`mongos-hedged-reads`
- :ref:`replica-set-read-preference-behavior-mongos`
Hedged Read Parameters
``````````````````````
.. list-table::
:widths: 40 60
:header-rows: 1
* - Parameter
- Description
* - :parameter:`readHedgingMode`
- Enables or disables :binary:`~bin.mongos` instance's support for
hedged reads.
* - :parameter:`maxTimeMSForHedgedReads`
- Specifies the maximimum time limit (in milliseconds) for the
additional read sent to :ref:`hedge a read operation
<mongos-hedged-reads>`.
Hedged Read Option for Read Preference
``````````````````````````````````````
To specify hedged read for a read preference, MongoDB 4.4 introduces
the :ref:`read-preference-hedged-read`. To set using a MongoDB
driver, refer to the driver :driver:`read preference API
documentation</>`.
The following :binary:`~bin.mongo` shell methods can accept hedge
options to enable hedged read for the specified read preference:
- :method:`cursor.readPref()`
- :method:`Mongo.setReadPref()`
Hedged Read Metrics
```````````````````
The command :dbcommand:`serverStatus` and its corresponding
:binary:`~bin.mongo` shell method :method:`db.serverStatus()` return
:serverstatus:`hedgingMetrics`.
``balancerCollectionStatus`` Command
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MongoDB 4.4 provides the command :dbcommand:`balancerCollectionStatus`
and the :binary:`~bin.mongo` shell helper method
:method:`sh.balancerCollectionStatus()` that return information about
whether the chunks of a sharded collection are balanced (i.e. do not
need to be moved) as of the time the command is run or need to be
moved. With the command, users can verify that initial chunk creation
and migration has finished.
Improved ``mongos`` Startup Procedure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting with MongoDB 4.4, :binary:`~bin.mongos` adds the following new
default startup behavior:
- :binary:`~bin.mongos` will now preload a sharded cluster's routing
table on startup, rather than doing so on-demand for the first
incoming client connection.
- :binary:`~bin.mongos` will now prewarm its connection pool to shard
hosts on startup, rather than doing so on-demand for incoming
client connections.
This behavior results in faster servicing of initial client
connections after a :binary:`~bin.mongos` instance is started or
restarted. In particular, this allows sites that employ multiple
:binary:`~bin.mongos` instances to restart them as necessary, or add new
ones, without initial client requests to those instances needing to wait
on connection establishment.
Both routing table preloading and connection pool prewarming are enabled
by default.
MongoDB 4.4 adds the following parameters for controlling this behavior:
- :parameter:`loadRoutingTableOnStartup`
- *Default*: ``true`` (Enabled)
- Enables or disables support for preloading the routing table on
startup for the :binary:`~bin.mongos`.
- :parameter:`warmMinConnectionsInShardingTaskExecutorPoolOnStartup`
- *Default*: ``true`` (Enabled)
- Enables or disables support for prewarming the connection pool on
startup for the :binary:`~bin.mongos`.
- :parameter:`warmMinConnectionsInShardingTaskExecutorPoolOnStartupWaitMS`
- *Default*: ``2000`` (2 seconds)
- Sets the timeout in milliseconds before client connections
to the :binary:`~bin.mongos` are allowed regardless of established
connection pool size.
Improved Routing Table Updates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Running :dbcommand:`flushRouterConfig` is no longer required after
executing the :dbcommand:`movePrimary` or :dbcommand:`dropDatabase`
commands. These two commands now automatically refresh a sharded
cluster's routing table as needed when run. Manually issuing the
:dbcommand:`flushRouterConfig` command is still recommended in the cases
described under
:ref:`flushRouterConfig Considerations<flushrouterconfig-considerations>`.
.. _4.4-rel-notes-sharding-compound-hashed:
Compound Hashed Shard Keys
~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, you can shard a collection using a compound
shard key with a single hashed field. Prior to 4.4, MongoDB did not
support compound shard keys with a hashed field.
Compound hashed sharding supports features like :ref:`zone sharding
<zone-sharding>`, where the prefix (i.e. first) non-hashed field or
fields support zone ranges while the hashed field supports more even
distribution of the sharded data. For example, the following operation
shards a collection on a compound hashed shard key that supports zoned
sharding:
.. code-block:: javascript
sh.shardCollection(
"examples.compoundHashedCollection",
{ "fieldA" : 1, "fieldB" : 1, "fieldC" : "hashed" }
)
Compound hashed sharding also supports shard keys with a hashed prefix
for resolving data distribution issues related to :ref:`monotonically
increasing fields <shard-key-monotonic>` For example, the
following operation shards a collection on a compound hashed shard key
where the hashed field is the shard key prefix:
.. code-block:: javascript
sh.shardCollection(
"examples.compoundHashedCollection",
{ "_id" : "hashed", "fieldA" : 1}
)
.. seealso::
- :ref:`sharding-hashed-sharding`
- :ref:`4.4-rel-notes-compound-hashed-index`
Chunk Migration Failover Resiliency Improvements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Starting in MongoDB 4.4, the following changes improve :term:`chunk`
migrations and :term:`orphaned document` cleanup resiliency during
failover:
- Chunk ranges awaiting cleanup after a chunk migration are now
persisted in the :data:`config.rangeDeletions` collection and
replicated throughout the shard. In the event of a failover, the
shard's new primary reads the documents in the
:data:`config.rangeDeletions` collection and resumes deleting the
corresponding ranges. The document that describes a range awaiting
cleanup is deleted from the :data:`config.rangeDeletions` collection
after the range is deleted.
- The :dbcommand:`cleanupOrphaned` command no longer deletes orphaned
documents from a shard. Instead, :dbcommand:`cleanupOrphaned` waits
for orphaned documents that are scheduled for deletion from a shard to
be deleted.
Set the :parameter:`disableResumableRangeDeleter` parameter to ``true``
on a shard's primary to pause range deletion on the shard.
General Sharded Clusters Improvements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Index Consistency Checks
````````````````````````
Starting in MongoDB 4.4, the :doc:`config server
</core/sharded-cluster-config-servers>` primary, by default, checks for
index inconsistencies across the shards for sharded collections. The
command :dbcommand:`serverStatus` returns the field
:serverstatus:`shardedIndexConsistency` to report on index
inconsistencies when run on the config server primary.
To configure the index consistency checks, MongoDB provides the
following parameters:
.. list-table::
:header-rows: 1
:widths: 40 65
* - Parameter
- Description
* - :parameter:`enableShardedIndexConsistencyCheck`
- Enable or disable the index consistency checks.
* - :parameter:`shardedIndexConsistencyCheckIntervalMS`
- The interval at which the config server's primary checks the
index consistency of sharded collections.
Concurrent ``removeShard`` Operations
`````````````````````````````````````
Starting in MongoDB 4.4, you can have more than one
:dbcommand:`removeShard` operation in progress.
In earlier versions, :dbcommand:`removeShard` returns an error if
another :dbcommand:`removeShard` operation is in progress.
Shard Key Limit
```````````````
Starting in version 4.4, MongoDB removes the 512-byte limit on the
shard key size. For MongoDB 4.2 and earlier, a shard key cannot
exceed 512 bytes.
Partial Results
```````````````
Starting in 4.4, if the :dbcommand:`find` or subsequent
:dbcommand:`getMore` commands return partial results due to the
unavailability of the queried shard(s), the output includes a
boolean flag ``partialResultsReturned``.
Jumbo Chunk Migration
`````````````````````
.. include:: /includes/extracts/4.4-changes-migrate-jumbo-chunks.rst
Improved Catalog Cache Refresh
``````````````````````````````
Starting in 4.4, if there is a stale chunk, the catalog cache is only
refreshed when :ref:`routers <sharded-cluster-query-routing>` access
a shard that previously had or currently has that chunk.
Prior to MongoDB 4.4, any stale chunk caused the entire chunk distribution
for a collection to be marked as stale and forced all
:ref:`routers <sharded-cluster-query-routing>` who contact the shard
to refresh their shard catalog cache. MongoDB 4.4 adds the
:parameter:`enableFinerGrainedCatalogCacheRefresh` startup parameter
for disabling catalog cache refresh for only a targeted shard and using
the older catalog cache refresh behavior. The
:parameter:`enableFinerGrainedCatalogCacheRefresh` parameter defaults to
``true``.
Automatically Split ``system.sessions`` Collection
``````````````````````````````````````````````````
Starting in version 4.4 (and 4.2.7), MongoDB automatically splits the
``system.sessions`` collection into at least 1024 chunks and
distributes the chunks uniformly across shards in the cluster.
.. _4.4-projection:
Projection
----------
Starting in MongoDB 4.4, as part of making
:method:`~db.collection.find` and
:method:`~db.collection.findAndModify` projection consistent with
aggregation's :pipeline:`$project` stage,
- The :method:`~db.collection.find` and
:method:`~db.collection.findAndModify` projection can accept
aggregation expressions and aggregation syntax, including the use of
literals and aggregation variables. With the use of aggregation
expressions and syntax, you can project new fields or project
existing fields with new values.
- The :method:`~db.collection.find` and
:method:`~db.collection.findAndModify` projection can specify
embedded fields using the nested form; e.g. ``{ field: { nestedfield:
1 } }`` as well as :ref:`dot notation <document-dot-notation>`. In
earlier versions, you can only use the dot notation.
For more information, see:
- :method:`db.collection.find()`
- :method:`db.collection.findOneAndDelete()`
- :method:`db.collection.findOneAndReplace()`
- :method:`db.collection.findOneAndUpdate()`
- :method:`db.collection.findAndModify()`
.. seealso::
:ref:`4.4-compatibility-projection-restrictions`
.. _4.4-rel-notes-projection-meta-keyword:
.. _4.4-rel-notes-agg-meta-keyword:
``$meta`` Operator