Release Notes for MongoDB 4.2の翻訳です。原文はMongoDB Documentation Teamによるものです。ライセンスはCC BY-NC-SA 3.0となっています。
MongoDB documentation is distributed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.
現時点(2019/5)では4.2は未リリースで、4.1系として開発が続けられている状態です。リリースノートも今後正式リリースまでに変わる可能性があります。変更があった場合は可能な限り追随していく予定です。
MongoDB 4.2 リリースノート
シャードクラスタ環境での複数ドキュメントトランザクション
MongoDB 4.2では複数ドキュメントトランザクションの機能がシャードクラスタ環境でも利用できるようになりました。
この機能を利用するには、シャードクラスタのすべてのメンバーにおいて featureCompatibilityVersion が4.2になっている必要があります。
MMAPv1ストレージエンジン廃止
MongoDB 4.2では、すでに非推奨であったMMAPv1ストレージエンジンが廃止になりました。
現在4.0の環境でMMAPv1を使用している場合は、MongoDB 4.2にアップグレードする前に、WiredTigerストレージエンジンに変更する必要があります。詳細については以下を参照してください。
MMAPv1特有の設定オプション
以下のMMAPv1特有の設定オプションは削除されました。
Configuration File Setting | Command-line Option |
---|---|
storage.mmapv1.journal.commitIntervalMs | |
storage.mmapv1.journal.debugFlags | mongod --journalOptions |
storage.mmapv1.nsSize | mongod --nssize |
storage.mmapv1.preallocDataFiles | mongod --noprealloc |
storage.mmapv1.quota.enforced | mongod --quota |
storage.mmapv1.smallFiles | mongod --smallfiles |
storage.repairPath | mongod --repairpath |
replication.secondaryIndexPrefetch | mongod --replIndexPrefetch |
MMAPv1特有のパラメータ
以下のMMAPv1特有のパラメータは削除されました。
- newCollectionsUsePowerOf2Sizes
- replIndexPrefetch
MMAPv1特有のコマンド
MMAPv1特有の touch コマンドは削除されました。
ツール類、コマンド、メソッドに関するMMAPv1特有のオプション
MMAPv1特有の以下のオプションは削除されました。
- collModに対するnoPaddingとusePowerOf2Sizes
- collStatsに対するverbose
- createに対するflags
- db.createCollection()メソッドとcompactコマンドに対するpaddingFactor、paddingBytes、preservePadding
- mongodumpに対するrepair
削除されたコマンドやメソッド
Removed Command | Removed Method | Notes |
---|---|---|
group | db.collection.group() | 代わりにdb.collection.aggregate()で$groupステージを使用してください。 |
eval | MongoDB 4.2のmongoシェルでは、db.eval()とdb.collection.copyTo()は、MongoDB 4.0もしくはそれ以前に対して接続されている時のみ実行できます。 | |
copydb | 対応するmongoシェルのヘルパーであるdb.copyDatabase()は、MongoDB 4.0もしくはそれ以前に対して接続されている時のみ実行できます。 代替策として、mongodump/mongorestoreや、カスタムスクリプトを用いることができます。 |
|
clone | 対応するmongoシェルのヘルパーであるdb.cloneDatabase()は、MongoDB 4.0もしくはそれ以前に対して接続されている時のみ実行できます。 代替策として、mongodump/mongorestoreや、カスタムスクリプトを用いることができます。 |
|
geoNear | 代わりに、db.collection.aggregate()において$geoNearステージを使用してください。 詳細についてはgeoNearコマンドの削除を参照してください。 |
|
parallelCollectionScan | ||
repairDatabase | db.repairDatabase() | 詳細については、repairDatabaseコマンドの削除を参照してください。 |
maxScanオプションの削除
すでに非推奨であった、findコマンドのmaxScanオプションと、そのmongoシェルヘルパーであるcursor.maxScan()は削除されました。代わりに、findコマンドのmaxTimeMSオプションか、もしくはヘルパーのcursor.maxTimeMS()を使ってください。
シャードクラスタ
複数シャードにまたがるトランザクションで原子性を維持するためには、MongoDB AtlasもしくはMongoDB Ops Managerで提供されるバックアップ・リストアを使用してください。これらのバックアップ・リストアはシャードクラスタ環境と適切に協調動作します。手動のバックアップ・リストアでは、複数シャードにまたがるトランザクションでの原子性を維持することができません。
セキュリティに関する改善
TLSオプションの追加
MongoDB 4.2ではmongod、mongos、mongoシェルにおいて、従来のSSLオプションを置き換える、TLSオプションが追加されました。SSLオプションは4.2で非推奨となりました。MongoDBはTLS 1.0以降をずっとサポートしていたため、新しいTLSオプションは、SSLオプションと 同じ 機能を提供します。
- コマンドラインTLSオプションについては、mongod、mongos、mongoシェルの各ページを参照してください。
- 対応するmongodとmongosの設定ファイルオプションについては、設定ファイルのページを参照してください。
- 接続文字列におけるtlsオプションについては、接続文字列のページを参照してください。
ほとんどのTLSオプション名は、SSLオプション名と似ています。たとえば--tlsModeと--sslModeというように。例外は以下です。
- TLSではnet.tls.certificateKeyFile、SSLではnet.ssl.PEMKeyFile
- TLSではnet.tls.certificateKeyFilePassword、SSLではnet.ssl.PEMKeyPassword
- TLSでは--tlsCertificateKeyFile、SSLでは--sslPEMKeyFile
- TLSでは--tlsCertificateKeyFilePassword、SSLでは--sslPEMKeyPassword
SSLオプションの非推奨化
MongoDB 4.2ではmongod、mongos、mongoシェルでのSSLオプション、それに対応する設定ファイルでのnet.sslオプションが非推奨となりました。
代わりに、新しいTLSオプションを使用してください。
tlsWithholdClientCertificateパラメータの追加
MongoDB 4.2では、mongodとmongosに対するsetParameterにtlsWithholdClientCertificateが追加されました。trueに設定すると、クラスタ内部認証の通信において当該mongodがクライアントとして振舞わないようになり、TLS証明書を他のmongodに対して送らないようになります。証明書無しでの着信を認める場合に使用してください。
tlsClusterCAFileオプションの追加
MongoDB 4.2では、--tlsClusterCAFileオプション、mongodとmongosでのnet.tls.clusterCAFileオプションが追加されました。これらは.pemファイルを指定して、クライアントからのコネクション確立を受け付けるときにTLS証明書を検証するためのものです。これにより、TLSハンドシェイクのクライアント・サーバー間、サーバー・クライアント間のそれぞれを検証するのに別々の認証局を使用することが出来るようになりました。
TLSオプション
passwordPrompt()
4.2以降のmongoシェルでは、さまざまなユーザー認証、管理メソッド、コマンドとpasswordPrompt()メソッドを組み合わせることで、パスワードをメソッドやコマンドに直接渡すのではなく、プロンプト入力させることができるようになりました。ただし、旧バージョンのmongoシェルを使う場合はパスワードを直接渡す必要があることに注意してください。
以下に例を示します。
db.createUser( {
user:"user123",
pwd: passwordPrompt(), // Instead of specifying the password in cleartext
roles:[ "readWrite" ]
} )
キーファイルがYAML形式に変更
MongoDB 4.2から、クラスタ内部メンバーの認証に使用するキーファイルは、複数のキーを1つのキーファイルに格納できるようにするため、YAML形式となりました。YAML形式では以下の内容を含むことができます。
- 単一のキー文字列(以前のバージョンと同じ)
- 複数のキー文字列(それぞれの文字列は引用符に囲まれている必要があります)
- キー文字列のシーケンス
YAML形式は、テキスト形式であるという点では、従来の単一キーのキーファイルと同じです。
新しい形式を使うと、ダウンタイム無しでキーのローリングアップデートが可能となります。レプリカセットでのキーのローテート、シャードクラスタでのキーのローテートを参照してください。
一般的なセキュリティに関する改善
- backup組み込みロールに、serverStatus権限が追加されました。
Aggregationに関する改善
$outステージの改善
MongoDB 4.2では$outステージに新しいシンタックスが追加されました。新しいシンタックスでは以下のことができます。
- aggregationの出力と既存のコレクションのマージ
- 既存のコレクションの内容をaggregationの出力で置き換え
- 異なるデータベースのコレクションに出力
- シャード化されている既存のコレクションに出力
aggregationの出力と、異なるデータベースの既存のコレクションとのマージを行う例を示します。
{ $out: { to : "employees", mode : "insertDocuments", db : "hr" } }
従来のシンタックスでは、既存のコレクションの内容をaggregationの出力で置き換えることは出来ましたが、シャード化されたコレクションに出力することはできませんでした。
従来のシンタックスの例を示します。
{ $out: "stock" }
$outステージの制約事項
Aggregationにおける三角関数の追加
MongoDB 4.2では、aggregationパイプライン中で使用可能な三角関数が追加されました。
これらは数値に対して三角関数の計算をします。角度を表す値は、常にラジアンとして解釈されます。度数とラジアンの変換には$degreesToRadians、$radiansToDegreesを使用してください。
Name | Description |
---|---|
$sin | サイン |
$cos | コサイン |
$tan | タンジェント |
$asin | アークサイン |
$acos | アークコサイン |
$atan | アークタンジェント |
$atan2 | y/xのアークタンジェント。yが第1引数、xが第2引数。 |
$asinh | ハイパボリックアークサイン |
$acosh | ハイパボリックアークコサイン |
$atanh | ハイパボリックアークタンジェント |
$degreesToRadians | 度数からラジアンに変換 |
$radiansToDegrees | ラジアンから度数に変換 |
Aggregationにおける算術式
MongoDB 4.2では$roundが追加されました。数値を特定の桁に丸める場合に$roundを使用してください。
MongoDB 4.2では、$truncに拡張機能と新しいシンタックスが追加されました。新しいシンタックスで$truncを使うことで、数値を特定の桁に切り捨てることができます。
新たなステージ
MongoDB 4.2では、新たなaggregationパイプラインステージである$planCacheStatsが追加され、これによりあるコレクションに対するプランキャッシュの情報が取得できるようになりました。
$planCacheStatsaggregationステージは、PlanCache.getPlansByQuery()メソッド、planCacheListPlansコマンド、PlanCache.listQueryShapes()メソッド、planCacheListQueryShapesコマンドよりも優先されます。
Change Stream
startAfterオプション
MongoDB 4.2では、Change Streamに対してstartAfterオプションが追加されました。レジュームトークンで示されるイベントの後に新しいChange Streamをスタートするようにするものです。このオプションにより、invalidateイベントからChange Streamを開始することができるようになり、以前のStreamが無効化されたあとの通知を見逃さないよう保証することができるようになりました。
Change Streamレジュームトークン
MongoDB 4.2では、Change Streamレジュームトークンのバージョン1(つまりv1)を使用します。Change Streamレジュームトークン バージョン1は、MongoDB 4.0.7で導入されました。
Wildcard インデックス
MongoDB 4.2では、ユーザーがコレクション内のさまざまなフィールドに対してクエリを実行するワークロードをサポートするため、ワイルドカードインデックスが追加されました。データベース管理者は、各ユーザーの様々なデータアクセスパターンをサポートするのに多数のインデックスを作成するのではなく、ドキュメントのフィールドの一部、または全てのフィールドを対象としてワイルドカードインデックスを作成できます。
MongoDBは、特定のフィールドパス、または複数のフィールドパスに関連付けられたスカラー値にインデックスをつけます。インデックスキーには、フィールドへのフルパスが含まれます。サブドキュメントを含むフィールドの場合、MongoDBはサブドキュメントの中に降りて、サブドキュメント内のフィールドと値のペアのインデックスキーを作成します。配列であるフィールドの場合は、MongoDBはマルチキーインデックスの場合と同様に、配列内の各値に対してインデックスキーを作成します。
ワイルドカードインデックスは、ワークロードにもとづいてインデックスを計画することを置き換えられるものではありません。クエリーをサポートするインデックスを作るための詳しい情報はこちらを参照してください。
ワイルドカードインデックスはスパースインデックスの一種で、インデックスには空でない値(スカラー値やnull)を持つフィールドのエントリのみが含まれます。
ワイルドカードインデックスは、createIndexesコマンド、またはそのシェルヘルパーであるdb.collection.createIndex()、db.collection.createIndexes()を使用して作成することができます。ワイルドカードインデックスの作成例は、ワイルドカードインデックスを作成するを参照してください。
ワイルドカードインデックスを作成する前に、mongodのfeatureCompatibilityVersion (fCV) を4.2に設定する必要があります。fCVの設定方法については、4.2 機能の互換性を参照してください。
ワイルドカードインデックスの制約事項
- ワイルドカードインデックスは、以下のインデックス形式、プロパティをサポートしません。
- ワイルドカードインデックスは、以下のクエリオペレータをサポートしません。
- { $exists: false }
- { $eq: null }
- { $eq: [ { a: 1 } ] }
- { $eq: { <object> } }
- { $ne: { <object> } }
- { $ne: null } (配列を含むフィールドパスに対するクエリの場合)
- ワイルドカードインデックスを用いてコレクションをシャード化することはできません。
- ワイルドカードインデックスでカバーされている複数のフィールドを指定したクエリに対しては、ワイルドカードインデックスはクエリ内の最大1つのフィールドをサポート可能です。クエリの$or演算子またはaggregationの$orオペレータを使用しているクエリに対しては、クエリプランナは単一のワイルドカードインデックスを使って、独立した$orの引数を満たすことができます。クエリプランナは、任意のクエリに対してどのワイルドカードインデックスフィールドを使うか選択します。
クエリプランナは、次の場合に限って、ワイルドカードインデックスを使用してsort()オペレーションもサポートすることができます。- ソートフィールドがワイルドカードインデックスに含まれており、かつ、
- ソートフィールドがクエリの条件部分にも含まれており、かつ、
- クエリプランナがクエリを満たすためにソートフィールドを選択した場合
サポート対象プラットフォーム
- MongoDB 4.2 (Community版およびEnterprise版) は以下のサポートを追加しました。
- ARM64上でのUbuntu 18.04
- MongoDB 4.2 (Community版およびEnterprise版) は以下のサポートを削除しました。
- Ubuntu 14.04
- macOS 10.11
サポート対象プラットフォームも参照してください。
MongoDB ツール群
FIPSモード
バージョン4.2以降、--sslFIPSModeオプションは以下のプログラムから削除されました。
これらのプログラム群は、接続先のmongod/mongosがFIPSモードを使うように設定されている場合に限り、FIPSに準拠したコネクションを確立します。
一般的な改善
トラフィックレコーダ
MongoDB 4.2ではmongod/mongosに対して送受信される全てのワイヤープロトコルトラフィックをキャプチャーし、指定のファイルに記録するためのトラフィックレコーダが追加されました。
- 有効化するには、trafficRecordingDirectoryパラメータを起動時に設定する必要があります。
- 開始するには、startRecordingTrafficコマンドを使います。
- 終了するには、stopRecordingTrafficコマンドを使います。
serverStatusコマンドと、db.serverStatus()メソッドの出力に、trafficRecordingの項目が含まれるようになりました。
outputConfigオプション
MongoDB 4.2ではmongodとmongosに--outputConfigオプションが追加され、YAML設定ドキュメントを標準出力に出力し、サーバーインスタンスを停止することができるようになりました。
インデックスキーのサイズ制限の解除
MongoDB 4.2以降で、featureCompatibilityVersionが4.2またはそれ以上に設定されている場合、インデックスキーのサイズ制限は解除されます。fCVが4.0に設定されている場合は、制限は有効のままです。
インデックス名の長さ制限の解除
MongoDB 4.2以降で、featureCompatibilityVersionが4.2またはそれ以上に設定されている場合、最大127バイトというインデックス名の長さ制限は解除されます。以前のバージョンや、fCVが4.0に設定されている場合は、この制限長以内である必要があります。
dropIndexesの改善
複数インデックスのdrop
MongoDB 4.2以降では、dropIndexesコマンドや、そのmongoシェルヘルパーであるdb.collection.dropIndexes()に対して、複数のインデックスを指定することができるようになりました。複数のインデックスを指定するには、dropIndexes/db.collection.dropIndexes()に対してインデックス名の配列を渡してください。
関連するクエリのみkill
MongoDB 4.2以降では、dropIndexesと、シェルヘルパーであるdropIndex()、dropIndexes()は、dropされようとしているインデックスを使用しているクエリのみをkillするようになりました。これは、当該インデックスをクエリプランニングの一部として検討中であるクエリも含むかもしれません。
以前のバージョンのMongoDBでは、あるコレクションのインデックスをdropする場合は、そのコレクション上でオープンされているすべてのクエリをkillしていました。
設定ファイルにおける外部からの値取り込み
MongoDBは、設定ファイル中で展開ディレクティブを使うことで、外部から値を読み込むことができます。展開ディレクティブは特定の設定ファイルオプションか、もしくは設定ファイル全体を読み込むことができます。
以下の展開ディレクティブが利用可能です。
展開ディレクティブ | 説明 |
---|---|
__rest | RESTエンドポイントを指定して、そこから値を読み込みます。 |
__exec | シェルやターミナルのコマンドを指定して、そこから値を読み込みます。 |
完全なドキュメントは、外部からの設定ファイルオプション読み込みを参照してください。
currentOp
MongoDB 4.2では、$currentOp aggregationステージにidleCursorsという新しいオプションが追加され、アイドル状態のカーソルに対する情報が取得できるようになりました。
さらに、MongoDB 4.2では$currentOp aggregationステージ、currentOpコマンド、db.currentOp()ヘルパーから返されるドキュメントに、以下の新しいフィールドが追加されました。
$currentOp | currentOp/db.currentOp() | Description |
---|---|---|
$currentOp.type | currentOp.type | 情報取得対象のオペレーションがop、idleSession、idleCursorのいずれであるかを指定する。 |
$currentOp.cursor | currentOp.cursor | カーソルの詳細を指定する。getmoreオペレーションやidleCursorの情報を返す時に利用可能。 |
$currentOp.effectiveUsers | currentOp.effectiveUsers | オペレーションに紐づくユーザーを指定する。 |
$currentOp.userImpersonators | currentOp.userImpersonators | オペレーションの実効ユーザーになりすますユーザーを指定する。 |
4.2 current opに関する互換性の変更点も参照してください。
ロギング
- INITSYNCコンポーネントが追加されました。
- ELECTIONコンポーネントが追加されました。
- デバッグメッセージにはverbosityレベル(D[1-5])が含まれるようになりました。たとえば、verbosityレベルが2の場合は、MongoDBは D2 というログを出力します。以前のバージョンでは、MongoDBはデバッグレベルでは単にDと出力していました。
-
syslogにロギングしている場合、メッセージテキストのフォーマットにコンポーネント名が含まれるようになりました。たとえば以下のようになります。
... ACCESS [repl writer worker 5] Unsupported modification to roles collection ...
以前は、syslogでのメッセージテキストにはコンポーネント名は含まれていませんでした。たとえば以下のようになっていました。
... [repl writer worker 1] Unsupported modification to roles collection ...
- MongoDB 4.2では、プロファイラログメッセージと分析ログメッセージにおいて、aggregateオペレーションに関しての usedDisk インジケータが追加されました。usedDisk はaggregateオペレーションのいずれかのステージでメモリの制約により一時ファイルが使用されたことを示します。aggregationでのメモリの制約についてはメモリ制約を参照してください。
- バージョン4.2以降(4.0.6以降も含む)では、レプリカセットのセカンダリメンバーは、しきい値以上に長時間かかっているoplog反映処理を、スローログ出力できるようになりました。セカンダリにてREPLコンポーネントとして、 applied op: <oplog entry> took <num>ms. というテキストでログ出力されます。
2018-11-16T12:31:35.886-0500 I REPL [repl writer worker 13] applied op: command { ... }, took 112ms
セカンダリにおける、遅いoplog適用のロギングは、
- slowOpSampleRateの影響は受けません。つまり、すべての遅いoplog適用がセカンダリでログ出力されます。
- logLevel/systemLog.verbosityレベル(またはsystemLog.component.replicateion.verbosityレベル)の影響は受けません。つまり、oplogについては、セカンダリは遅いoplogのみログ出力します。verbosityレベルを上げたとしても、すべてのoplogがログ出力されることはありません。
- プロファイラにはキャプチャされません。プロファイリングレベルには影響を受けません。
スローオペレーションのしきい値の設定についてさらなる詳細は以下を参照してください。
- mongod --slowms
- slowOpThresholdMs
- profileコマンド、またはシェルヘルパーのdb.setProfilingLevel()メソッド。
- MongoDB 4.2以降では、getLogコマンドは1024文字以上を含むイベントをtruncateします。以前のバージョンでは、getLogは512文字以上の場合truncateしていました。
- MongoDB 4.2以降(および4.0.9)では、プロファイラエントリや分析ログメッセージにスローログとして出力されるオペレーションは、ストレージの情報を含むようになりました。
- MongoDB 4.2以降では、read/writeオペレーションに関するプロファイラエントリや分析ログメッセージ(mongod/mongosログメッセージ)は以下の項目を含むようになりました。
- 同じ形をしているスロークエリを識別するため queryHash
- スロークエリについて、クエリプランキャッシュについてさらなる情報を得られるようにするため、planCacheKey
クエリハッシュとプランキャッシュキーを参照してください。
serverStatusメトリクス
- shardingStatisticsに新しい項目が追加されました。
- metrics.repl.networkに新しい項目が追加されました。
- プライマリがステップダウンするときに実行中のオペレーションについて情報取得するため、metrics.repl.stepDownという新しい項目が追加されました。metrics.repl.stepDownには以下の項目が含まれます。
- トラフィックレコーダの情報を取得するため、trafficRecordingという新しい項目が追加されました。trafficRecordingには以下の項目が含まれます。
- transactionsに以下の新しい項目が追加されました。
zstdの導入
MongoDB 4.2以降では、以下の機能に対してzstdが導入されました。
- ブロック圧縮。storage.wiredTiger.collectionConfig.blockCompressorを参照してください。
- ジャーナル圧縮。storage.wiredTiger.engineConfig.journalCompressorを参照してください。
- ネットワーク圧縮。net.compression.compressorsを参照してください。
queryHashとplanCacheKey
-
queryHash
同じ形をしているスロークエリを識別しやすくするため、MongoDB 4.2以降では、クエリの形ごとにqueryHashが割り当てられるようになりました。queryHash は、クエリの形のハッシュ値を表す16進数の文字列で、クエリの形によってのみ決まります。注意:
ハッシュ関数には一般的なことですが、2つの異なるクエリの形に対して同じハッシュ値となる可能性があります。ただしそのようなハッシュ値の衝突は非常にまれです。 -
planCacheKeyクエリプランのキャッシュについて詳細な情報を取得できるようにするため、MongoDB 4.2ではplanCacheKeyが導入されました。
planCacheKeyは、クエリに関連付けられているプランキャッシュエントリのキーのハッシュ値です。注意:
queryHashとは異なり、planCacheKeyはクエリの形と、そのクエリに対して現在利用可能なインデックスの両方の影響を受けます。つまり、そのクエリに対して利用可能なインデックスが追加または削除された場合、planCacheKeyの値は変わりますが、queryHashは変わりません。参照:
planCacheKey -
queryHashとplanCacheKeyは以下で利用可能です。
- プロファイラ出力では、ログ出力されたオペレーションについてqueryHashとplanCacheKey
- 分析ログメッセージ(mongod/mongosのログメッセージ)
- explain()出力
クエリプランキャッシュに関する情報を返すオペレーションの中でも利用可能です。
- $planCacheStats aggregationステージ(MongoDB 4.2で新規導入)
- PlanCache.listQueryShapes()メソッド/planCacheListQueryShapesコマンド
- PlanCache.getPlansByQuery()メソッド/planCacheListPlansコマンド
$regexと$not
MongoDB 4.2以降(および4.0.7)では、$notオペレータは$regexオペレータおよび正規表現オブジェクト(/pattern/形式)の両方に対して、論理否定として働くようになりました。
4.0およびそれ以前のバージョンでは、$notは正規表現オブジェクト(/pattern/形式)に対しては働きましたが、$regexオペレータに対しては働きませんでした。
自分自身のカーソルをkill
MongoDB 4.2以降では、ユーザーはいつでも、killCursors権限を持っているかどうかに関わらず、自分自身のカーソルをkillすることができるようになりました。killCursors権限はMongoDB 4.2以降ではこの点については影響を持たなくなりました。
MongoDB 4.0では、自分自身のカーソルをkillするためにもkillCursors権限が必要でした。
collStats
MongoDB 4.2以降では、$collStats aggregation、collStatsコマンド、mongoシェルヘルパーのdb.collection.statsは
構築途中のインデックスに関する情報を返すようになりました。
詳細については、以下を参照してください。
- collStats.nindexes
- collStats.indexDetails
- collStats.indexBuilds
- collStats.totalIndexSize
- collStats.indexSizes
互換性への影響
いくつかの変更点は互換性に影響する可能性があり、ユーザーの対応が必要になるかもしれません。詳細な一覧はMongoDB 4.2での互換性の変更点を参照してください。
アップグレードの手順
FEATURE COMPATIBILITY VERSION:
アップグレードするには、4.0のインスタンスはfeatureCompatibilityVersionを4.0にしておく必要があります。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
featureCompatibilityVersionを確認したり設定したりするための詳細や、アップグレードに関するその他の必要条件、考慮事項などについては、それぞれの手順を参照してください。
4.2へのアップグレードで支援が必要な場合は、MongoDB社はメジャーバージョンアップグレードサービスを提供しています。これは、あなたのアプリケーションを停止させることなく円滑な移行ができるように支援するものです。
問題を報告する
問題を報告するためには https://github.com/mongodb/mongo/wiki/Submit-Bug-Reports を参照してください。MongoDBサーバや、関連プロジェクトについて、JIRAチケットを登録する方法が書いてあります。