Docs Menu
Docs Home
/
MongoDB マニュアル
/
リリースノート

MongoDB 4.4 のリリースノート

項目一覧

  • パッチ リリース
  • フルタイムの診断データキャプチャ要件
  • 集計
  • レプリカセット
  • シャーディングされたクラスター
  • プロジェクション
  • トランザクション
  • ソート
  • セキュリティの改善
  • 構造化ログ
  • プラットフォーム サポート
  • mongo shell
  • ツール
  • ドライバー
  • Indexes
  • 削除されたコマンド
  • ネットワーキング
  • 全般的な改善
  • 互換性に影響する変更
  • アップグレード手順
  • ダウングレードの検討事項
  • ダウンロード
  • 既知の問題点
  • 問題を報告する

警告

過去のリリース制限

以下の 重要な助言 は、一部の MongoDB の前のバージョンに影響します。 配置が重要な助言によって影響を受ける機能に依存している場合は、利用可能な最新のパッチ リリースにアップグレードしてください。

問題
影響を受けるバージョン
WT- 7426
4.4.5
4.4.8
4.4.2 - 4.4.8
4.4.0 - 4.4.18 （ARM64 または POWER システム アーキテクチャ）
4.4.8 - 4.4.21 （ MongoDB Ops ManagerまたはCloud Managerクラスターの増分バックアップ）
4.4.7

パッチ リリース

4.4.29 - Feb 28, 2024

重要

MongoDB Server が信頼できない接続が成功する可能性があることに対する修正

CVE- 2024 - 1351により、 4.4.29以前の MongoDB 4.4では、 --tlsCAFileおよびCAFileの特定の構成において、MongoDB Server がピア証明書の検証をスキップし、信頼できない接続が成功する可能性があります。

これにより、TLS によって提供されるセキュリティ保証と、証明書の検証のために閉じられる必要があるオープン接続を実質的に削減する可能性があります。 この問題は、次の MongoDB Server バージョンに影響します。

  • 7.0.0 - 7.0.5

  • 6.0.0 - 6.0.13

  • 5.0.0 - 5.0.24

  • 4.4.0 - 4.4.28

CVSS スコア: 8.8

CWE: CWE-295: 不適切な認定検証

  • SERVER-70155 mongod 「低速クエリ」ログ行に oplog スロットを開いたままにしている期間を追加する

  • SERVER-82353 movePrimary が同時に実行されると、マルチドキュメントトランザクションでドキュメントが失われる可能性あり

  • SERVER-83564 プロセス フィールドが config.locks でインデックスされていることを確認

  • SERVER-85536 [4 .4 ]インデックスのない一意の部分インデックスエントリの排除では、書込み競合 (write conflict) が発生します

  • すべての Jira の課題は 4.4.29 で終了しました

  • 4.4.29 変更履歴

4.4.28 - Jan 18, 2024

  • SERVER-77506 シャーディングされたマルチドキュメントトランザクションでは、データと ShardVersion が一致しない可能性があります。

  • SERVER-82365 バランサーのコレクション分散ステータスのヒストグラムの構築を最適化しました（2 回の試行）

  • SERVER-82883 ステップアップで TransactionCoordinator を回復すると、参加者が準備状態である間に読み取り/書き込みチケットの取得がブロックされる可能性があります。

  • WT-7929 チェックポイント中の FTDC ストールを回避するための解決法を調査すること

  • すべての Jira の課題は 4.4.28 で終了しました

  • 4.4.28 変更履歴

4.4.27 - Jan 3, 2024

  • SERVER-63865 不正なシャットダウン後のスタンドアロン起動の回復中に欠落したインデックス識別子の処理

  • SERVER-81106 受信者シャードは、クローンフェーズを開始する前にコレクション バージョンがローカルに保存されるのを待たない

  • SERVER-81878 startupRecoveryForRestore が正常に実行されない可能性あり

  • SERVER-82325 バランサーのラウンド中にコンフィギュレーションサーバーが変化する可能性あり

  • WT-11564 チェックポイントに存在する場合にのみ最新のトランザクション値を読み取るように RTS を修正

  • すべての Jira の課題は 4.4.27 で終了しました

  • 4.4.27 変更履歴

4.4.26 - 11 月27 、 2023

修正された問題:

  • SERVER-50792 shardCollection または refineCollectionShardKey のシャードキー インデックスが見つからない場合に、より有用なエラーを返す

  • SERVER-80021 double と string の間で $convert の正しくラウンドトリップを作成します

  • SERVER-81106 受信者シャードは、クローンフェーズを開始する前にコレクション バージョンがローカルに保存されるのを待たない

  • SERVER-81966 更新中に以前のチャンクマップ インスタンスの変更を避ける

  • WT-10424 削除された項目が多数ある場合は、 cursor::search_near パフォーマンスが低下します

  • すべての Jira の課題は 4.4.26 で終了しました

  • 4.4.26 変更履歴

4.4.25 - 9 月29 、 2023

修正された問題:

  • SERVER-76299 セカンダリの serverStatus での writeConflics の報告

  • SERVER-78828 ソート中に LDAP ホスト タイミング データの不整合が生じる可能性があります

  • WT-11031 チェックポイントに時間ウィンドウ情報がないテーブルをスキップするように RTS を修正

  • SERVER-70973 バランサーは、使用可能なシャードがなくなると、コレクションの反復を停止する必要があります

  • SERVER-71627 キャッシュされたコレクション ルート情報を更新すると、100万チャンクのクラスターですべてのクライアントリクエストが著しくブロックされる

  • SERVER-78813 lastCommited optime が null の消費カーソルでは、コミット ポイントの伝達が無期限に失敗する

  • WT-8570 復元中に最も古い ID を増加させない

  • WT-10449 履歴ストアに書き込むアップデートがない場合、アップデートチェーンを保存しないこと

  • すべての Jira の課題は 4.4.25 で終了しました

  • 4.4.25 変更履歴

4.4.24 - Aug 23, 2023

修正された問題:

4.4.23 - 7 月13 、 2023

4.4.22 - 5 月18 、 2023

4.4.21 - 4月は27 、 2023

修正された問題:

4.4.20 - Apr 10, 2023

修正された問題:

  • SERVER-51835 Mongos readPreferenceTags が期待どおりに機能していない

  • SERVER-74345 mongodb-org-server 4.4.19、5.0.15、6.0.5 は、古いバージョン（Debian、RPM パッケージ）からアップグレードした後に起動しない

  • SERVER-75205 すべての読み取りチケットが使い果たされた後に、ステップダウンと復元ロックの間でデッドロックが発生する

  • WT-9500 HSアップデートのキー/値のタイムスタンプではなく、セル時間枠を使用するようにRTSを修正

  • すべての Jira の課題は 4.4.20 で終了しました

  • 4.4.20 変更履歴

4.4.19 - Feb 27, 2023

警告

MongoDB の既存のインスタンスを MongoDB 4.4.19 にアップグレードする場合、 mongod.confファイルにfork: trueが設定されていると、そのインスタンスが起動に失敗する可能性があります。

アップグレードの問題は、 .debまたは.rpmインストール パッケージを使用するすべての MongoDB インスタンスに影響します。 tarball（ .tgz ）リリースまたはその他のパッケージ タイプを使用するインストールは影響を受けません。 詳細については、 SERVER-74345 を参照してください。

fork: true設定を削除するには、システム ターミナルから次のコマンドを実行します。

systemctl stop mongod.service
sed -i.bak '/fork: true/d' /etc/mongod.conf
systemctl start mongod.service

設定が削除された後に、2 番目のsystemctlコマンドはアップグレードされたインスタンスを起動します。

修正された問題:

  • サーバー -68122 最初の同期中にコレクション WiredTiger 構成文字列を複製する方法について調査します

  • SERVER-71759 dataSize コマンドは生成されません

  • SERVER-72222 mapReduce で single reduce が最適化されている場合、マージングの結果シャードされたクラスターが作成されると失敗します

  • SERVER-72535 シャーディングされたクラスターを使用すると、「管理」、「ローカル」、および「コンフィギュレーション」データベースを別のケースで作成できます

  • SERVER-70235 42V では範囲削除ドキュメントを作成しないでください。 -v4 .4コレクション UUID が一致しない場合のアップグレード

  • WT-9599 ホットバックアップロックを取得して、ブロックマネージャーでフォールトを呼び出します

  • すべての Jira の課題は 4.4.19 で終了しました

  • 4.4.19 変更履歴

4.4.18 - 11 月21 、 2022

修正された問題:

4.4.17 - 9 月28 、 2022

修正された問題:

4.4.16 - Aug 19, 2022

修正された問題:

4.4.15 - Jun 21, 2022

修正された問題:

  • SERVER-66433 重複する範囲の削除が完了するのを待機しているバックポートの期限が より前に完了するのを待機しています。51バージョン

  • SERVER-65821 コミット/中止の決定が永続的でなかったトランザクションが準備された場合、setFCV 中にデッドロックが発生する

  • SERVER-65131 便宜的読み取りターゲットを無効にします（ヘッジされた読み取りを除く）

  • SERVER-62272 コレクションにスキーマ検証を追加すると、失敗したドキュメントの チャンク移行 を防ぐことができます

  • SERVER-54900 ネットワーク呼び出しをブロックすると、同期ソースの解決が無期限に遅延する可能性があります

  • すべての Jira の課題は 4.4.15 で終了しました

  • 4.4.15 変更履歴

4.4.14 - 5 月9 、 2022

修正された問題:

4.4.13 - 3月は7と2022

修正された問題:

4.4.12 - Jan 21, 2022

修正された問題:

4.4.11 - Dec 30 、 2021

修正された問題:

  • WT-8395 4からのアップグレード後にデータの不整合。4 。3と4 。 4 。 4から4 。 4 。 8 + と5 。 0 。 2 +

  • SERVER- X60326 証明書に空のサブジェクト名がある場合、Windows Server の起動に失敗509

  • SERVER-60310 OCSP 応答の検証では、関連性のない証明書のステータスを考慮しないでください。

  • SERVER-59226 中断なしとしてマークされたプロファイル セッションで降格したときにデッドロックが発生する

  • SERVER-56226 [v4 .4 ]チャンク移行がコミットされないように、 config.collections エントリに 'permitMigrations' フィールドを導入しました

  • SERVER-51329 mongos サーバーをシャットダウンするときに予期しない再試行できないエラーが発生しました

  • SERVER-45953 oplog リーダーによる読み取りチケットの取得を除外する

  • すべての Jira の課題は 4.4.11 で終了しました

  • 4.4.11 変更履歴

4.4.10 - 10 月15 、 2021

修正された問題:

4.4.9 - 9 月21 、 2021

修正された問題:

  • SERVER-57630 : Ubuntu18 04で SSL_OP_NO_REN後に有効にするOpenSSL に対して実行する場合は1 です。1 。1

  • SERVER-34938 : oplog の単一バッチでキャッシュに固定されたコンテンツが原因で、セカンダリの速度低下またはハング

  • WT-8005 : 履歴保存のエントリが未解決のままになる可能性のある準備コミットのバグを修正

  • WT-7995 : チェックポイントの可視性を超えることのできない 可視性を修正Go

  • WT-7984 : チェックポイントによってデータのページが省略される可能性があるバグを修正しました

  • すべての Jira の課題は 4.4.9 で終了しました

  • 4.4.9 変更履歴

4.4.8 - Aug 4, 2021

修正された問題:

  • SERVER-58936 : 一意なインデックス制約は強制されない可能性があります

  • SERVER-58258 : 'replSetGetStatus' の応答に 'initialSync' フィールドがないため、アサートする前に最初の同期がクリアされるまで待機します

  • SERVER-52906 : 移行が失敗した後に moveChunk を実行すると、シャードキー インデックスが欠落しているため、ロールバックされたクローン インデックスが無期限にハングする可能性があります。

  • WT-7837 : アサートが発動しないように、 wt_hs_insert_updates でアップデート構造をクリアします

  • WT-6729 : 安定版のアクティブなトランザクション チェックへのロールバックを実行する前に、休止処理を実行します

  • すべての Jira の課題は 4.4.8 で終了しました

  • 4.4.8 変更履歴

4.4.7 - 7 月16 、 2021

修正された問題:

  • SERVER-57476 ：oplog スロットを保持している間に準備競合がブロックされ、レプリケーションが無期限に停止する可能性があります

  • SERVER-56054 : レプリケーション書込みスレッド プールの minThreads 値を に変更0

  • SERVER-53760 : $unwind + $sort パイプラインはディスクに書き出すときに多数のファイル処理を生成します

  • SERVER-47699 : 範囲削除で使用される出力タイプを、YELD_MANUAL から YELD_Auto に変更

  • WT-7185 : トランザクションが強制削除され、最も古い場合は、トランザクションを中止しないでください

  • すべての Jira の課題は 4.4.7 で終了しました

  • 4.4.7 変更履歴

4.4.6 - 5 月10 、 2021

修正された問題:

4.4.5 - Apr 8, 2021

修正された問題:

4.4.4 - Feb 16, 2021

修正された問題:

  • SERVER-48471 : ハッシュされたインデックスはマルチキーとして誤ってマークされ、シャードキーとして適格しない可能性があります

  • SERVER-50769 :expr{"expr":"_currentApplyOps.getArrayLength() >0 ","file":"src/mongo/db/pipeline/source_change_stream_transform.cp","line":535}}

  • SERVER-52919 : 最初の同期ではワイヤ圧縮は有効になっていません

  • WT-7109 : 下位互換性のためにサポートされなくなった構成オプションを保持する

  • WT-7117 : 更新の復元中に、ディスク上のベース更新よりも新しい変更をスキップするための RTS

  • すべての Jira の課題は 4.4.4 で終了しました

  • 4.4.4 変更履歴

4.4.3 - Jan 4, 2021

修正された問題:

4.4.2 - 11 月18 、 2020

修正された問題:

  • SERVER-48067 : 多数の非一意なキーを持つ一意のインデックス ビルドのメモリ消費を削減

  • SERVER-48523 : 変更ストリームを再開しようとする際に、oplog の最初のエントリを条件付きで確認します。

  • SERVER-50365 : タイムアウトできないトランザクションが長時間実行され、タイムアウトできない

  • SERVER-50394 : mongod 監査ログは、シャーディングされた環境内の _system ユーザーに DDL 操作を属性化します

  • SERVER-51041 : セカンダリ読み取りのトランザクションの開始を制限します

  • SERVER-51120 : 照合が指定されている場合に、MERGE_SORT を使用して結果を誤ってソートする

  • すべての Jira の課題は 4.4.2 で終了しました

  • 4.4.2 変更履歴

4.4.1 - 9 月9 、 2020

修正された問題:

  • SERVER-48531 :3 チャンク スプリット、準備されたトランザクション、ステップダウン スレッド間で 方法のデッドロックが発生する可能性があります。

  • SERVER-48641 : MigrationDestinationManager がセッションをチェックアウトした状態で書込み保証 (write concern)を待機しているため、デッドロック

  • SERVER-49546 : FCV4 4を に設定します。 は、範囲削除タスクを一度に 1 つずつではなくバッチで挿入する必要があります

  • SERVER-49694 : シャーディングされたクラスターでは、最も近い読み取りまたはヘッジされた読み取りは、ほぼシャードのレプリカにルーティングされない場合があります。

  • SERVER-50137 : で生成された oplog エントリが原因で、MongoDB は Invariant3 障害でクラッシュします。4

  • SERVER-50140 : 最初の同期は同期ソースの不正再起動に耐えられません

  • SERVER-50170 : mongos でサーバー選択が失敗する問題を修正しました

  • WT-6623 : リカバリファイルスキャンで接続レベルのファイル ID を設定する

  • すべての Jira の課題は 4.4.1 で終了しました

  • 4.4.1 変更履歴

フルタイムの診断データキャプチャ要件

バージョン4.4 以降、 または の フルタイム診断データ取得（FTDC） mongodmongosスレッドが失敗すると、元のプロセスが終了します。特に一般的な障害を回避するには、 mongod / mongosを実行しているユーザーに、 storage.dbPath内で FTDC diagnostic.dataディレクトリを作成する権限があることを確認します（ mongod ）、またはsystemLog.pathと並行して （ mongosの場合）、 ）。

集計

Union すべて（$unionWith ステージ）

MongoDB 4.4では$unionWith集計ステージが追加され、複数のコレクションのパイプライン結果を単一の結果セットに結合する機能が提供されます。

詳細については、$unionWith を参照してください。

カスタム集計式

バージョン4.4以降、 MongoDB は、ユーザーがカスタム集計式を定義できるようにする次の新しい演算子を提供します。

これらの新しい演算子を追加すると、 mapReduceと$whereに依存する代わりに、集計を使用してカスタム JavaScript 式を記述できます。

注意

バージョン 4.4 より前でも、カスタム関数なしで、 、 $group$mergeなど の他の 集計パイプライン演算子 を使用して、さまざまな map-reduce 式を書き換えることもできました。

詳細については、「 map-reduce から集計パイプラインへの移行 」を参照してください。

新しい集計演算子

演算子
説明
指定された文字列またはバイナリ データ値の内容のサイズをバイト単位で返します。
指定されたドキュメントのサイズをバイト単位で返します（つまりbsontype Object ）。（BSON としてエンコードされた場合）
配列内の最初の要素を返します。
カスタム集計式を定義します。

指定された式がinteger 、 decimal 、 double 、またはlongに解決される場合はブール値trueを返します。

式が他のBSON タイプ、 null 、または欠落したフィールドに解決される場合はブール値falseを返します

配列内の最後の要素を返します。
指定された入力内の一致した文字列の最初のインスタンスを置き換えます。
指定された入力内の一致した文字列のすべてのインスタンスを置き換えます。

全般的な集計の改善

$out

MongoDB 4.4 以降:

  • $outは別のデータベース内のコレクションに出力できます。 以前のバージョンでは、 $outは、集計が実行されるのと同じデータベースデータベース内のコレクションにのみ出力できます。

  • $outは、クラスター内のすべてのノードのfeatureCompatibilityVersionが4.4以上に設定されており、読み込み設定（read preference） でセカンダリ読み取りが許可されている場合にのみ、レプリカセットのセカンダリ ノードで実行できます。 ドライバーのドキュメントをチェックして、ドライバーがサポートをいつ追加したかを確認してください。

$indexStats

MongoDB 4.4以降（ 4.2.4以降でも利用可能 ）、 $indexStatsの出力には次のフィールドが含まれます。

フィールド
説明
シャードの名前（該当する場合）。
インデックス仕様ドキュメント
インデックスが現在ビルド中かどうかを示すブール値のフラグ。

$merge

MongoDB 4.4 以降:

  • $mergeは別のデータベース内のコレクションに出力できます。 以前のバージョンでは、 $mergeは、集計が実行されるのと同じデータベース内のコレクションにのみ出力できます。

  • $mergeは、クラスター内のすべてのノードのfeatureCompatibilityVersionが4.4以上に設定されており、読み込み設定（read preference） でセカンダリ読み取りが許可されている場合にのみ、レプリカセットのセカンダリ ノードで実行できます。 ドライバーのドキュメントをチェックして、ドライバーがサポートをいつ追加したかを確認してください。

$mergeは、集約されている同じコレクションに出力できます。 また、 $lookupなど、パイプラインの他のステージに表示されるコレクションに出力することもできます。

警告

$mergeの出力が集約されている同じコレクションに出力する場合、ドキュメントが複数回更新されたり、操作によって無限ループが発生したりする可能性があります。 この動作は、 $mergeによって実行されるアップデートによって、ディスクに保存されているドキュメントの物理的な場所が変更された場合に発生します。 ドキュメントの物理的な場所が変更されると、 $mergeはそのドキュメントを完全に新しいドキュメントとして表示し、追加のアップデートが行われる可能性があります。 この動作の詳細については、「 日付 の問題 」を参照してください。

$planCacheStats 変更点

バージョン 4.4 以降、

  • $planCacheStatsステージは、 mongosインスタンスとmongodインスタンスでも実行できます。 4の 。 2 、 $planCacheStatsステージはmongodインスタンスでのみ実行できます。

  • $planCacheStatsには新しいフィールドが含まれます。ホストフィールドと、 mongosに対して実行した場合は、シャードフィールドが含まれます。

  • mongoshell は、PlanCache.list() 集計ステージのラッパーとしてメソッド$planCacheStats を提供します。

  • MongoDB は以下を削除します。

    • planCacheListPlans およびplanCacheListQueryShapesコマンドと

    • PlanCache.getPlansByQuery() およびPlanCache.listQueryShapes()メソッド。

    代わりに$planCacheStatsまたはPlanCache.list()を使用してください。

$collStats 変更点

MongoDB 4.4以降、 $collStatsはqueryExecStatsフィールドを引数ドキュメントとして受け入れます。 このフィールドを指定すると、出力に次のフィールドが返されます。

collectionScansフィールドには、次のフィールドを含む埋め込みドキュメントが含まれています。

フィールド名
説明
total
コレクションスキャンを実行したクエリの総数を示す 64 ビットの整数。 合計は、追尾可能 (tailable) カーソル を使用したクエリと使用しなかったクエリで構成されています。
nonTailable

explain 変更点

MongoDB4.4 以降、db.collection.explain().aggregate() モードと モードでexecutionStats allPlansExecutionメソッドを実行すると、 explain 出力 にリストされる各 パイプライン ステージ にnReturned とexecutionTimeMillisEstimate が含まれます。

レプリカセット

再開可能な最初の同期

MongoDB 4.4以降、一時的なネットワーク エラー、コレクションの削除、コレクションの名前変更のいずれかによって同期プロセスが中断された場合、同期プロセスの再開が最初の同期を実行したセカンダリによって試行できるようになりました。再開可能な最初の同期を利用するには、同期ソースでも MongoDB 4.4 が実行される必要があります。同期ソースで MongoDB 4.2 またはそれ以前のバージョンが実行されている場合、一時的ではないネットワーク エラーが発生した際と同様に、セカンダリで最初の同期プロセスを再開する必要があります。

デフォルトでは、セカンダリによる最初の同期の再開は 24 時間試みられます。MongoDB 4.4 では、セカンダリによる最初の同期の再開の試行時間を制御するinitialSyncTransientErrorRetryPeriodSeconds サーバー パラメーターが追加されました。セカンダリによる最初の同期プロセスが設定した時間内に正常に再開できない場合、セカンダリにより、レプリカセットから正常なソースが新しく選択され、最初の同期プロセスが改めて最初から開始されます。

MongoDB 4.4より前では、プロセス中にエラーが発生すると、セカンダリは最初の同期全体を再開していました。

ストリーミングレプリケーション

MongoDB 4.4 以降では、同期元 ソースが同期元のセカンダリにoplogエントリの連続ストリームを送信します。

MongoDB 4.4 より前では、セカンダリはソース から 同期 のリクエストを発行して応答を待つことで、 oplog エントリのバッチを取得していました。これには、 oplogエントリのバッチごとにネットワーク上の往復が必要でした。 MongoDB 4.4 では、ストリーミングレプリケーションを無効にし、古いレプリケーション動作を使用するためのoplogFetcherUsesExhaustスタートアップ パラメータが追加されました。

詳細については、「ストリーミングレプリケーション 」を参照してください。

ロールバック ディレクトリ

mongo 4.4 以降、コレクションのロールバック ディレクトリは、コレクション名前空間ではなく、コレクションの UUID にちなんで命名されます。例:

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

詳細については、「データのロールバック 」を参照してください。

最小 oplog 保持期間

oplog エントリを保持する最小時間数を指定できます。ここで、 mongodは次の条件の 両方 が満たされている場合にのみ oplog エントリを削除します。

デフォルトでは、MongoDB は oplog の最小保持期間を設定せず、設定された最大 oplog サイズを維持するために、最も古いエントリから oplog を自動的に切り捨てます。

mongodの起動時に最小 oplog 保持期間を構成するには、次のいずれかを実行します。

実行中のmongodで最小 oplog 保持期間を設定するには、 replSetResizeOplogを使用します。mongodの実行中に最小 oplog 保持期間を設定すると、スタートアップ時に設定された値が上書きされます。対応する構成ファイルの設定またはコマンドラインのオプションの値を更新して、これらの変更がサーバーの再起動後も保持されるようにする必要があります。

重要

oplog は、設定された時間数だけ oplog エントリーを保持できるように、制約なしに拡張されます。そのため、書き込みが大量で保存期間が長い組み合わせにした場合は、システム ディスク容量が減少または枯渇する可能性があります。

Tip

以下も参照してください。

レプリカセット Oplog

slowOpSampleRate セカンダリ ログへの影響

MongoDB 4.4以降、レプリカセット セカンダリでのoplog アプリケーション ログの低速化はslowOpSampleRateの影響を受けます。 以前のバージョンでは、MongoDB はサンプル レートに関係なく、すべての低速 oplog のエントリをログに記録していました。

slowOpSampleRate は、プロファイリングまたはログに記録する必要がある低速操作の割合を指定します。

データを保持するレプリカセット ノードで同時にビルドされるインデックス

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

レプリカセット全体でインデックス構築を同時に開始するには、レプリカセットまたはシャーディングされたクラスター内の各 mongod は、featureCompatibilityVersion を少なくとも 4.4 に設定する必要があります。

レプリカセットまたはシャーディングされたクラスター上のインデックスは、データを保持するすべてのレプリカセット ノードで同時に構築されます。シャーディングされたクラスターの場合、インデックス構築は、インデックスが作成されるコレクションのデータを含むシャードでのみ行われます。プライマリは、インデックスを使用可能とマークする前に、自身を含む最小限のデータを保持する voting ノード（コミットクォーラム）でインデックス構築を完了する必要があります。

デフォルトでは、インデックスビルドでは、データを保持するすべての投票ノードのコミットクォーラムが使用されます。 デフォルト以外のコミット クォーラムでインデックスビルドを開始するには、 MongoDB 4.4 はcommitQuorumパラメータをcreateIndexesまたはそのshellヘルパーdb.collection.createIndex()とdb.collection.createIndexes() に追加します。

進行中のインデックスビルドに必要なクォーラムを変更するには、MongoDB 4.4で新しいsetIndexCommitQuorumコマンドを導入します。

詳細については、「レプリケートされた環境でのインデックス構築」を参照してください。

レプリカセットの再構成の変更

の変更 replSetReconfig

MongoDB 4.4以降、 replSetReconfigコマンドは、成功を返す前に、投票権のあるノードの過半数がレプリカ構成をインストールするまで待機します。 投票ノードとは、 が でmembers[n].votes ある1 レプリカ ノード（アービタを含む）です。まず、この操作は現在の構成がコミットされるまで待機してから、新しい構成をプライマリにインストールします。 その後操作は、投票権のあるノードの過半数が新しい構成をインストールしてから、正常に返されるまで待機します。 詳細については、「再構成により、過半数のノードがレプリカ構成をインストールするまで待機する」を参照してください。

replSetReconfigは、投票権のあるノードの過半数がデフォルトで構成をインストールするまで無期限に待機します。 MongoDB4.4 では、操作が正常に返されるまでの最大待機時間を指定するために、 に任意の maxTime replSetReconfigパラメータも追加されています。

MongoDB 4.4以降、 replSetReconfigコマンドで一度に追加または削除できるノードは、一度に1 votingメンバーのみです。 複数の投票メンバーを追加または削除するには、一連のreplSetReconfigまたはrs.reconfig()操作を発行して、一度に 1 つのメンバーを追加または削除します。 詳しくは、「再構成では一度に 1 人の投票メンバーしか追加または削除できない」を参照してください。

の変更 replSetGetConfig

replSetGetConfigコマンドは、プライマリで実行する場合に新しいオプションcommitStatus: trueを指定できます。 オプションを指定して実行すると、コマンドの出力にcommitStatusフィールドが含まれます。 この出力フィールドは、レプリカセットの以前の再構成がコミットされたかどうかを示し、レプリカセットを再度再構成する準備が整っているかどうかを示します。 詳しくは、 replSetGetConfigコマンドを参照してください。

レプリカ構成ドキュメントの変更

MongoDB4.4 は、レプリカセットterm 構成ドキュメント に フィールドを追加します。レプリカセット ノードは、 termとversionを使用して「最新」レプリカ構成でコンテキストを実現します。 featureCompatibilityVersion (fCV) : " 4 . 4 " に設定します 暗黙的にreplSetReconfigを実行して構成ドキュメントにtermフィールドを追加し、新しい構成がレプリカセット ノードの大部分に伝播するまでブロックします。 同様に、 fCV : "4.2"にダウングレードすると、 termフィールドが削除されるための再構成が暗黙的に実行されます。

優先される最初の同期ソース

MongoDB 4.4以降では、 initialSyncSourceReadPreferenceパラメータを使用して優先される最初の同期ソースを指定できます。 このパラメータは、mongod setParameter構成ファイル設定または--setParameter コマンドライン オプションを使用して、 の起動時にのみ設定できます。

initialSyncSourceReadPreference は、次の読み込み設定（read preference）モードをサポートします。

レプリカセットでchainingが無効になっている場合、デフォルトのinitialSyncSourceReadPreference読み込み設定（read preference）モードはprimaryです。

タグセットまたはmaxStalenessSecondsをinitialSyncSourceReadPreferenceに指定することはできません。

Tip

以下も参照してください。

最初の同期ソースの選択

ミラーリングされた読み取り

MongoDB バージョン 4.4 以降では、最近アクセスされたデータを使って、選出される可能性のあるセカンダリのキャッシュを事前にウォーミングアップするためのミラーリングされた読み取りが備わっています。ミラーリングされた読み取りでは、プライマリは受信した操作のサブセットをミラーリングし、選出可能なセカンダリのサブセットに送信できます。セカンダリのキャッシュを事前にウォームアップしておくと、選出後のパフォーマンスをより迅速に復元できます。

注意

プライマリのクライアントへの応答は、ミラーリングされた読み取りの影響を受けません。 ミラーリングされた読み取りは、プライマリによる "fire-and-foreget" 操作であり、つまり、プライマリはミラーリングされた読み取りの応答を待ちません。

ミラーリングされた読み取りのパラメーター

MongoDB 4.4では、次のミラーリングされた読み取りパラメータが追加されます。 このパラメータは、 setParameter構成ファイル設定または--setParameterコマンドライン オプションを使用してスタートアップ時に設定することも、 setParameterコマンドを使用して実行時に設定することもできます。

Parameter
説明

ミラーリングされた読み取りのsamplingRateとmaxTimeMS設定を指定します。

{ samplingRate: <float>, maxTimeMS: <int> }

samplingRate0の は、ミラーリングされた読み取りをオフにします。

ミラーリングされた読み取りのメトリクス

コマンドserverStatusとそれに対応するmongo shell メソッドdb.serverStatus()では、操作にフィールドを含めることを指定すると、 mirroredReadsが返されます。

db.runCommand( { serverStatus: 1, mirroredReads: 1 } )

or

db.serverStatus( { mirroredReads: 1 } )

シャーディングされたクラスター

調整可能なシャードキー

4.4以降、 MongoDB はrefineCollectionShardKeyコマンドを提供します。 新しい コマンドを使用すると、既存のキーにサフィックス フィールドを追加して、コレクションのシャードキーを調整できます。 コレクションのシャードキーを使用すると、よりきめの細かいデータ分散が可能になり、濃度が十分でないために既存のキーがジャンボ（不可分）チャンクになる状況に対応できます。

たとえば、シャードキー{ customer_id: 1 }を持つ既存のordersコレクションがあるとします。 シャードキーにサフィックスorder_id フィールドを追加してシャードキーを変更すると、{ customer_id: 1, order_id: 1 } が新しいシャードキーになり、customer_id フィールドとorder_id フィールドの両方によるデータ分散が可能になります。

refineCollectionShardKeyコマンドを使用するには、シャーディングされたクラスターの機能の互換性バージョン（fcv）が4.4である必要があります。 詳しくは、 refineCollectionShardKeyコマンドを参照してください。

注意

シャードキーを調整すると、コレクション内のすべてのドキュメントにサフィックス フィールドが存在しない場合があります。 欠落しているシャードキー フィールドを入力するには、「欠落しているシャードキー フィールド 」を参照してください。

シャードキーを検証する前に、コレクション内のすべてまたはほとんどのドキュメントにサフィックス フィールドが含まれていることを確認して、可能であれば、フィールドにその後にフィールドを入力する必要がないようにします。

以前のバージョンでは、シャードキーを選択すると、そのシャードキーを変更できません。

重要

欠落しているシャードキー

サフィックスを使用して シャードキーを調整 する機能を使用すると、コレクション内のすべてのドキュメントにサフィックス フィールドが存在しない場合があります。 バージョン4.4以降、シャーディングされたコレクション内のドキュメントには、シャードキー フィールドがないことがあります。 以前のバージョンでは、シャーディングされたコレクションのすべてのドキュメントにシャードキー フィールドが存在する必要がありました。 詳細については、「欠落しているシャードキー フィールド 」を参照してください。

ヘッジされた読み取り

レイテンシを最小限に抑えるために、 mongosインスタンスはデフォルトでヘッジされた読み取りを使用できます。 ヘッジされた読み取りを使用すると、 mongosインスタンスはクエリされたシャードごとに読み取り操作を複数のノードにルーティングして、シャードごとに最初の応答のあるノードから結果を返すことができます。 デフォルトでは、 mongosインスタンスはヘッジされた読み取りの使用をサポートしています。 mongosインスタンスのヘッジされた読み取りのサポートをオフにするには、readHedgingMode mongosの パラメータを設定します。

ヘッジされた読み取りは、 読み込み設定（read preference）の一部として操作ごとに指定されます。 primary以外の 読み込み設定（ read preference ） では、ヘッジされた読み取りがサポートされます。 読み込み設定（read preference nearestはデフォルトでヘッジされた読み取りを指定します。

詳細については、以下を参照してください。

ヘッジされた読み取りパラメーター

Parameter
説明
ヘッジされた読み取り のmongosインスタンスのサポートを有効または無効にします。

読み込み設定（read preference）のためのヘッジされた読み取りオプション

読み込み設定（read preference）でヘッジされた読み取りを指定する方法は、MongoDB 4.4でヘッジされた読み取りオプション を導入しています。 MongoDB ドライバーを使用して を設定するには、「 ドライバーの読み込み設定（ read preference）API ドキュメント 」を参照してください。

次のmongo shell メソッドは ヘッジ オプションを受け入れて、指定された読み込み設定（read preference）でヘッジされた読み取りを有効にできます。

ヘッジされた読み取りメトリクス

コマンドserverStatusとそれに対応するmongo shell メソッドdb.serverStatus()はhedgingMetricsを返します。

balancerCollectionStatus コマンド

MongoDB4.4{ }balancerCollectionStatus mongoshellsh.balancerCollectionStatus()には、シャーディングされたコレクションのチャンクがバランシングされているかどうか （ つまり、は、コマンドが実行されるか、または移動する必要がある時点で、移動する必要はありません）。 コマンドを使用すると、ユーザーは最初のチャンクの作成と移行が完了したことを確認できます。

mongos起動手順の改善

MongoDB 4.4以降、 mongosは次の新しいデフォルト起動動作を追加します。

  • mongos は、最初の受信クライアント接続に対してオンデマンドで行うのではなく、シャーディングされたクラスターのルーティング テーブルを起動時にプリロードします。

  • mongos は、受信クライアント接続に対してオンデマンドで実行するのではなく、起動時に接続プールをシャード ホストに事前にウォームアップします。

この動作により、 mongosインスタンスを起動または再起動した後の初期クライアント接続のサービスが高速化されます。 特にこれにより、複数のmongosインスタンスを使用するサイトでは、必要に応じてインスタンスを再起動したり、新しいインスタンスを追加したりすることができ、接続の確立を待つ必要がありません。

ルーティング テーブルのプリロードと接続プールの事前ウォーミングの両方がデフォルトで有効になっています。

MongoDB 4.4では、この動作を制御するための次のパラメーターが追加されています。

ルーティング テーブルの更新が改善されました

flushRouterConfigmovePrimaryまたはdropDatabase コマンドの実行後は、 の実行は必要なくなりました。これら 2 つのコマンドは、実行時に必要に応じてシャーディングされたクラスターのルーティング テーブルを自動的に更新するようになりました。 「 FlutterConfig に関する考慮事項flushRouterConfig 」で説明されている場合には、 コマンドを手動で発行することも推奨されます。

ハッシュされた複合シャードキー

MongoDB 4.4以降では、単一の ハッシュされたフィールド を持つ 複合 シャードキーを使用してコレクションをシャーディングできます。 4.4より前は、MongoDB は ハッシュされたフィールドを持つ複合シャードキーをサポートしていませんでした。

ハッシュされた複合シャーディングは、ゾーン シャーディングなどの機能をサポートします。ここで、プレフィックスは（つまり 最初の）ハッシュされていないフィールド（1 つまたは複数）はゾーン範囲をサポートし、ハッシュされたフィールドはシャーディングされたデータのより均等な分散をサポートします。 たとえば、次の操作では、ゾーン シャーディングをサポートする複合ハッシュされたシャードキーでコレクションをシャーディングします。

sh.shardCollection(
  "examples.compoundHashedCollection",
  { "fieldA" : 1, "fieldB" : 1, "fieldC" : "hashed" }
)

ハッシュされた複合シャーディングでは、単調に増加するフィールドに関連するデータ分散の問題を解決するために、ハッシュされたプレフィックス付きのシャードキーもサポートされています。たとえば、次の操作では、ハッシュされたフィールドがシャードキーのプレフィックスである複合ハッシュされたシャードキー上のコレクションをシャーディングします。

sh.shardCollection(
  "examples.compoundHashedCollection",
  { "_id" : "hashed", "fieldA" : 1}
)

Tip

以下も参照してください。

チャンク移行のフェイルオーバーの回復力の改善

MongoDB 4.4以降、次の変更により、フェイルオーバー中のチャンク移行 と孤立したドキュメント のクリーンアップの回復力が改善されます。

  • チャンク移行後のクリーンアップを待機しているチャンク範囲がconfig.rangeDeletionsコレクションに保存され、シャード全体に複製されるようになりました。 フェイルオーバーが発生すると、シャードの新しいプライマリはconfig.rangeDeletionsコレクション内のドキュメントを読み取り、対応する範囲の削除を再開します。 クリーンアップを待機している範囲を記述するドキュメントは、範囲が削除されるとconfig.rangeDeletionsコレクションから削除されます。

  • cleanupOrphanedコマンドでは、シャードから 孤立したドキュメント が削除されなくなりました。 代わりに、 cleanupOrphanedは、シャードからの削除が予定されている 孤立したドキュメント が削除されるのを待機します。

シャードのプライマリでdisableResumableRangeDeleterパラメータをtrueに設定すると、シャードで範囲の削除が一時停止されます。

シャーディングされたクラスターの全体的な改善

インデックスの整合性チェック

MongoDB 4.4以降、 コンフィギュレーションサーバーのプライマリは、デフォルトでは、シャーディングされたコレクションのシャード間でのインデックスの不整合をチェックします。 コマンドserverStatusは、構成サーバーのプライマリで実行された場合にインデックスの不整合を報告するフィールドshardedIndexConsistencyを返します。

インデックスの整合性チェックを構成するために、MongoDB は次のパラメータを提供します。

Parameter
説明
インデックスの整合性チェックを有効または無効にします。
コンフィギュレーションサーバーのプライマリがシャーディングされたコレクションのインデックスの整合性をチェックする間隔。

removeShard操作の同時実行

MongoDB 4.4以降では、複数のremoveShard操作を進行させることができます。

以前のバージョンでは、別の 操作が進行中の場合、removeShard removeShardはエラーを返していました。

シャードキーの制限

バージョン4.4以降、 MongoDB では、シャードキー サイズの512バイトの制限が削除されます。 MongoDB 4.2以前の場合、シャードキーは512バイトを超えることはできません。

部分的な結果

4.4以降では、クエリされたシャードが使用できないために、 findまたは後続のgetMoreコマンドが部分的な結果を返す場合、出力にはブール値フラグpartialResultsReturnedが含まれます。

ジャンボチャンク移行

移行するには大きすぎるチャンクの場合（MongoDB 4.4以降）

カタログ キャッシュの更新が改善されました

4.4以降では、古いチャンクがある場合、カタログ キャッシュは、以前にそのチャンクを持っていた、または現在そのチャンクを持っているシャードにルーターがアクセスした場合にのみ更新されます。

MongoDB 4.4 以前では、古いチャンクがあると、コレクションのチャンク配布全体が古いとしてマークされ、シャードにアクセスするすべてのルーターにシャード カタログ キャッシュの更新が強制されていました。 MongoDB 4.4 では、対象シャードのみのカタログ キャッシュ更新を無効にし、古いカタログ キャッシュ更新動作を使用するためのenableFinerGrainedCatalogCacheRefreshスタートアップ パラメーターが追加されました。 enableFinerGrainedCatalogCacheRefreshパラメータのデフォルトはtrueです。

system.sessionsコレクションの自動分割

バージョン4.4以降（および4.2.7 ）、 MongoDB は、 system.sessionsコレクションを少なくとも1024チャンクに自動的に分割し、そのチャンクをクラスター内のシャード全体に均等に分散します。

プロジェクション

MongoDB 4.4 以降では、 find()とfindAndModify()のプロジェクションを集計の$projectステージと一貫性を持たせるために、

  • find()とfindAndModify()のプロジェクションでは、リテラルや集計変数の使用など、集計式と集計構文を受け入れることができます。 集計式と構文を使用して、新しいフィールドをプロジェクションしたり、既存のフィールドを新しい値でプロジェクションしたりできます。

  • find()とfindAndModify()プロジェクションでは、ネストされた形式を使用して埋め込みフィールドを指定できます。例: { field: { nestedfield: 1 } }およびドット表記。 以前のバージョンでは、ドット表記のみを使用できました。

詳細については、以下を参照してください。

Tip

以下も参照してください。

パスの不一致の制限

$meta 演算子

$meta キーワード サポート

MongoDB 4.4以降、 $meta演算子はindexKeyメタデータを検索するためのサポートを追加します。 indexKeyメタデータはデバッグ目的のみで使用され、アプリケーション ロジックには使用できません。 詳しくは、 $metaを参照してください。

{ $meta: "textScore" } で使用する find()

バージョン4.4以降、 MongoDB では、{ $meta: "textScore" } と併用する場合、次のdb.collection.find() が変更されます。

  • $textを使用するには、クエリ述語に{ $meta: "textScore" } 演算子を指定する必要があります。

    注意

    $text は、自己管理型（Atlas 以外）配置に対するテキスト クエリ機能を提供します。MongoDB Atlas でホストされているデータに対して、MongoDB は改良された全文クエリ ソリューションである Atlas Search を提供します。

  • 結果のドキュメントを検索の関連性（つまり{ $meta: "textScore" } ）でソートすることができ、 textScoreをプロジェクションする 必要もありません 。

    In earlier versions, to include { $meta: "textScore" } expression in the sort(), you must also include the same expression in the projection.

  • プロジェクションとソートの両方に{ $meta: "textScore" }式を含める場合、つまりdb.collection.find(<$text search>, <projection>).sort(<sort>)は、プロジェクション ドキュメントとソート ドキュメントで式のフィールド名が異なる場合があります。

    In previous versions of MongoDB, if you include the { $meta: "textScore" } in both the projection and sort, you must specify the same field name in both places.

詳細については、テキスト スコア メタデータ$meta: "textScore"を参照してください。 "textScore"のプロジェクションとソートの例については、「関連性スコアの例 」を参照してください。

詳細については、テキスト検索メタデータ { $meta: "textScore" } クエリ要件

トランザクション

機能の互換性バージョン（fcv） "4.4"を持つ MongoDB 4.4 700} 以降では、トランザクションがクロスシャード間書込みトランザクション（write transaction） でない限り、マルチドキュメントトランザクション内にコレクションとインデックスを作成できます。

トランザクション内でコレクションを作成する際、以下を実行できます。

トランザクション内でインデックスを作成する際、以下を実行できます。

  • 存在しないコレクションにインデックスを作成できます。 コレクションは、操作中に作成されます。

  • 同じトランザクション内で以前に作成された新しい空のコレクションにインデックスを作成すること

  • システム コレクションdb.collection.createIndex() に対して実行すると、 メソッドは失敗します。

詳細については、「トランザクション内でのコレクションとインデックスの作成 」を参照してください。

MongoDB 4.4には、トランザクション内でのコレクションとインデックスの作成を有効（デフォルト）または無効にできる新しいパラメータshouldMultiDocTxnCreateCollectionAndIndexesが追加されました。 シャーディングされたクラスターのパラメーターを設定する場合は、すべてのシャードに パラメーターを設定します。

トランザクション内でコレクションまたはインデックスを明示的に作成する場合、トランザクションの読み取り保証（read concern）は "local" でなければなりません。明示的な作成には次のコマンドとメソッドが使用されます。

コマンド
方式

Tip

以下も参照してください。

ソート

$sort 変更点

MongoDB 4.4以降、 sort()メソッドで$sort集計ステージと同じソート アルゴリズムが使用されるようになりました。 この変更により、重複する値を含むフィールドに対してsort()を実行するクエリでは、それらの値のソート順序が一貫しない可能性が高まります。

重複する値に対してsort()を使用するときに並べ替えの整合性を保証するには、一意の値のみを含む追加のフィールドを並べ替えに含めます。

これは、並べ替えに_idフィールドを追加することで簡単に実現できます。

詳細については、「ソートの整合性」を参照してください。

セキュリティの改善

新しい Kerberos 検証ツール mongokerberos

MongoDB Enterprise 4.4は、MongoDB で使用するためのプラットフォームの Kerberos 構成を検証し、Kerberos を介してエンドツーエンドのクライアント認証をテストするための新しいmongokerberosツールを提供します。 実行すると、 mongokerberosは発生した問題を示すレポートを返し、その問題を解決するための潜在的なアドバイスを提供します。 mongokerberosは MongoDB Enterprise でのみ利用可能です。

OCSP

バージョン4.4以降、 MongoDB では、証明書の失効をチェックするために、OCSP（Online Certificate Status Protocol、オンライン証明書ステータス プロトコル）を使用することがデフォルトで有効になっています。 OCSP を使用すると、 Certificate Revocation List (CRL)を定期的にダウンロードし、アップデートされた CRL を使ってmongod / mongosを再起動する必要がなくなります。

バージョン 4.0 および 4.2 では、Windows または macOS で system certificate store を使用する場合にのみ OCSP を使用できます。

Tip

以下も参照してください。

TLS/SSL (トランスポート暗号化)

OCSP ステープリング/ステープリングが必要です

MongoDB 4.4は、OCSP サポートの一環として、Linux 上で以下をサポートします。

  • OCSP ステープリング 。OCSP ステープリングを使用すると、mongod インスタンスおよび mongos インスタンスは、TLS/SSL ハンドシェイク中にこれらの証明書をクライアントに提供するときに、証明書に OCSP ステータス応答を添付、つまり「ステープリング（ホチキス止め）」します。OCSP ステータス応答が証明書に添付されているため、OCSP ステープリングでは、提供された証明書の OCSP ステータスを取得するためにクライアントが別のリクエストを行う必要がありません。

  • OCSP must-staple 拡張機能。OCSP must-staple は、サーバー証明書に追加できる拡張機能であり、TLS/SSL ハンドシェイク中にクライアントが証明書を受信するときに OCSP ステープリングを要求するように指示します。

OCSP パラメータ

MongoDB 4.4は、次の OCSP パラメータを追加します。 これらのパラメータは、 setParameter構成ファイル設定または--setParameterコマンドライン オプションを使用して起動時に設定できます。

Parameter
説明
OCSP サポートを有効または無効にします。
ステープリングされた OCSP ステータス応答をリフレッシュする前に待機する時間を秒単位で指定します。
mongod / mongosインスタンスが証明書の OCSP ステータス応答を受信するまで待機する最大秒数を指定します。
クライアント証明書を検証するときに、 mongod / mongosが OCSP 応答を待機する最大秒数を指定します。

有効期限が近い x.509証明書のtrigger警告

MongoDB 4.4以降、 が x を表示すると、 mongod / mongosは接続時に警告を記録します。 509証明書は、 mongod/mongosシステム クロックから30日以内に期限切れになります。 具体的には、mongod または mongos への次の接続で x.509 証明書の有効期限警告がtriggerされます。

警告ログ メッセージは次のようになります。

<Timestamp> W NETWORK [connection] Peer certificate <Certificate Subject Name> expires...

クライアント x を積極的に更新することを検討してください。クラスターへの継続的な接続を確保するために、有効期限が近い509証明書。

MongoDB 4.4には、証明書の有効期限警告しきい値を制御するためのtlsX509ExpirationWarningThresholdDaysパラメータが追加されています。 警告を無効にするには、パラメーターを0に設定します。 完全なドキュメントについては、 tlsX509ExpirationWarningThresholdDaysを参照してください。

TLS 1.3 サポート

CentOS 8および RHEL 8では、MongoDB 4.4 （およびバージョン4.2 、 4.0 、 3.6 ）は TLS 1をサポートしています。 3 。

ネットワークまたは認証の失敗時にユーザーから DN へのマッピングが終了

mongod 、 mongos 、またはmongoldapは、LDAP サーバーとのネットワーク接続や認証に失敗してユーザーと DN（Distinguished Name、識別名）のマッピングのいずれかが評価できない場合にエラーを返します。

mongod 、 mongos 、またはmongoldapは接続リクエストを拒否し、残りのマッピングがある場合はチェックしません。

ユーザーから DN へのマッピングを指定するには、次を参照してください。

構造化ログ

MongoDB 4.4以降、 mongod / mongosインスタンスはすべてのログ メッセージを構造化 JSON 形式で出力するようになりました。 ログ エントリは、一連のキーと値のペアとして書き込まれます。各キーは「重大度」などのログ メッセージのフィールド タイプを示し、対応する値はそれぞれ、「情報」など、そのフィールド タイプに関連するログ情報を記録します。

これには、ファイル、 syslog 、 stdout （標準出力） のログ出力先、およびgetLogコマンドの出力に送信されるログ出力が含まれます。

以前は、ログ エントリはプレーンテキストとして出力されていました。

JSON 形式の次のログ メッセージは、 mongodが接続をリッスンし、準備ができていることを示しています。

{"t":{"$date":"2020-05-18T20:18:13.533+00:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"127.0.0.1"}}
{"t":{"$date":"2020-05-18T20:18:13.533+00:00"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":27001,"ssl":"off"}}

キーと値のペアによる構造化されたロギングにより、自動ツールやログ取り込みサービスによる効率的なログ分析が可能になり、プログラムによるログ解析の難易度が下がります。

MongoDB 構造化ログを使用する場合、サードパーティの jqコマンドライン ユーティリティ は、ログ エントリーを簡単かつきれいに印刷したり、キーに基づく強力なマッチングとフィルタリングを実行したりできる便利なツールです。

jq はオープンソースの JSON パーサーで、Linux、Windows、macOS で利用できます。

ログ エントリ コンポーネントの詳細な調査やコマンドライン解析の例など、構造化ログの詳細については、「ログ メッセージ 」を参照してください。

複数の LDAP パスワードをサポート

MongoDB 4.4以降、 ldapQueryPassword setParameterコマンドは string または string の配列のいずれかを受け付けます。 配列に設定されている場合、成功するまで各パスワードが試行されます。 これを使用して、MongoDB のダウンタイムなしで LDAP アカウント パスワードのロールオーバーを実行できます。

プラットフォーム サポート

追加されたプラットフォーム

MongoDB 4.4は、次のプラットフォームのサポートを追加します。

削除されたプラットフォーム

MongoDB 4.4では、次のプラットフォームのサポートが除かれます。

  • Amazon Linux 2013.03

  • RHEL 6 / CentOS 6 / Oracle 6 （ s 390 xアーキテクチャ上）

  • Windows 7 / Server 2008 R 2

  • Windows 8 / Server 2012

  • Windows 8.1 / Server 2012 R 2

  • macOS 10.12

MongoDB 4.4でサポートされているプラットフォームとアーキテクチャの完全なリストについては、「プラットフォーム サポート」を参照してください。

mongo shell

mongoshellはAmazon Web Services クラスターの IAM 認証情報をサポートしますAtlas

MongoDB4.4以降、 はmongoshell Amazon Web ServicesIAM 認証情報 の使用をサポートしています は、 IAMMongoDB Atlas 認証用に構成されたAmazon Web Services クラスターを認証します。

この方法で認証するには、新しい MONGODB-AWS authentication mechanismを使用し、 Amazon Web ServicesのアクセスキーIDとシークレットアクセスキーを指定する必要があります。これらは接続stringまたはコマンドラインで--usernameと--passwordオプション。

さらに、Amazon Web Services のセッショントークン を使用している場合は、 、 AssumeRole を使用する場合の一時的な認証情報による認証用 リクエスト、またはこの値を指定する のリソース（Amazon Web Services Lambdastringなど）を操作する場合は、AWS_SESSION_TOKENauthMechanismProperties 値を使用して接続 に、または コマンドラインで オプションを使用して、そのセッション--awsIamSessionToken トークンを提供できます。 。

あるいは、Amazon Web Services のアクセスキーID 、シークレット アクセスキー、またはセッション トークンが、それぞれのAmazon Web Services IAM 環境変数 を使用してプラットフォーム上で定義されている場合は、mongoshell はこれらの環境変数の値を使用して認証を行います。接続string で指定する必要はありません。

使用方法については「接続string認証オプション 」を、例については「 MONGODB-AWS を使用したAtlasクラスターへの接続」を参照してください。

ツール

MongoDB Database Tools プロジェクトへの移行

MongoDB 4.4以降、次のツールのドキュメントはMongoDB Database Tools プロジェクトに移行されました。

MongoDB Database Tools は、 Apache ライセンス、バージョン2.0を使用します。 MongoDB/mongo-tools を参照してください ソース コード用。

注意

リストされているツールの以前のバージョンに関するドキュメントについては、そのバージョンの MongoDB サーバー マニュアルを参照してください。

古いドキュメントへのクイックリンク:

新しいmongokerberos Kerberos 検証ツール

MongoDB Enterprise 4.4は、MongoDB で使用するためのプラットフォームの Kerberos 構成を検証し、Kerberos を介してエンドツーエンドのクライアント認証をテストするための新しいmongokerberosツールを提供します。 実行すると、 mongokerberosは発生した問題を示すレポートを返し、その問題を解決するための潜在的なアドバイスを提供します。 mongokerberosは MongoDB Enterprise でのみ利用可能です。

詳しくは、 mongokerberosリファレンス ページを参照してください。

mongoreplay MongoDB パッケージから削除

MongoDB 4.4以降、MongoDB パッケージからmongoreplayが削除されました。 mongoreplayとそれに関連するドキュメントは mongodb-lass に 移行されます Github プロジェクト。mongodb-labsのプロジェクトは実験的なものであり、MongoDB によって公式にサポートされていないため、

古いドキュメントへのクイックリンク

Windows MSI にパッケージ化されていない MongoDB Database Tools

Community エディションと Enterprise エディションの両方のWindows MSI インストーラーにはMongoDB Database Toolsは含まれていません（ mongoimport 、 mongoexportなど）。 Windows に MongoDB Database Tools をダウンロードしてインストールするには、「 MongoDB Database Toolsのインストール 」を参照してください。

MongoDB 4.2またはそれ以前の MSI インストーラーを使用して MongoDB Server とともに Database Tools をインストールしていた場合は、Database Tools を個別にダウンロードする必要があります。

ドライバー

新しいドライバー

Indexes

ハッシュされた複合インデックス

MongoDB 4.4は、単一のハッシュされたフィールドを含む複合インデックスの作成のサポートを追加します。 MongoDB 4.2以前は、単一フィールドのハッシュされたインデックスのみをサポートしていました。

次の操作では、 countryと_idにハッシュされた複合インデックスが作成されます。

db.examples.createIndex( { "country" : 1, "_id" : "hashed" } )

ハッシュされた複合インデックスでは、 featureCompatibilityVersionを4.4に設定する必要があります。

Tip

以下も参照してください。

ハッシュされた複合シャードキー

Hidden Indexes

バージョン4.4以降、 MongoDB adds the ability to hide or unhide indexes from the query planner. クエリ プランナーから非表示のインデックスは、クエリプラン選択手順の一部として評価されません。

プランナーからインデックスを非表示にすることで、インデックスを削除せずに、インデックスを削除した場合の潜在的な影響を評価できます。 影響がマイナスの場合は、削除されたインデックスを再度作成する必要がある代わりに、インデックスを再表示できます。 また、インデックスは非表示になっている間完全に維持されているため、非表示のインデックスは非表示にならないとすぐに使用できるようになります。

詳細については、「非表示のインデックス 」を参照してください。

非表示のインデックスをサポートするために、MongoDB は以下を導入します。

dropIndexes 進行中のインデックスビルドを中止できる

dropIndexesに指定されたインデックスがまだビルド中の場合、 dropIndexesは進行中のビルドを中止しようとします。 インデックスのビルドを中止すると、ビルドされたインデックスを削除するのと同じ効果があります。 MongoDB 4.4より前では、コレクションで進行中のインデックスビルドがある場合、 dropIndexesはエラーを返していました。 この動作は、 shellヘルパーdb.collection.dropIndex()とdb.collection.dropIndexes() にも適用されます。

  • dropIndexes / dropIndexes()に指定されるインデックスは、特定のインデックス ビルダに関連付けられている進行中のビルドのセット全体である必要があります。つまり、単一のcreateIndexesまたはdb.collection.createIndexes()操作によってビルドされたインデックスです。

  • dropIndex()に指定されるインデックスは、インデックス ビルダに関連付けられた唯一のインデックスである必要があります。つまり、単一のcreateIndexesまたはdb.collection.createIndexes()操作によってビルドされたインデックスです。

関連する進行中のビルドのセットから特定のインデックスを削除するには、インデックスのビルドが完了するまで待ってから、そのインデックスをdropIndexesまたはそのshellヘルパーに指定します。

より詳細なドキュメントについては、以下を参照してください。

drop() 進行中のインデックスビルドを中止できる

db.collection.drop()メソッドとdropコマンドは、コレクションを削除する前に、ターゲット コレクションで進行中のインデックス ビルドを中止します。

レプリカセットまたはシャード レプリカセットの場合、プライマリでインデックスを中止しても、セカンダリ インデックス構築は同時には中止されません。MongoDB は、プライマリ上の指定されたインデックスの進行中の構築を中止しようとし、成功した場合は関連するabort oplog エントリを作成します。進行中の構築が複製されたセカンダリ ノードは、インデックス構築をコミットまたは中止する前に、プライマリからのコミットまたは中止の oplog エントリを待ちます。

レプリカセットまたはシャード レプリカセットの場合、プライマリでインデックスを中止しても、セカンダリ インデックス構築は同時には中止されません。MongoDB は、プライマリ上の指定されたインデックスの進行中の構築を中止しようとし、成功した場合は関連するabort oplog エントリを作成します。進行中の構築が複製されたセカンダリ ノードは、インデックス構築をコミットまたは中止する前に、プライマリからのコミットまたは中止の oplog エントリを待ちます。

dropDatabase 進行中のインデックスビルドを中止できる

db.dropDatabase()メソッドとdropDatabaseコマンドは、データベースを削除する前に、ターゲット データベース内のコレクションに対して進行中のインデックスのビルドを中止します。 インデックスのビルドを中止すると、ビルドされたインデックスを削除するのと同じ効果があります。

Tip

以下も参照してください。

データが存在するコレクションでのインデックス構築

インデックスと コマンドの非推奨geoHaystackgeoSearch

MongoDB 4.4では、 geoHaystackインデックスとgeoSearchコマンドが非推奨になります。 代わりに、 または $geoNearとともに$geoWithin2 d インデックス を使用してください。

削除されたコマンド

MongoDBでは次のコマンドとmongo shellヘルパーが削除されます。

削除されたコマンド
削除されたヘルパー
代替手段
cloneCollection
db.cloneCollection()

  • mongoexportとmongoimportを使用するか、

  • 集計パイプライン$outまたは$mergeステージを使用するか、 または

  • ドライバーを使用してスクリプトを作成します。

planCacheListPlans
PlanCache.getPlansByQuery()

  • 集計パイプライン ステージ$planCacheStatsを使用するか、

  • mongo shellヘルパー メソッドPlanCache.list()を使用します。 （バージョン4.4以降で利用可能 ）

See also $planCacheStats Changes.
planCacheListQueryShapes
PlanCache.listQueryShapes()

  • 集計パイプライン ステージ$planCacheStatsを使用するか、

  • mongo shellヘルパー メソッドPlanCache.list()を使用します。 （バージョン4.4以降で利用可能 ）

See also $planCacheStats Changes.

ネットワーキング

TCP Fast Open のサポート

MongoDB 4.4以降、 mongodとmongosは TCP Fast Open（TFO）接続をデフォルトでサポートしています。 TFO には、クライアントとmongod/mongosホストの両方で次のように TFO がサポートされ、有効である必要があります。

Windows

次の Windows オペレーティング システムは TFO をサポートしています。

  • Microsoft Windows Server 2016以降。

  • Microsoft Windows 10 Update 1607以降。

MacOS
macOS 10.11 （El Capitan）以降は TFO をサポートしています
Linux

Linux カーネル3.7以降を実行している Linux オペレーティング システムは、インバウンド TFO 接続をサポートできます。

Linux カーネル4.11以降を実行している Linux オペレーティング システムは、インバウンド TFO 接続とアウトバウンド TFO 接続の両方をサポートできます。

インバウンド TFO 接続およびアウトバウンド TFO 接続のサポートを有効にするには、 /proc/sys/net/ipv4/tcp_fastopenの値を設定します。

  • アウトバウンド TFO 接続のみを有効にするには、 1に設定します

  • インバウンド TFO 接続のみを有効にするには、 2に設定します

  • インバウンド TFO 接続およびアウトバウンド TFO 接続を有効にするには、 3 を設定します。

MongoDB 4.4は、TFO を制御するための次のパラメーターを追加します。

Parameter
説明

デフォルト: true （有効）

へのインバウンド TFO 接続のサポートを有効または無効にします mongod/mongos

デフォルト: true （有効）

Linux オペレーティング システムのみ。

mongod/mongosからのアウトバウンド TFO 接続のサポートを有効または無効にします。

デフォルト: 1024

保留中の TFO 接続のキューのサイズを制御します。

MongoDB 4.4は、 serverStatusとdb.serverStatus()の出力に次のカウンターを追加します。

カウンター
説明

Linux のみ

TFO のカーネル サポートを示します。

受信 TFO 接続に対するオペレーティング システムのサポートを示します。
オペレーティング システムが送信 TFO 接続をサポートしていることを示します。
mongod/mongosが最後に起動されて以降にmongod / mongosに受け入れられた着信 TFO 接続の合計数を示します。

TFO の完全な説明は、このドキュメントの範囲外です。 TFO の詳細については、次の外部リソースを参照してください。

全般的な改善

ブロッキングソートの制限の増加

MongoDBは、1 つまたは複数のインデックスを使用して特定のcursor.sort()操作のソート順序を取得できない場合、データに対してブロッキングソートを実行MongoDB必要があります。 ブロッキングソートは、結果を返す前に MongoDB が、ソートへのすべての入力ドキュメントを消費して処理する必要があることを示します。 ブロッキングソートは、コレクションまたはデータベースに対する同時操作をブロックしません。

MongoDB 4.4より前は、 MongoDB は、ブロッキングソート操作に32 MB を超えるシステム メモリを必要とする場合、エラーを返しました。 MongoDB 4.4以降、ブロッキングソート操作により、ソート操作に使用するシステムメモリの制限が100メガバイトに増加します。 100MB を超えるシステム メモリを必要とするブロッキングソート操作の場合、クエリが を指定 しcursor.allowDiskUse() ない限り 、MongoDB はエラーを返します（ MongoDB の新機能4 .4 ）。

ソートとインデックスの使用の詳細については、「ソートとインデックスの使用 」を参照してください。

Tip

以下も参照してください。

find 一時ファイルを使用した大規模なインデックスなしソートのサポートが可能

MongoDB4.4 は コマンドに新しいオプション allowDiskUse findを追加します。allowDiskUse: trueを設定すると、操作は100 MB のメモリ制限を超えるインデックスなし（「ブロッキング」）ソート操作を処理するときにディスク上の一時ファイルを使用できます。 MongoDB 4の前。 4で、ソート処理中にメモリ制限を超えた場合、ブロッキングソートを使用したfind操作は失敗します。

を使用する db.collection.find()shellcursor.sort() 4.4cursor.allowDiskUse()メソッドには、MongoDB は カーソル修飾子を追加します。

allowDiskUseとcursor.allowDiskUse()は、MongoDB がインデックスを使用してソートを満たすことができる場合、またはブロッキングソートに必要なメモリが100 MB 未満の場合、効果がありません。

MongoDB ドライバーを介して発行されたクエリに対してallowDiskUseを有効にする手順については、ご希望のMongoDB 4.4互換ドライバーのドキュメントを参照してください。

Tip

以下も参照してください。

コレクション名前空間の制限

MongoDB 4.4以降、

featureCompatibilityVersionが"4.4"以上に設定されている場合、MongoDB はコレクションまたはビューの名前空間の制限を255バイトに引き上げます。 コレクションまたはビューの名前空間には、データベース名、ドット（ . ）セパレーター、コレクションまたはビューの名前（例: <database>.<collection> ）、

検証データのスループット情報

$currentOpコマンドとcurrentOpコマンドには、進行中の操作を検証するためのdataThroughputAverageとdataThroughputLastSecond情報が含まれています。

検証操作のログ メッセージには、 dataThroughputAverageとdataThroughputLastSecondの情報が含まれます。

Tip

以下も参照してください。

db.collection.validate() パラメーターの変更

compact 動作の変化

ブロッキング

MongoDB 4.4以降、 compactは次のメタデータ操作のみをブロックします。

compactは、現在操作しているデータベースのMongoDB CRUD 操作を ブロックしません。

以前は、 compactはMongoDB CRUD 操作を含む操作対象データベースのすべての操作をブロックしていたため、スケジュールされたメンテナンス期間中にのみ使用するのが適切でした。

force オプション

MongoDB 以降、 フラグにより レプリカセット4.4 forcecompact内の プライマリ で が強制的に実行されます。

以前は、 オプションにより、 に設定すると レプリカセット compact内のforce プライマリtrue で の実行が有効になり、 に設定するとプライマリで実行するとエラーが返されましたfalse 。

Tip

以下も参照してください。

compact

mongod --repair 動作の変化

MongoDB 4.4以降、 mongod --repairは次のすべてのインデックスを再構築します。

  • コレクション データと 1 つ以上のインデックス間で不整合があるコレクション。

  • サルベージおよび変更されたコレクション。

MongoDB の以前のバージョンでは、 mongod --repairオプションによってすべてのコレクションのすべてのインデックスが再構築されていました。

serverStatus 出力の変更

フィールド名の変更

serverStatusはflowControl.locksPerKiloOp flowControl.locksPerOpではなく を返します。

新しいフィールド

serverStatus には、出力に次の新しいフィールドが含まれます。

serverStatus シャーディング統計の出力の変更

shardingStatistics.numHostsTargeted は、CRUD 操作と集計コマンドの対象となるシャードの数を報告します。 関連する検索、挿入、アップデート、削除、または集計のメトリクスが、クラスターに対する各操作ごとに増加します。

replSetGetStatus 出力の変更

replSetGetStatus により、次の新しいフィールドが返されます。

db.auth() はパスワードの入力を要求できます

MongoDB 4.4以降では、パスワードまたは<password>のpasswordPrompt()メソッドを渡さない場合、 mongo shell メソッドdb.auth(<username>, <password>)はパスワードの入力を要求します。

ビューでの ソートのサポート$natural

ビューに対して 操作を実行する場合に$natural find並べ替えを指定できます 。

診断バックトレース生成のサポート

Linux で実行されている MongoDB インスタンスの場合:

  • mongod プロセスと mongos プロセスが SIGUSR2シグナルを受信すると、バックトレースの詳細が各プロセス スレッドのログに追加されます。

  • バックトレースの詳細では、プロセスの関数呼び出しが表示されます。必要に応じて診断に使用したり、 MongoDB サポートに提供したりできます。

バックトレース機能はこれらのアーキテクチャで利用できます。

  • x86_64

  • arm64 （ MongoDB 5.0.10以降 ）

詳細については、「バックトレースの生成 」を参照してください。

コンテナを認識する FTDC レポート作成

MongoDB 4.4以降、 FTDCが、ホスト オペレーティング システムではなくコンテナの観点から、コンテナ内で実行されているmongodの使用率データを報告するようになりました。 詳細については、「フルタイム診断データ取得 」を参照してください。

ulimit起動時の警告を更新しました

MongoDB 4.4以降、オープン ファイル数にプラットフォームで設定されたulimitの値が64000未満の場合、 mongodは起動警告をログに記録します。 以前は、この値が1000未満の場合にのみ警告がログに記録されていました。 詳細については、「推奨されるulimit設定」を参照してください。

replanReason新しい データベースプロファイラーの出力フィールド

MongoDB4.4 は、 データベースプロファイラーの出力 とreplanReason 診断ログ メッセージ に フィールドを追加します。replanReasonフィールドには、クエリ システムがキャッシュされたプランをエビクションした理由が含まれます。

dbStats とcollStats の出力

dbStatsコマンドとそのmongo shellヘルパーdb.stats()は次を返します。

collStatsコマンド、そのmongo shellヘルパーdb.collection.stats() 、および$collStats集計ステージは次を返します。

追加のデータベースコマンドで使用できるヒント

MongoDB 4.4以降、次のデータベースコマンドでは、使用するインデックスを指定するためにhint引数を受け入れられます。

次を参照してください。

での JavaScript 実行 mongos

MongoDB 4.4以降、 MongoDB では、 mongosインスタンスで JavaScript の実行が許可されています。 mongosインスタンスで JavaScript の実行を無効にするには、次の手順に従います。

MongoDB の以前のバージョンでは、 mongosインスタンスで JavaScript の実行は許可されません。

グローバルのデフォルトの読み取り保証および書込み保証

注意

FeatureCompatibilityVersion 4.4 以上が必要です。

グローバルのデフォルトの読み取りおよび書込み保証を構成するには、レプリカセットまたはシャーディングされたクラスター内の各 は、 featureCompatibilityVersion を少なくともmongod に設定する 必要 があります。4.4

MongoDB 4.4以降、レプリカセットとシャーディングされたクラスターは、読み取り保証と書込み保証のグローバルなデフォルト設定の構成をサポートしています。 特定の読み取り保証または書込み保証が明示的に指定されていないクライアントは、対応するグローバルデフォルト設定を継承します。

デフォルトのグローバルデフォルト読み取りまたは書込み保証を設定するために、MongoDB はsetDefaultRWConcern管理コマンドを追加します。 レプリカセットの場合は、プライマリノードに対して コマンドを発行します。 シャーディングされたクラスターの場合は、 mongosからコマンドを発行します。

グローバルのデフォルトの読み取りまたは書込み保証 (write concern) 設定を取得するには、MongoDB はgetDefaultRWConcern管理コマンドを追加します。

読み取り保証 (read concern) の出所

MongoDB 4.4以降、読み取り保証 (read concern) オブジェクトには、読み取り保証 (read concern) が発生した場所を示すprovenanceフィールドが含まれる場合があります。

次の表は、読み取り保証 (read concern) の provenance に指定可能な値とその意味を示しています。

出所
説明
clientSupplied
読み取り保証 (read concern) がアプリケーションで指定されました。
customDefault
読み取り保証 (read concern) は、カスタム定義されたデフォルト値に基づきます。setDefaultRWConcern を参照してください。
implicitDefault
他の読み取り保証 (read concern) が一切指定されていない状態で、読み取り保証 (read concern) がサーバーから発生しました。

読み取り操作がログまたはプロファイリングされる場合、操作エントリには 読み取り保証オブジェクト（ provenanceフィールドを含む）が含まれます。

MongoDB では、サーバーへのリクエストでprovenanceフィールドを指定することは推奨されません。 このフィールドは、診断目的でのみ使用してください。

書込み保証 (write concern) の出所

MongoDB 4.4以降、書込み保証 (write concern) オブジェクトには、書込み保証 (write concern) が発生した場所を示すprovenanceフィールドが含まれる場合があります。

次の表は、可能な書込み保証 (write concern) provenance の値とその重要性を示しています。

出所
説明
clientSupplied
書き込み保証（write concern）がアプリケーションで指定されました。
customDefault
書込み保証 (write concern) は、カスタム定義されたデフォルト値に基づきます。setDefaultRWConcern を参照してください。
getLastErrorDefaults
書込み保証 (write concern) は、レプリカセットの settings.getLastErrorDefaults のフィールドに基づきます。
implicitDefault
他の書き込み保証（write concern）が一切指定されていない状態で、サーバーから発生した書き込み保証。

書込み操作がログまたはプロファイリングされる場合、操作エントリには書込み保証オブジェクト（ provenanceフィールドを含む）が含まれます。

MongoDB では、サーバーへのリクエストでprovenanceフィールドを指定することは推奨されません。 このフィールドは、診断目的でのみ使用してください。

currentOp 出力

の新しい KMIP 接続パラメーター mongod

MongoDB 4.4 Enterprise では、Kerberos 認証の一環として KMIP サーバーへの初期接続を強化するための 2 つの新しい構成設定が導入されています。

接続の再試行

KMIP サーバーに対して失敗した初期接続をmongodが再試行する回数を制御するには:

接続タイムアウト

中断または再試行する前に、KMIP サーバーからの初期応答を待つ際のタイムアウトをミリ秒単位で制御するには、次の手順に従います。

これらの設定は MongoDB Enterprise でのみ使用できます。

の新しいスタートアップ オプション mongod

の新しいprocessUmask スタートアップmongod honorSystemUmaskfalseオプションにより、 umesk を通じて権限を設定できます グループと他のユーザーでは、 が に設定されている場合。

mapReduce オプションを無視verbose

MongoDB 4.4以降、 mapReduceコマンドとdb.collection.mapReduce() shell メソッドは冗長オプションを無視します。

explain サポート mapReduce

MongoDB 4.4以降では、 explainコマンドまたはdb.collection.explain() shell メソッドを使用して、 mapReduceまたはdb.collection.mapReduce()の結果をプレビューできます。

explainの結果への改善

バージョン 4.4 以降

  • シャーディングされたクラスターで実行されたコマンドの mongos説明結果serverInfo には、各シャードに対して返される オブジェクトに加えて、 の最上位の serverInfo オブジェクトが含まれます。これは、バージョン 4.2.2、4.0.14、および 3.6.16 でも利用できます。

  • が の場合、optimizedPipeline Explain 結果 には serverInfotrue オブジェクトが含まれます。MongoDB の以前のバージョンでは、 optimizedPipelineがtrueの場合、 explainの結果にserverInfoオブジェクトが含まれないことがあります。 これは、バージョン 4.2.2、4.0.14、および 3.6.16 でも利用できます。

  • 集計の 説明結果 には、nReturned モードと executionTimeMillisEstimateモードで メソッドを実行する場合、各 パイプライン ステージdb.collection.explain().aggregate() executionStatsallPlansExecutionの } フィールドと フィールドが含まれます。

Tip

以下も参照してください。

結果を説明します。

comment すべてのデータベースコマンドで使用できるオプション

MongoDB 4.4以降、すべてのデータベースコマンドは次の方法でcommentフィールドの指定をサポートしています。

例

db.runCommand( { <command> , "comment" : <any BSON type> })

設定すると、コメントは以下の場所に コマンドの記録と合わせて表示されます。

コメントは有効なBSON オブジェクト（string, integer, array など）である必要があります。

位置指定$ 演算子の改善

MongoDB 4.4以降では、位置指定の$演算子を使用すると、クエリ ドキュメントとプロジェクション ドキュメントの間で異なる配列フィールドを指定できます。

たとえば、次のドキュメントを コレクションに挿入するとします。

db.foo.insertOne( { a: [ "one", "two", "three" ], b: [ 1, 2, 3 ] } )

MongoDB 4.4以降では、次のクエリを使用して、フィールドaに指定されたクエリに一致するドキュメントの、フィールドbから最初の要素のみを投影できます。

db.foo.findOne( { a: "one" }, { "b.$": 1 } )

重要

期待どおりの動作を実現するには、クエリドキュメントとプロジェクションドキュメントで使用される配列が同じ長さである必要があります。 配列の長さが異なる場合、特定のシナリオでは操作でエラーが発生する可能性があります。

MongoDB の以前のバージョンでは、制限されている配列フィールドはクエリ ドキュメントに表示される必要があるため、この操作は失敗します。

互換性に影響する変更

一部の変更は互換性に影響を与える可能性があり、ユーザーのアクションが必要になる場合があります。 互換性の変更の詳細リストについては、「 MongoDB 4.4の互換性の変更 」を参照してください。

アップグレード手順

重要

機能の互換性バージョン

4.2配置からアップグレードするには、 4.2配置でfeatureCompatibilityVersionを4.2に設定する必要があります。 バージョンを確認するには、以下を参照してください。

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

featureCompatibilityVersionの検証と設定の具体的な詳細およびアップグレードに関するその他の前提条件や考慮事項については、個々のアップグレード手順を参照してください。

4.4へのアップグレードに関するガイダンスが必要な場合は、 MongoDB プロフェッショナル サービスがメジャー バージョン アップグレード サポートを提供して、MongoDB アプリケーションを中断することなくスムーズに移行できるようにします。

ダウングレードの検討事項

MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。

たとえば、 4.4シリーズの配置を4.2シリーズにダウングレードできます。 ただし、 4.2シリーズの配置から4.0シリーズの配置へのさらなるダウングレードはサポートされていません。

ダウンロード

MongoDB 4. 4をダウンロードするには、MongoDB ダウンロードセンターにアクセスします。

Tip

以下も参照してください。

既知の問題点

バージョン
問題
ステータス
4.4.0
SERVER-45042 : Community と Enterprise の両方の MongoDB Server インストール MSI には、 MongoDB Database Tools のバイナリが含まれなくなりました。詳細については、「ツールの変更 」を参照してください。
未解決
4.4.0
SERVER-49694 : シャーディングされたクラスターでは、nearest 読み取りまたは ヘッジされた読み取り は、ほぼシャード レプリカにルーティングされない可能性があります。
4.4.1で修正済み
4.4.0
WT-6623 : リカバリファイルスキャンの接続レベルファイル ID を設定します。
4.4.1で修正済み

問題を報告する

問題を報告するには、 https://github.com/mongodb/mongo/wiki/Submit-Bug-Reports を参照してください。MongoDB サーバーまたは関連するプロジェクトのいずれかに対して JIRA チケットを提出する方法については、 を参照してください。

戻る

変更履歴