MongoDB 4.4 での互換性の変更

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

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

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

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

replSetGetStatus 出力フィールドの変更

replSetGetStatusコマンドとその mongo shellヘルパーrs.status()は、その出力から次の非推奨フィールドを削除します。

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

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

操作における最初の同期の制限

レプリカセット ノードで次の操作を実行するには、ノードがPRIMARYまたはSECONDARY状態である必要があります。

• listDatabases

• listCollections

• listIndexes

• distinct

• dbStats

• collStats

ノードがSTARTUP2などの別の状態にある場合、操作はエラーになります。

カスタムgetLastErrorDefaults 値は非推奨

バージョン4.4以降、 MongoDB では、デフォルトの{ w: 1, wtimeout: 0 }以外のsettings.getLastErrorDefaults値の指定が非推奨となります。 MongoDB 4.4はユーザーが指定した任意の書込み保証 (write concern) の値を尊重しますが、将来の MongoDB バージョンはデフォルト以外の値を尊重しない可能性があります。 代わりに、 setDefaultRWConcernコマンドを使用して、レプリカセットまたはシャーディングされたクラスターのデフォルトの読み取りまたは書込み保証 (write concern) を設定します。

フィールドを新しい値に設定

MongoDB 4.4以降、 findとfindAndModify()プロジェクションでは集計式と集計構文 を受け付けます。

集計式と構文規則（リテラルと集計変数の使用を含む）では、プロジェクション フィールド値としてリテラル（数値またはブール値以外）を指定すると、フィールドは新しい値でプロジェクションされます。

たとえば、 statusフィールドを含むドキュメントを含むコレクション インベントリを考えてみましょう。

db.inventory.insertOne( { _id: 1, item: "postcard", status: "A", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] })

MongoDB 以降、 4.4では、次の操作では、フィールドstatusとinstockを現在の値ではなく新しい値でプロジェクションします。

db.inventory.find(
   { status: "A" },
   { status: "Active", instock: ["blue", "crimson"] }
)

つまり、この操作は次のドキュメントを返します。

{ "_id" : 1, "status" : "Active", "instock" : [ "blue", "crimson" ] }

以前のバージョンでは、すべての指定値（ゼロ/false 値または以前にサポートされていない ドキュメント値を除く）は、現在の値を持つフィールドが含まれていることを示すtrueとして扱われていました。 つまり、以前のバージョンでは、前の操作では現在の値を持つstatus instockフィールドと フィールドが含まれるドキュメントが返されます。

{ "_id" : 1, "status" : "A", "instock" : [ { "warehouse" : "B", "qty" : 15 }, { "warehouse" : "C", "qty" : 35 } ] }

$elemMatch プロジェクション フィールドの順序

ドキュメント内のフィールドの順序に関係なく、既存フィールドの$elemMatchプロジェクションでは、他の既存フィールドを包含した後にフィールドが返されます。

たとえば、次のドキュメントを含む players コレクションを考えます。

db.players.insertOne( {
   name: "player1",
   games: [ { game: "abc", score: 8 }, { game: "xyz", score: 5 } ],
   joined: new Date("2020-01-01"),
   lastLogin: new Date("2020-05-01")
} )

次のプロジェクションでは、ドキュメントではjoinedフィールドとlastLoginフィールドの前に フィールドがリストされているにもかかわらず、プロジェクションに含まれる他の既存フィールドの後にgamesフィールドが返されます。

db.players.find( {}, { games: { $elemMatch: { score: { $gt: 5 } } }, joined: 1, lastLogin: 1 } )

つまり、この操作は次のドキュメントを返します。

{
   "_id" : ObjectId("5edef64a1c099fff6b033977"),
   "joined" : ISODate("2020-01-01T00:00:00Z"),
   "lastLogin" : ISODate("2020-05-01T00:00:00Z"),
   "games" : [ { "game" : "abc", "score" : 8 } ]
}

$slice の埋め込み配列

ネストされたドキュメント内の配列の$sliceプロジェクションは、プロジェクションがインクルージョン プロジェクションの一部である場合、ネストされたドキュメント内の他のフィールドを返さなくなりました。

たとえば、size フィールドを含むドキュメントを含むコレクション inventory を考えます。

{ item: "socks", qty: 100, details: { colors: [ "blue", "red" ], sizes: [ "S", "M", "L"] } }

次の操作では、 _idフィールド（デフォルト）、 qtyフィールド、およびdetailsフィールドを、 colors配列の指定されたスライスのみでプロジェクションします。

db.inventory.find( { }, { qty: 1, "details.colors": { $slice: 1 } } )

つまり、この操作は次のドキュメントを返します。

{ "_id" : ObjectId("5ee92a6ec644acb6d13eedb1"), "qty" : 100, "details" : { "colors" : [ "blue" ] } }

$sliceプロジェクションが除外プロジェクションの一部である場合、操作はネストされたドキュメント内の他のフィールドを引き続き返します。 つまり、次のプロジェクションは除外プロジェクションです。 プロジェクションでは、 _idフィールドと指定されたスライスの範囲外のcolors配列内の要素は除外され、他のすべてのフィールドが返されます。

db.inventory.find( { }, { _id: 0, "details.colors": { $slice: 1 } } )

{ "item" : "socks", "qty" : 100, "details" : { "colors" : [ "blue" ], "sizes" : [ "S", "M", "L" ] } }

$sliceプロジェクション自体は除外されていると見なされます。

以前のバージョンでは、プロジェクションが包含か除外かに関係なく、 $sliceプロジェクションにはネストされたドキュメント内の他のフィールドも含まれていました。

パスの不一致の制限

{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }

db.inventory.find( {}, { size: 1, "size.uom": 1 } )

{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }

db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )

$-プレフィックスが付いたフィールドパス制限

findとfindAndModify()プロジェクションでは、 DBRef フィールドを除き、 $で始まるフィールドをプロジェクションできません。

たとえば、次の操作は無効です。

db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )

$ 位置演算子の配置制限

$プロジェクション演算子は、フィールドパスの末尾にのみ使用できます（例: "field.$"または"fieldA.fieldB.$" 。

たとえば、次の操作は無効です。

db.inventory.find( { }, { "instock.$.qty": 1 } )

解決するには、$ プロジェクション演算子の後に続くフィールドパスのコンポーネントを削除してください。

$ 位置演算子と$slice の制限

find と プロジェクションには、findAndModify() $slice$プロジェクション式の一部として プロジェクション式を含めることはできません。

たとえば、次の操作は無効です。

db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )

以前のバージョンでは、MongoDB はクエリ条件に一致する instock 配列の最初の要素（instock.$）を返します。つまり、位置プロジェクション"instock.$" が優先され、$slice:1 の処理はありません。"instock.$": { $slice: 1 } は他のドキュメント フィールドを除外しません。

空のフィールド名に対するプロジェクション制限

findとfindAndModify()プロジェクションには、空のフィールド名のプロジェクションを含めることはできません。

たとえば、次の操作は無効です。

db.inventory.find( { }, { "": 0 } )

以前のバージョンでは、MongoDB は空のフィールドの包含/除外を、存在しないフィールドのプロジェクションと同様に扱っていました。

テキスト検索メタデータ { $meta: "textScore" } クエリ要件

MongoDB4.4 以降、プロジェクションまたはソートで$text 式を使用するには、 操作のクエリ述語にdb.collection.find() { $meta: "textScore" }演算子を指定する必要があります。例:

db.articles.find(
   { $text: { $search: "cake" } },
   { score: { $meta: "textScore" } }
);
db.articles.find(
   { $text: { $search: "cake" } },
   { score: { $meta: "textScore" } }
).sort( { score: {  $meta: "textScore" } } );

クエリ述語に$text演算子を指定しないと、操作は失敗します。 たとえば、次の操作は MongoDB 4.4以降では無効です。

db.articles.find(
   { },
   { score: { $meta: "textScore" } }
)
db.articles.find(
   { },
   { score: { $meta: "textScore" } }
).sort( { score: {  $meta: "textScore" } } );

単一の値を含むキーの削減

MongoDB 4.4以降、 mapReduceコマンドを実行すると、関連付けられたキーに含まれる値の数に関係なく、MongoDB はreduce関数を呼び出します。

以前のバージョンでは、MongoDB は単一の値を持つキーに対してreduce関数を呼び出しませんでした。

詳細については、「 使用状況 」を参照してください。

map-reduce 出力の変更

MongoDB 4.4以降、 mapReduceは、その出力からcountsフィールドを削除します。

以前のバージョンでは、 コマンドの出力にcountsフィールドが含まれていました。 例:

"counts" : {
   "input" : 4,
   "emit" : 4,
   "reduce" : 1,
   "output" : 2
},

Map Function's Emit Limit

MongoDB 4.4以降、 map関数は各emit()出力のサイズを MongoDB の最大 BSON ドキュメント サイズの半分に制限しなくなりました。

以前のバージョンでは、1 回の発行で MongoDB の最大 BSON ドキュメント サイズの半分しか保持できませんでした

スコープを持つ BSON 型 JavaScript コードのサポートを廃止します

mapReduceは、関数の中で非推奨のBSON Type JavaScript コード（BSON Type 15 ）のサポートを終了しました。 map、reduce、finalize 関数は、 BSON型のstring （ BSON Type 2）またはBSON型JavaScript （ BSON Type 13）のいずれかである必要があります。 map 、 reduce 、 finalize関数でアクセス可能な定数を渡すには、 scopeパラメーターを使用します。

mapReduce関数のスコープを持つ JavaScript コードの使用は、バージョン 4.2.1 以降では非推奨となっています。

rsgetLog 値の削除

MongoDB 4.4以降、メッセージタイプのこの分類は非推奨になったため、 getLogコマンドはrs値を受け入れなくなりました。 代わりに、ログ メッセージは常にコンポーネントによって識別されるようになりました（レプリケーション メッセージのREPLを含む）。

コンポーネント フィールドでフィルタリングするログ解析の例については、「コンポーネントによるフィルタリング」を参照してください。

タイムスタンプの形式

構造化 JSON ロギングへの移行に伴い、 ctimeタイムスタンプ形式はサポートされなくなりました。 次の構成オプションでは、有効なパラメータとしてctimeを受け入れなくなりました。

• systemLog.timeStampFormat

• mongod --timeStampFormat

• mongos --timeStampFormat

代わりに、 iso8601-local （デフォルト）またはiso8601-utcタイムスタンプ形式を使用してください。

maxLogSizeKB パラメーター

構造化 JSON ロギングへの移行により、 maxLogSizeKBサーバー パラメータは指定された制限を超えるログ エントリ内の個々の属性を切り捨てるようになりました。 以前は、このパラメーターはログ エントリ全体を切り捨てていました。

さらに、

• maxLogSizeKBが0の値を受け入れるようになりました。これにより、切り捨てが完全に無効になります。

• maxLogSizeKB 負の値を受け入れなくなりました。

詳細については、「ログメッセージの切り捨て」を参照してください。

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

mongoメソッドdb.collection.validate()はブール値パラメータのみを受け付けなくなりました。

つまり、 メソッドはdb.collection.validate(<boolean>)をdb.collection.validate({full: <boolean>})の省略形として受け入れなくなりました。

での完全検証 oplog

MongoDB 4.4以降、WiredTiger のoplogでの完全な検証では、より詳細なチェックがスキップされます。 validate.warningsには の動作に関する通知が含まれています。

MMAPv 1クリーンアップ

• dbStatsコマンドは廃止された MMAPv 1 numExtentsフィールドを返さなくなりました。

• replSetGetStatusコマンドは、出力で廃止された MMAPv 1フィールドreplSetGetStatus.initialSyncStatus.fetchedMissingDocsを返さなくなりました。

• fsyncコマンドは、廃止された MMAPv 1フィールドasyncをオプションとして受け入れなくなりました。

非推奨