MongoDB 8.0 のリリースノート
このページでは、 MongoDB 8.0で導入された変更点と新機能について説明します。
MongoDB 8.0はメジャー リリースであるため、 MongoDB Atlasとオンプレミスの配置の両方でサポートされます。 MongoDB 8.0にはMongoDB Rapid Releases 7.1 、 7.2 、 7.3で導入された変更が含まれています。 このページでは、これらの Rapid Release とMongoDB 8で導入された変更について説明します。 0 。
メジャー リリースと Rapid Release の違いの詳細については、「 MongoDB のバージョン管理 」を参照してください。
パッチ リリース
8.0.1 - 10 月9 、 2024
修正された問題:
SERVER-76883 外部ソースユーザーの「ロールが存在しません」ログのチャットボットを削減
SERVER-82221 listCollections と listIndexes にはコミット保留中の名前空間が含まれます
SERVER-94635 セッション更新パラメーターを構成可能にする
SERVER- 挿入につながるアップサート95244 ステートメントが、クライアントがシャードに直接接続している場合、tassert によって失敗する可能性があります9146500
WT-13409 __txn_checkpoint の 1 回の再試行は処理されない
8.0.0 - 10 月2 、 2024
このページの残りの部分では、 MongoDB 8.0で導入された変更点と新機能について説明します。
プラットフォーム サポートの更新
MongoDB 8.0以降、新しい MongoDB Server バージョン(メジャーとマイナー)は、OS ベンダーによって定義される最小のオペレーティング システム(OS)のマイナー バージョンをサポートします。 OS マイナー バージョンが OS ベンダーによってサポートされなくなると、MongoDB は MongoDB Server を更新して次の OS マイナー バージョンをサポートします。 詳細については、「 MongoDB Platform サポートの改善」を参照してください。
MongoDB 8.0は、最小の OS マイナー バージョンをサポートしています。
Red Hat Enterprise Linux 8.8
Red Hat Enterprise Linux 9.3
SUSE Linux Enterprise Server 15 SP 5
Amazon Linux 2023バージョン2023.3
ログ記録
MongoDB 8.0以降では、操作の合計レイテンシではなく、MongoDB がその操作に費やした時間に基づいて、低速操作をログに記録するようにデータベースプロファイラーを構成できます。 つまり、ロックの待機やフロー制御などの要因は、操作が 低速操作しきい値 を超えるかどうかに影響しません。
この変更により、ログ記録とクエリ分析が次の改善が行われます。
低速クエリは、MongoDB がクエリの処理に費やす時間に基づいて、より正確にログに記録されます。
クエリプロファイラー、Performance Advisor 、検索クエリ テレメトリなどのクエリ分析ツールでは、
workingMillis
ではなく {0durationMillis
に基づいて低速操作が報告されます。この変更により、問題のあるクエリのより正確なビューが提供されます。低速クエリ ログには、実行チケットのキューに入れられた時間のメトリクスが含まれます(
queues.execution.totalTimeQueuedMicros
。 このメトリクスは、操作が完了までにかかる時間や操作の開始待機に費やされているかを特定するのに役立ちます。
詳細については、db.setProfilingLevel()
を参照してください。
Database Profiler
データベースプロファイラーにフィルターを指定すると、新しいworkingMillis
メトリクスに基づいて操作をログに記録できます。 workingMillis
とdurationMillis
の両方に基づいて操作をログに記録し、各メトリクスを異なるしきい値に設定できます。
集計
BinData 変換
MongoDB 8.0以降では、 $convert
演算子を使用して次の変換を実行できます。
String values to binData values
binData 値から string 値へ
MongoDB 8.0には新しいヘルパー式$toUUID
} も含まれています。これは、string を UUID値に変換するための簡素化された構文を提供します。
$queryStats
MongoDB 7.1以降、 $queryStats
ステージは記録されたクエリの統計を返します。
変更ストリームの改善
MongoDB 8.0以降、 $queryStats
は変更ストリームの追跡とレポート作成メトリクスを改善します。 詳細については、「 $queryStats Change Streamsの動作 」を参照してください。
$rank と $denseRank の動作
MongoDB 8.0以降、 $denseRank
および$rank
sortBy操作のnull
と欠落しているフィールド値は、ランキングを計算するときに同じように扱われます。 この変更により、 denseRank
とrank
の動作が$sort
と一貫性が生じます。
セキュリティ
Queryable Encryption 範囲クエリ
MongoDB 8.0以降、 Queryable Encryptionは、 $lt
、 $lte
、 $gt
、および$gte
演算子を使用した、暗号化されたフィールドに対する範囲クエリをサポートしています。 詳細については、「 Queryable Encryption がサポートする操作 」を参照してください。 暗号化されたフィールドで範囲クエリを有効にするには、「暗号化スキーマの作成 」を参照してください。
ログ メッセージの OCSF スキーマ
MongoDB 8.0以降では、監査ログ メッセージにOCSFスキーマを指定できます。 OCSF スキーマは、 ログ プロセッサ と互換性のある標準化された形式でログを提供します。
ログ メッセージに使用されるスキーマを設定するには、 auditLog.schema
構成ファイル オプションを使用します。
OCSF 形式のログ メッセージの例については、「 OCSF スキーマ監査メッセージ 」を参照してください。
Ingress キュー
MongoDB 8.0では、Ingress 認証制御用の新しいキューが導入されています。 ネットワークからデータベースへのエントリがあるのを待つ操作は、Ingress キューに入力されます。 デフォルトでは、キューは制限されていません。つまり、MongoDB ではすべての操作がこのステージでキューに入れられることなく実行できます。 キューの最大値を特定の値に設定すると、実行中の操作の数が指定された制限に達した場合、このステージで操作をキューに含めることができます。
シャーディング
MongoDB 8.0以降では、コレクションのシャーディングを解除し、シャーディングされたクラスター上のシャード間でシャーディングされていないコレクションをシャード間で移動できます。
コレクションの移動
MongoDB 8.0以降では、 moveCollection
コマンドを使用して、シャーディングされていないコレクションを別のシャードに移動できます。
詳細については、「移動可能なコレクション 」を参照してください。 開始するには、「コレクションの移動 」を参照してください。
Change Streamsを持つコレクションの移動
MongoDB8.0 以降、movePrimary
は 変更ストリーム を持つコレクションを 無効化 しません。コレクションが新しいシャードに移動された後も、変更ストリームはコレクションからイベントを引き続き読み取ります。
詳細については、「 Change Streamsを持つコレクションの移動 」を参照してください。
コレクションのシャーディングの解除
MongoDB 8.0以降では、 unshardCollection
コマンドまたはsh.unshardCollection()
メソッドを使用して、既存のシャーディングされたコレクションのシャーディングを解除できます。 この操作は、 コレクション内のすべてのドキュメントを、指定されたシャードまたはデータ量が最も少ないシャードに移動します。
詳細については、「シャーディングされていないコレクション 」を参照してください。 開始するには、「コレクションのシャーディングの解除 」を参照してください。
コンフィギュレーションシャード
MongoDB 8.0以降では、通常の シャーディングされたシャーディングされたクラスターのメタデータデータ に加えて、アプリケーションデータを保存するようにコンフィギュレーションコンフィギュレーションサーバーを構成できます。 コンフィギュレーションコンフィギュレーションサーバーとシャードサーバーの両方の機能を提供するmongod
ノードは、コンフィギュレーションシャードと呼ばれます。 シャードサーバー機能を持たないスタンドアロン--configsvr
として実行されるmongod
ノードは専用コンフィギュレーションサーバーと呼ばれコンフィギュレーションサーバー。
専用のコンフィギュレーションコンフィギュレーションサーバーをコンフィギュレーションシャードとして実行するように構成するには、 transitionFromDedicatedConfigServer
コマンドを実行します。
コンフィギュレーションシャードを専用のコンフィギュレーションコンフィギュレーションサーバーとして実行するように構成するには、 transitionToDedicatedConfigServer
コマンドを実行します。
詳細については、「コンフィギュレーションシャード」を参照してください。開始するには、「コンフィギュレーションシャードを使用してシャーディングされたシャードクラスタを開始する 」を参照してください。コンフィギュレーションシャードを使用してレプリカセットをシャーディングされたシャーディングされたクラスターに変換するには、「埋め込みコンフィギュレーションサーバーを使用してシャーディングされたシャードクラスタにレプリカセットを変換 」を参照してください。
新しいデータベースコマンド
新しい mongosh メソッド
serverStatus メトリクス
MongoDB 8.0以降、 serverStatus
の出力には次の新しいshardingStatistics
フィールドが含まれます。
shardingStatistics.countTransitionToDedicatedConfigServerStarted
shardingStatistics.countTransitionToDedicatedConfigServerCompleted
shardingStatistics.countTransitionFromDedicatedConfigServerCompleted
MongoDB 7.1には、チャンク移行に関する次の新しいシャーディング統計が含まれています。
シャードあたりのデフォルトのチャンク
MongoDB 7.2 以降では、空のコレクションをハッシュされたシャードキーでシャードすると、 操作によってデフォルトでシャードごとに 1 つのチャンクが作成されます。 Previously, the operation created two chunks by default.
directShardOperations ロール
MongoDB 8.0以降では、 directShardOperations
ロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。
警告
directShardOperations
ロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperations
ロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperations
ロールの使用を停止します。
シャーディングされたクラスターで有効になっているカーソルをすべて使用する
MongoDB7.1 以降、クライアントのmongos
getMore リクエストで exhaustAllowed フラグが設定されている場合、 はエグゼキューションカーソルをサポートします。これにより、クライアントが 1 つのリクエストに対してデータベース サーバーから複数の応答を受け取った場合に、シャーディングされたクラスターでのクエリのパフォーマンスが向上します。
mongos ポート範囲
MongoDB 7.1以降、 mongos
は [ 0 、 65535 ] から--port
値を受け入れます。 詳しくは、 --port
を参照してください。
部分的なシャードキーを含むクエリ
MongoDB 7.1以降では、 findAndModify
とdeleteOne()
は部分的なシャードキーを使用してシャーディングされたコレクションをクエリできます。
再シャーディングの改善
MongoDB 7.2 では、コレクションの再シャーディング操作のパフォーマンスが大幅に向上し、操作の実行にかかる時間が大幅に短縮されます。
さらに、アプリケーションとクラスターが 必要な要件と制限を満たしている場合は、 reshardCollection
コマンドを使用して同じキーでコレクションを再シャーディングし、コレクションを再配布できます。これは、別の範囲移行手順 よりもはるかに高速です。
次のオプションが コマンドに追加されます。
フィールド | 説明 |
---|---|
forceRedistribution | 同じキーの再シャーディング を有効にします。 |
例については、「新しいシャードへのデータの再配布 」を参照してください。
シャーディングされたクラスターの自己管理型バックアップ
MongoDB 7.1以降では、 fsync
} コマンドとfsyncUnlock
コマンドは、シャーディングされたクラスターで fsync 操作を実行できます。
lock
フィールドをtrue
に設定してmongos
で実行すると、 fsync
コマンドはストレージ層からディスクに書き込みをフラッシュし、各シャードをロックして追加の書込みを防ぎます。 その後、 fsyncUnlock
コマンドを使用してクラスターのロックを解除できます。
シャーディングされたコレクションでの UpdateOne のアップサート動作
MongoDB7.1 以降、シャーディングされたコレクションで とともにupdateOne()
upsert: true
{ を使用する場合、フィルターに完全なシャードキーを含める必要はあり ません 。
シャーディングされたコレクションを使用したトランザクションの $lookup ステージ
MongoDB 8.0以降では、シャーディングされたコレクションをターゲットにしながら、トランザクション内で$lookup
ステージを使用できます。
複製
過半数の書込み保証(write concern)
MongoDB 8.0以降、 "majority"
書込み保証 ( 書込み保証 (write concern) ) を使用する書込み操作は、レプリカセットノードの過半数が変更のoplogエントリを書込んだときに確認応答を返します。 これにより、 "majority"
書き込みのパフォーマンスが向上します。 以前のリリースでは、これらの操作はレプリカセットの過半数が変更を適用した後、待機して確認応答を返していました。
アプリケーションが{ w: "majority" }
書込み (write)操作(因果整合性のあるセッションなし)からの確認応答を受信した後すぐにセカンダリから読み取る場合、クエリは書込み (write) からの変更を含まない結果を返すことがあります。
新しい replSetGetStatus メトリクス
MongoDB 8.0以降では、 replSetGetStatus
コマンドを使用すると次のメトリクスが利用できます。
oplogバッファ
MongoDB 8.0以降、セカンダリは各バッチの oplog エントリを並列に書込み、適用します。 書込みスレッドはプライマリから新しいエントリを読み取り、ローカル oplog に書込みます。 アプライアンス スレッドはこれらの変更をローカル データベースに非同期に適用します。 この変更により、セカンダリのレプリケーション スループットが向上します。
これにより、 metrics.repl.buffer
に重大な変更が導入され、1 つのバッファではなく 2 つのバッファに対してメトリクスが提供されるようになりました。
MongoDB 8.0では、次のサーバー ステータス メトリクスが非推奨になります。
MongoDB 8.0は、次のサーバー ステータス メトリクスを追加します。
アップグレードされた TCMalloc
MongoDB 8.0以降、 MongoDBは、メモリのフラグメント化を減らし、高負荷のワークロードに対するデータベースの回復力を高めます。
新しい TCMalloc バージョンは、Transparent Huge Page の以前の本番環境の推奨事項に直接影響します。 詳細については、「自己管理型配置の TCMalloc パフォーマンスの最適化 」を参照してください。
serverStatus メトリクス
MongoDB 8.0以降、次の新しいserverStatus
メトリクスではtcmalloc
の使用に関する情報が報告されます。
一般的な変更点
シャットダウン パフォーマンス
MongoDB 8.0以降では、 Bulk.insert()
およびデータ取り込みワークロードのパフォーマンスが向上する可能性があります。 ただし、これらのワークロードを実行した後すぐに MongoDB をシャットダウンすると、余計なデータがディスクにフラッシュされるため、時間がかかる可能性があります。
アプリケーション データをコンフィギュレーションシャードに保存
MongoDB 8.0以降では、通常のシャーディングされたクラスターのメタデータに加えて、アプリケーション データを保存するように コンフィギュレーションサーバー を構成できます。 また、コンフィギュレーションサーバーはコンフィギュレーションシャードと呼ばれます。 詳細については、「コンフィギュレーションシャード 」を参照してください。
圧縮の改善
MongoDB 7.3以降、 compact
コマンドには、圧縮を続行するために回復可能な必要があるストレージ領域の最小量(メガバイト単位)が含まれる新しいfreeSpaceTargetMB
オプションが含まれています。
バックグラウンド圧縮
MongoDB 8.0以降では、新しいautoCompact
コマンドを使用してバックグラウンド圧縮を実行できます。 有効にすると、サーバーは各コレクションとインデックス内の空き領域を指定されたfreeSpaceTargetMB
値より下に維持しようとします。
ryRun オプション
有効にすると、 compact
コマンドは、対象コレクションから圧縮によって再利用できる領域の推定値(バイト単位)を返します。 dryRun
をtrue
に設定してcompact
を実行すると、MongoDB は推定値のみを返し、圧縮は実行しません。
同時 DDL 操作
MongoDB 7.1以降では、同じデータベースから異なるコレクションを対象とする複数のDDL 操作を実行する場合、MongoDB はそれらの操作を同時に実行します。
この変更により、 serverStatus
locks
フィールドとcurrentOp.locks
出力に 2 つの新しいタイプが追加されます。
DDLDatabase
DDLCollection
mongos 集計クエリでのデータベース検証
MongoDB 7.2 以降、 mongos配置で存在しないデータベースを使用しようとする集計パイプライン クエリでは、検証エラーが返されます。
以前のバージョンでは、これらの集計クエリは空のカーソルを返していました。
DDL 操作
MongoDB 8.0では、クラスターが DDL 操作( reshardCollection
などのコレクションを変更する操作)を実行しているときにシャードを追加または削除すると、シャードを追加または削除する操作は、同時 DDL 操作が完了した後にのみ実行されます。
パイプラインのサイズ制限を超えるためのエラー コード
MongoDB 7.1以降では、パイプラインが パイプライン ステージの制限 を超えると、集計コマンドによってエラーがスローされるようになります。 詳細については、「ステージ数の制限 」を参照してください。
getField フィールドはすべての文字列をサポート
MongoDB 7.2 以降では、 演算子の 入力に、string に変換される任意の有効な 式field
$getField
を指定できます。以前のバージョンでは、field
はstring定数のみを受け入れていました。
インデックス構築の改善
MongoDB 7.1 以降では、インデックス構築でのエラー報告が高速化され、障害回復力が高まります。 新しいindexBuildMinAvailableDiskSpaceMB
パラメータを使用して、インデックスビルドに必要な最小ディスク容量を設定することもできます。これにより、ディスク容量が低すぎる場合はインデックスビルドが停止します。
次の新しいインデックス構築メトリクスが追加されました。
詳細については、「インデックス ビルド 」を参照してください。
新しいパラメーター
auditConfig Parameter
MongoDB7.1 は、auditConfig
とmongod
サーバーmongos
インスタンスからの監査構成に関する情報を含む クラスター パラメータを追加します。
defaultMaxTimeMS パラメーター
MongoDB 8.0以降では、 defaultMaxTimeMS
クラスター パラメータを使用して、個々の読み取り操作が完了するデフォルトの時間制限を指定できます。
indexBuildMinAvailableDiskSpaceMB Parameter
MongoDB 7.1では、インデックス構築に必要な最小ディスク容量を設定できるindexBuildMinAvailableDiskSpaceMB
パラメータが追加されています。
tcmallocEnableBackgroundThread Parameter
MongoDB 8.0以降では、 tcmallocEnableBackgroundThread
はデフォルトで有効になっています。 これにより、MongoDB は定期的にメモリを解放してオペレーティング システムに戻すことができます。
新しい一括書込みコマンド
MongoDB 8.0以降では、新しいbulkWrite
コマンドを使用して、1 回のリクエストで複数のコレクションに対して多くの挿入、アップデート、削除操作を実行できます。 既存のdb.collection.bulkWrite()
メソッドでは、1 回のリクエストで 1 つのコレクションのみを変更できます。
新しいクエリシェイプとクエリ設定
MongoDB 8.0では新しいクエリシェイプが導入されています。 既存のクエリシェイプの名前が、プラン キャッシュ クエリシェイプに変更されます。
MongoDB 8.0以降では、新しいクエリシェイプのクエリ設定を追加できます。 クエリオプティマイザは、クエリプランニング中にクエリ設定を追加の入力として使用します。これは、一致するクエリシェイプを持つクエリを実行するために選択されたプランに影響します。
クエリ設定は、インデックス フィルターと比較して機能が向上しています。 インデックス フィルターも MongoDB 8.0以降は非推奨になっており、それらの使用は避けてください。
クエリ設定を追加するには、
setQuerySettings
コマンドを使用します。クエリ設定を削除するには、
removeQuerySettings
コマンドを使用します。クエリ設定を取得するには、集計パイプラインの
$querySettings
ステージを使用します。クエリシェイプをブロックするには、「操作拒否フィルター 」を参照してください。
MongoDB 8.0以降では、次の出力にqueryShapeHash
が含まれます。
explain
{ フィールドの コマンドexplain.queryShapeHash
MongoDB 8.0以降、既存のqueryHash
フィールドの名前がplanCacheShapeHash
に変更されます。 以前のバージョンの MongoDB を使用している場合は、 planCacheShapeHash
ではなくqueryHash
が表示されます。
Parameter Filtering
MongoDB 8.0以降、 getParameter
コマンドはsetAt
フィールドを受け入れます。 このフィールドを使用して、 allParameters: true
が返すドキュメントをフィルタリングして、スタートアップまたは実行時に設定できるパラメータのみを表示できます。
Cappedコレクションに関する 読み取り保証 (read concern)
MongoDB8.0 以降では、"snapshot"
Capped コレクションで読み取り保証 を使用できます。
serverStatus 出力の変更
MongoDB 7.1以降では、 serverStatus
コマンドの出力に次の新しいメトリクスが含まれています。
MongoDB 7.2以降では、 serverStatus
コマンドの出力に次の新しいメトリクスが含まれています。
MongoDB 7.3以降では、 serverStatus
コマンドの出力に次の新しいメトリクスが含まれています。
MongoDB 8.0以降では、 serverStatus
コマンドの出力に次の新しいメトリクスが含まれています。
updateOne のソート サポート
MongoDB 8.0以降、 updateOne()
メソッドはsort
オプションをサポートしています。 これは、MongoDB が更新を受信するドキュメントを選択する前にドキュメントを順序付けする方法を制御します。
以前のリリースでは、 findAndModify()
メソッドとfindOneAndUpdate()
メソッドを使用して、ユーザー指定のソート順序で最初のドキュメントを更新していました。 再試行可能な書込みをサポートするには、これらのメソッドがドキュメント全体を各ノードの特別なサイド コレクションにコピーする必要があります。これは、新しいsort
オプションを備えたupdateOne()
メソッドよりもコストのかかる操作です。
個別のコマンドのクエリ インデックス ヒントの指定
MongoDB 7.1以降では、 distinct
コマンドでhint
フィールドが使用でき、クエリのインデックスを指定できます。
TTL Indexes
MongoDB7.1 以降では、 Cappedコレクション に TTL インデックス を作成できます。
クエリ計画と実行
ブロック プロセシング
バージョン8.0以降、 MongoDB は、ブロック処理を使用して特定の時系列クエリを実行する場合があります。 このパフォーマンス向上により、クエリは個々の値ではなく、データの「ブロック」単位で処理されます。 ブロック処理 により、時系列コレクションを操作する際のクエリ実行速度とスループットが向上します。
時系列クエリがブロック処理を使用しているかどうかを確認するには、説明プランの出力のexplain.queryPlanner.winningPlan.slotBasedPlan.stages
フィールドを確認します。
詳しくは、「ブロック処理 」を参照してください。
Expressクエリ ステージ
MongoDB 8.0以降、限定的なクエリのセット( _id
等価一致を含む)は、通常のクエリ計画と実行をスキップします。 代わりに、これらのクエリでは、次のいずれかのプラン ステージで構成される最適化されたインデックス スキャン プランが使用されます。
EXPRESS_CLUSTERED_IXSCAN
EXPRESS_DELETE
EXPRESS_IXSCAN
EXPRESS_UPDATE
クエリプランの詳細についてはexplain の結果 を参照してください。
拒否されたクエリプランの出力
MongoDB 8.0以降、拒否されたクエリプランにはクエリのfind
部分のみが含まれます。 以前のバージョンでは、拒否されたプランには$group
のような 集計ステージ が含まれることがあります。 これらの集計ステージは勝利プランを選択するためにクエリ プランナーによって使用されることはありません。そのため、 rejectedPlans
フィールドには、勝利プランを選択するために使用されたクエリの部分のみが含まれます。
この変更により、拒否されたプランのexecutionStats
もゼロ以外になります。 その結果、拒否されたプランによって検査されたドキュメントやキーの数などの統計が表示されるようになりました。
拒否されたクエリプランの詳細については、 explain.queryPlanner.rejectedPlans
をご覧ください。
バッチ複数ドキュメント挿入操作
MongoDB 8.0以降、マルチドキュメントトランザクションの挿入操作では、個々のoplog
エントリが生成されなくなりました。 代わりに、複数ドキュメントの挿入は 1 つのエントリとしてバッチ化されます。 各ドキュメントの変更ストリームinsert
イベントには同じclusterTime
があります。
この変更により、複数ドキュメント挿入操作のパフォーマンスが向上し、複数のoplog
書込みによって発生する可能性のあるレプリケーションラグがなくなります。
OIDC IdP は発行者を共有できます
MongoDB 8.0以降では、複数の ID プロバイダー(IDP)が定義されている場合、 audience
値が各発行者に対して一意である限り、 oidcIdentityProviders
パラメータは重複するissuer
値を受け入れます。 これは、バージョン7.3および7でも利用できます。 0 。
サブパイプラインの名前空間
MongoDB 以降では、8.0 $lookup
と$unionWith
内のサブパイプラインの名前空間が検証され、from
coll
フィールドと フィールドが正しく使用されるようになりました。
詳細については、「 $lookup サブパイプライン 」と「 $unionWith サブパイプライン 」を参照してください。
クエリプランナーの最適化時間
explain()
メソッドがクエリ プランナーの最適化時間に関する情報を返すようになりました。 queryPlanner.optimizationTimeMillis
ステータスは、クエリ プランナーが最適化に費やした時間をミリ秒単位で表示します。
既知の問題点
このセクションでは、MongoDB 8.0の既知の問題とその解決ステータスについて説明します。
バージョン | 問題 | ステータス |
---|---|---|
8.0.0 | SERVER-94741 : $or 最上位の$and 句(暗黙的な$and 句を含む)を含む クエリで複数のインデックスが使用されている場合、クエリは新しいインデックス作成中に最も効率的なインデックスが誤って考慮事項から削除されたため、クエリは効率の低いインデックスを使用する可能性があります。 MongoDB のクエリ プラン作成の「インデックス8 0プルーニング」フェーズ。 。 | 未解決。 8.0.1SERVER-94738 でインデックスのプルーニング機能を無効にすることで、 で軽減される予定です。 |
8.0.0 | SERVER-95244 : 次のすべてが当てはまる場合、単一シャードのシャーディングされたクラスターでアップサート操作が失敗する可能性が高くなります。
シャーディングされたシャーディングされたクラスターに移行するための推奨プロセスでは、クライアントをシフトして | この問題は8.0.1で修正される予定です。 |
アップグレード手順
重要
機能の互換性バージョン
MongoDB8.0 7.0配置から MongoDB にアップグレードするには、7.0 featureCompatibilityVersion
配置で7.0
を に設定する必要があります。バージョンを確認するには、以下を参照してください。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
MongoDB 8.0にアップグレードするには、MongoDB 配置に固有のアップグレード手順を参照してください。
8.0 へのアップグレードに関するガイダンスが必要な場合は、MongoDB プロフェッショナル サービスがメジャー バージョン アップグレード サポートを提供して、MongoDB アプリケーションを中断することなくスムーズに移行できるようにします。詳細については、MongoDB コンサルティングを参照してください。
ダウンロード
MongoDB 8. 0 をダウンロードするには、MongoDB ダウンロードセンターにアクセスします。