このページでは、 MongoDB 9.0 で導入された、古いバージョンのMongoDBとの互換性に影響を与える可能性のある変更について説明します。
非推奨
非推奨 | 説明 |
|---|---|
| MongoDB 9.0 以降、 |
| MongoDB 9.0 の暗号化されたフィールドに対する部分文字列クエリの内部制限を上書きすることはできません。 |
集計
空のフィールド名 $group
MongoDB 9.0以降、$groupステージは、アキュムレータ式に空のフィールド名が含まれている場合にエラーを返します。詳細については、空のフィールド名の$group制限を参照してください。
allowPartialResults aggregate $queryStats Key
MongoDB 9.0以降、aggregateコマンドの$queryStatsキーには、オプションが明示的に設定されている場合にallowPartialResultsオプションが含まれるようになります。クエリ統計では、allowPartialResultsが省略されている場合、明示的にtrueに設定されている場合、または明示的にfalseに設定されている場合のリクエストを区別できます。
この追加により、allowPartialResults を設定する aggregate クエリの key および keyHash 直列化が変更されます。queryShapeHash は変更されていません。keyHash に一致するダウンストリームコンシューマーは、これらのクエリで異なる値を観測する可能性があります。
詳細については、「aggregateコマンドのクエリシェイプ」を参照してください。
一般的な変更点
インデックス付きフィールドがマルチキーになるとクエリが失敗する
MongoDB 9.0 以降では、インデックスが作成されたフィールドがマルチキーフィールドになり、そのフィールドを参照するクエリが実行されている場合、クエリが QueryKilledError で失敗する可能性があります。ドキュメントを挿入または更新してフィールドに配列値が含まれるようになると、インデックスが作成されたフィールドはマルチキーになります。
このエラーでクエリが失敗した場合は、挿入または更新操作が完了した後にクエリを再実行してください。
Change Streamsは選挙後に読み込み設定 (read preference)を強制する
MongoDB 9.0 以降、readPreference が primary または secondary に設定された状態で開かれた変更ストリームは、レプリカセットの選挙によってノードのロールが変更され、読み込み設定 (read preference) を満たさなくなった場合、getMore から再開可能なエラー InterruptedDueToReplStateChange (エラーコード 11602) を返します。以前のバージョンでは、カーソルは同じノードから結果を返し続けていました。
準拠したドライバーと mongos は、最後のレジュームトークンから自動的に再開します。手動の getMore ループと mongosh は、resumeAfter で再開する必要があります。詳細については、「変更ストリームの再開」を参照してください。
地理空間インデックスのキー抽出エラーコード
MongoDB 9.0以降、2dsphereインデックスのキー抽出に失敗すると、名前付きエラーコード510 (GeoKeyExtractionFailed)および511 (GeoKeyExtractionFailedTimeseries)が返されます。これらのコードは、通常の2dsphereインデックスの前アサーションコード16755および16756、時系列コレクションの183934および183493に代わるものです。アプリケーションが前のコードと一致する場合は、510および511と一致するように更新してください。
クロスデータベース間向けのより強固なコレクション ロック renameCollection
MongoDB 9.0 以降、レプリカセット上の異なるデータベース間でコレクションの名前を変更する場合、renameCollection コマンドはソースコレクションとターゲットコレクションに対して排他ロックを保持します。このロックは操作全体を通じて継続され、DDL操作および両方のコレクションへの書き込み (write) をブロックします。ほとんどの読み取り操作は ロックフリー読み取り を使用するため、ブロックされません。
以前のバージョンでは、renameCollectionが名前の変更を完了する前に、ソースコレクションのロックを解除していました。そのウィンドウの間にソースコレクションへの書き込み (write)が同時に発生すると、その書き込み (write)が失われる可能性があります。
この変更はレプリカセットにのみ影響します。シャーディングされたクラスターでは、名前変更の間、両方のコレクションがすでにロックされています。
サーバーサイドの JavaScript 日付操作では UTC が使用されます
MongoDB 9.0以降、サーバー側のJavaScriptはWebAssembly (WASM)ベースのエンジンで実行されます。このエンジンは、mongodホストのタイムゾーンに関係なく、ローカルのDate操作をUTCで評価します。以前のバージョンでは、これらの操作はホストのタイムゾーンに従っていました。この変更は、$function、$accumulator、$where、およびmapReduceで実行されるJavaScriptに影響します。
保存 (する)されたBSONの日付値は変更されません。Date.prototype.getTime()、Date.prototype.toISOString()、およびgetUTC*()メソッドなどのUTC操作も同様です。この違いは、ローカル時刻の操作に影響します。
Date.prototype.toString()Date.prototype.toTimeString()Date.prototype.getHours()およびその他のローカルゲッターローカル
Dateコンストラクターとセッター日付を暗黙的に文字列に変換する操作（比較演算子なしで呼び出される
Array.prototype.sort()を含む）
TZ=America/New_Yorkで実行されるmongodに対する以下の操作を検討してください。
db.events.insertOne( { name: "before-opening", occurredAt: ISODate("2024-01-15T13:30:00Z")} )
db.events.find( { $expr: { $function: { body: function(date) { return date.getHours() < 9; }, args: [ "$occurredAt" ], lang: "js" } }} )以前のバージョンでは、13:30 UTC はニューヨークでは 08:30 であるため、getHours() は 8 を返し、クエリはドキュメントと一致します。MongoDB 9.0 以降、getHours() は 13 を返し、クエリは一致しない。保存された日付はどちらのバージョンでも有効なままなので、操作は成功し、その違いはエラーとして報告されません。バイナリバージョンが混合して実行される配置では、同じJavaScriptに対しても異なる結果が返される可能性があります。
アップグレードの影響
MongoDB 9.0 にアップグレードする前に、$function、$accumulator、$where、および mapReduce コード内の JavaScript を検討してローカル Date の使用状況を確認し、mongod ホストのタイムゾーンに依存しないようにしてください。
名前付きタイムゾーンで日付を評価するには、JavaScriptの代わりに明示的なtimezone引数を持つ集計日付演算子を使用します。次のクエリは、すべてのバージョンで同じ結果を返します。
db.events.find( { $expr: { $lt: [ { $hour: { date: "$occurredAt", timezone: "America/New_York" } }, 9 ] }} )決定論的な比較や直列化が必要なJavaScriptの場合は、ローカルのDateメソッドや暗黙的なstring変換ではなく、getTime()、toISOString()、またはgetUTC*()メソッドを使用してください。ソートされた値に日付が含まれる可能性がある場合は、明示的な比較子をArray.prototype.sort()に渡します。
詳細については、「サーバーサイドJavaScript」を参照してください。
サーバーサイド JavaScript は使用できません: ppc64le
MongoDB 9.0 以降、サーバーサイド JavaScript は ppc64le アーキテクチャでは使用できません。ppc64le 用の mongod および mongos バイナリには、JavaScript エンジンは含まれていません。その結果、そのアーキテクチャでは $function、$accumulator、$where、および mapReduce 操作は失敗します。以前のバージョンでは、これらの操作は ppc64le で実行されていました。
ppc64leでは、構成ファイルの設定やコマンドラインオプションを使用してサーバー側のJavaScriptを有効にすることはできません。
アップグレードの影響
ppc64le 配置を MongoDB 9.0 にアップグレードする前に、$function、$accumulator、$where、または mapReduce を使用するアプリケーションを特定します。サーバー側の JavaScript を必要としない集計パイプラインステージと演算子を使用するように、これらの操作を書き換えます。異なるアーキテクチャを使用する配置で操作を実行することもできます。
詳細については、「サーバーサイドJavaScript」を参照してください。
セキュリティ
Queryable Encryptionのプレフィックス、サフィックス、およびサブストリングのパブリックプレビューからGAへの移行
MongoDB 9.0では、Queryable Encryptionが有効なコレクション内の暗号化されたstringフィールドに対するプレフィックス、サフィックス、および部分文字列クエリがGAとなりました。このGA機能は、MongoDB 8.2でリリースされたパブリックプレビュー版と互換性がありません。この機能がGAとなった現在、パブリックプレビュー版は使用しないでください。
Queryable Encryptionでプレフィックス、サフィックス、またはサブストリングクエリを使用するには、MongoDBのバージョンが9.0以降であり、9.0互換のドライバーが必要です。パブリックプレビューをまだ使用している場合、MongoDBはバージョン8.2または8.3のままである必要があり、8.2または8.3が必要です。互換ドライバー。
MongoDB 9.0 ドライバーは、MongoDB 8.2 または 8.3 ドライバーで作成されたデータを復号できます。アップグレードのオプションについては、次のセクションを参照してください。
新しい開始（推奨）
可能であれば、Public Preview機能で作成されたコレクションを移行するのではなく、新しいコレクションを作成してください。
MongoDBサーバーとドライバーを9.0にアップグレードします。
前のコレクションとは異なる名前で新しい暗号化されたコレクションを設定します。
新しいデータを挿入するか、ローカル コピーがある場合は既存のデータの暗号化されていないバージョンを挿入します。
前のコレクションを削除します。
既存のデータの移行
新しいデータを使用できない場合、または既存のデータの暗号化されていないバージョンがない場合。
MongoDB サーバーとドライバーを 9.0 にアップグレードする
9.0 互換ドライバーを使用して暗号化されたコレクションをクエリし、復号化します。
出力をローカルに保存します。
新しい暗号化されたコレクションを構成し、データを取り込みます。
警告
mongoexportおよびmongodump操作では、コレクションは復号されません。復号されたデータを出力するには、ドライバーからコレクションをクエリする必要があります。MongoDB 9.0 互換ドライバーは、MongoDB 8.2 用に暗号化されたデータの暗号化されたフィールドをクエリできません。パブリックプレビューのクエリタイプ。データを復号化するには、暗号化されていないフィールドをクエリするか、コレクション全体をクエリします。
下位互換性のない機能
次のセクションでは、配置から下位互換性のない機能を削除するための情報を提供します。MongoDB 9.0 から以前のバージョンにダウングレードする場合は、以下のセクションを確認して、ダウングレード後に配置が正常に実行されることを確認してください。
ビューにおける式
MongoDB 9.0 では、$convert を使用してオブジェクトを binData に変換できます。詳細については、「オブジェクトを binData に変換する」を参照してください。
この変換を使用するビューを作成した場合、以前のバージョンにダウングレードすると、そのビューに対するクエリはエラーを返します。
9.0 からダウングレードする前に、この変換を使用しているビューを更新または削除してください。