翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon DocumentDB のトラブルシューティング
以下のセクションでは、Amazon DocumentDB (MongoDB 互換) の使用時に発生する可能性がある問題をトラブルシューティングする方法について説明します。
**Topics**
+ [接続の問題](troubleshooting.connecting.md)
+ [インデックス](troubleshooting.index-creation.md)
+ [パフォーマンスとリソース使用率](user_diagnostics.md)
+ [ガベージコレクション](garbage-collection.md)
# 接続の問題のトラブルシューティング
接続に問題がありますか。一般的なシナリオと、それらを解決する方法は、次の通りです。
**トピック**
+ [Amazon DocumentDB エンドポイントに接続できない](#troubleshooting-connecting)
+ [Amazon DocumentDB インスタンスへの接続のテスト](#troubleshooting.testing-connection)
+ [無効なエンドポイントへの接続](#troubleshooting.invalid-endpoint)
+ [接続数に影響するドライバー設定](#troubleshooting.driver.config)
## Amazon DocumentDB エンドポイントに接続できない
Amazon DocumentDB に接続しようとすると、以下のような最も一般的なエラーメッセージが表示されることがあります。
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
このエラーメッセージは、クライアント (この例では mongo シェル) が Amazon DocumentDB エンドポイントにアクセスできないことを意味します。これには以下のようにいくつかの原因が考えられます。
**Topics**
+ [パブリックエンドポイントからの接続](#troubleshooting.cannot-connect.public-endpoints)
+ [リージョン間接続](#troubleshooting.cannot-connect.different-regions)
+ [別の Amazon VPC からの接続](#troubleshooting.cannot-connect.different-vpcs)
+ [セキュリティグループがインバウンド接続をブロックする](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Java Mongo ドライバーの読み取り設定に関する問題](#troubleshooting-cannot-connect-java-mongo-issue)
### パブリックエンドポイントからの接続
**ノートパソコンやローカル開発マシンから直接 Amazon DocumentDB クラスターに接続しようとしています。**
ノートパソコンやローカル開発マシンなどのパブリックエンドポイントから Amazon DocumentDB クラスターに直接接続しようとしても失敗します。Amazon DocumentDB は仮想プライベートクラウド (VPC) 専用で、現在パブリックエンドポイントをサポートしていません。したがって、ノートパソコンまたは VPC の外部のローカル開発環境から直接 Amazon DocumentDB クラスターに接続することはできません。
Amazon VPC の外部から Amazon DocumentDB クラスターに接続するには、SSH トンネルを使用します。詳細については、「[Amazon VPC の外部から Amazon DocumentDB クラスターへの接続](connect-from-outside-a-vpc.md)」を参照してください。さらに、開発環境が別の Amazon VPC にある場合は、VPC ピアリングを使用して、同じリージョンまたは別のリージョンにある別の Amazon VPC から Amazon DocumentDB クラスターに接続することもできます。
### リージョン間接続
**他のリージョンにある Amazon DocumentDB クラスターに接続しようとしています。**
クラスターのリージョン以外のリージョンにある Amazon EC2 インスタンスから Amazon DocumentDB クラスターに接続しようとするとします。例えば、米国西部 (オレゴン) リージョン (us-west-2) から米国東部 (バージニア北部) リージョン (us-east-1) からクラスターに接続しようとしても失敗します。
Amazon DocumentDB クラスターのリージョンを確認するには、以下のコマンドを実行します。そのリージョンはエンドポイントにあります。
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
このオペレーションによる出力は、次のようになります。
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
EC2 インスタンスのリージョンを確認するには、以下のコマンドを実行します。
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
このオペレーションによる出力は、次のようになります。
```
[
[
"us-east-1a"
]
]
```
### 別の Amazon VPC からの接続
**クラスターのデプロイ先の Amazon VPC とは異なる VPC から Amazon DocumentDB クラスターに接続しようとしています。**
Amazon DocumentDB クラスターと Amazon EC2 インスタンスの両方が同じ にあり AWS リージョン、同じ Amazon VPC にない場合、2 つの Amazon VPCs 間で VPC ピアリングが有効になっていない限り、Amazon DocumentDB クラスターに直接接続することはできません。
Amazon DocumentDB インスタンスの Amazon VPC を確認するには、以下のコマンドを実行します。
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Amazon ÉC2 インスタンスの Amazon VPC を確認するには、以下のコマンドを実行します。
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### セキュリティグループがインバウンド接続をブロックする
**Amazon DocumentDB クラスターに接続しようとしているが、クラスターのセキュリティグループはクラスターのポート (デフォルトポート: 27017) でインバウンド接続を許可していない。**
Amazon DocumentDB クラスターと Amazon EC2 インスタンスが両方とも同じリージョン内および同じ Amazon VPC 内にあり、同じ Amazon VPC セキュリティグループを使用しているとします。Amazon DocumentDB クラスターに接続できない場合は、クラスターのセキュリティグループ (ファイアウォール) で、Amazon DocumentDB クラスター用に選択したポート (デフォルトポートは 27017) でインバウンド接続を許可していないことが原因と考えられます。
Amazon DocumentDB クラスターのポートを確認するには、以下のコマンドを実行します。
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Amazon DocumentDB クラスターのセキュリティグループを取得するには、以下のコマンドを実行します。
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
セキュリティグループのインバウンドルールを確認するには、Amazon EC2 ドキュメントの以下のトピックを参照してください。
+ [Linux インスタンスのインバウンドトラフィックの承認](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Windows インスタンスのインバウンドトラフィックの承認](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Java Mongo ドライバーの読み取り設定に関する問題
**クライアントの読み取り設定は適用されず、一部のクライアントは再起動しない限りフェイルオーバー後に Amazon DocumentDB に書き込むことができません。**
この問題は、Java Mongo ドライバー 3.7.x で初めて発見されましたが、クライアントが `MongoClientSettings` を使用して Amazon DocumentDB への接続を確立したとき、具体的には `applyToClusterSettings` メソッドをチェーニングしたときに発生します。MongoClient クラスター設定は、`hosts()`、`requiredReplicaSetName()`、`mode()` などのいくつかの異なる方法を使用して定義できます。
クライアントが `hosts()` メソッドでホストを 1 つだけ指定した場合、モードは `ClusterConnectionMode.MULTIPLE` の代わりに `ClusterConnectionMode.SINGLE` に設定されます。これにより、クライアントは読み取り設定を無視し、`hosts()` で設定されているサーバーにのみ接続します。そのため、クライアントの設定が以下のように初期化されても、すべての読み取りはセカンダリではなくプライマリに送られます。
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**フェイルオーバーケース**
上記のクライアント接続設定を使用すると、クラスターライターエンドポイントのフェイルオーバーが発生し、DNS レコードの更新が遅れた場合でも、クライアントは古いライター (フェイルオーバー後にリーダーになる) への書き込みを試みます。その結果、(プライマリではない) サーバー側のエラーが発生し、Java ドライバーでは適切に処理することができません (この問題についてはまだ調査中です)。そのため、たとえばアプリケーションサーバーが再起動されるまで、クライアントは不正な状態のままになる可能性があります。
これには次の 2 つの回避策があります。
+ 接続文字列を使用して Amazon DocumentDB に接続するクライアントは、読み込み設定を設定するときに `ClusterConnectionMode` が `MULTIPLE` に設定されるため、この問題は発生しません。
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
または、`applyConnectionString` メソッドで `MongoClientSettings` ビルダーを使用することもできます。
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ 明示的に `ClusterConnectionMode` を `MULTIPLE` に設定します。これは `applyToClusterSettings` と `hosts().size() == 1` を使用する場合にのみ必要です。
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Amazon DocumentDB インスタンスへの接続のテスト
一般的な Linux または Windows ツールを使用して、クラスターへの接続をテストできます。
Linux または UNIX のターミナルからは、次のように入力することで接続をテストします (`cluster-endpoint` と `port` をインスタンスのエンドポイントとポートに置き換えてください)。
```
nc -zv cluster-endpoint port
```
サンプルのオペレーションと戻り値の例を次に示します。
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## 無効なエンドポイントへの接続
Amazon DocumentDB クラスターに接続し、有効でないクラスターエンドポイントを使用すると、以下のようなエラーが表示されます。
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
出力は次のようになります。
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
クラスターの有効なエンドポイントを取得するには、以下のコマンドを実行します。
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
インスタンスの有効なエンドポイントを取得するには、以下のコマンドを実行します。
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
詳細については、「[Amazon DocumentDB エンドポイントについて](endpoints.md)」を参照してください。
## 接続数に影響するドライバー設定
クライアントドライバーを使用して Amazon DocumentDB クラスターに接続する場合は、`maxPoolSize` 設定パラメータを考慮することが重要です。`maxPoolSize` 設定は、クライアントドライバーが接続プールに維持できる接続の最大数を決定します。
# トラブルシューティングインデックス
次のトピックでは、インデックスまたはバックグラウンドインデックスの構築が失敗したときにどうすべきかを説明しています。
**Topics**
+ [インデックスの構築が失敗する](#troubleshooting.index-build-fails)
+ [バックグラウンドインデックスビルドのレイテンシーの問題と失敗](#troubleshooting.background-index-build-fails)
+ [データベースインデックスの肥大化](#troubleshooting-database-bloat)
## インデックスの構築が失敗する
Amazon DocumentDB は、インデックス作成プロセスの一部としてローカルストレージをインスタンス上で使用します。[**FreeLocalStorage**] CloudWatch メトリクス (`CloudWatch -> Metrics -> DocDB -> Instance Metrics`) を使用して、このディスクの使用状況をモニタリングできます。インデックスの構築がすべてのローカルディスクを消費して失敗すると、エラーが発生します。Amazon DocumentDB にデータを移行する場合、まずインデックスを作成してからデータを挿入することをお勧めします。移行戦略やインデックスの作成については、Amazon DocumentDB のドキュメントや「[オフラインメソッドを使用して、MongoDB から Amazon DocumentDB に移行する](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/)」のブログで [Amazon DocumentDB への移行](docdb-migration.md) を参照してください。
既存のクラスターでインデックスを作成するときに、インデックスの構築に予想以上の時間がかかる場合、または失敗する場合、まずインスタンスをスケールアップし、インデックスが作成されたらスケールバックして戻すことが推奨されます。Amazon DocumentDB では、 AWS マネジメントコンソール または を使用してインスタンスサイズを数分ですばやくスケーリングできます AWS CLI。詳細については、「[インスタンスクラスの管理](db-instance-classes.md)」を参照してください。秒単位のインスタンス料金によって、使用したリソースの秒数分のみを支払います。
## バックグラウンドインデックスビルドのレイテンシーの問題と失敗
Amazon DocumentDB のバックグラウンドインデックスビルドは、インデックスビルドが開始される前に開始されたプライマリインスタンス上のすべてのクエリの実行が完了するまで開始されません。クエリが長時間実行されている場合、バックグラウンドインデックスビルドはクエリが終了するまでブロックされるため、完了までに予想以上に時間がかかることがあります。コレクションが空であるとしても同様です。
フォアグラウンドインデックスビルドは、同じブロッキング動作を示しません。代わりに、フォアグラウンドインデックスビルドは、インデックスのビルドが完了するまで、コレクションを排他的にロックします。したがって、空のコレクションにインデックスを作成し、長時間実行されるクエリでブロックされないようにするには、フォアグラウンドインデックスビルドを使用することをお勧めします。
**注記**
Amazon DocumentDB では、任意の時点でコレクションにおいてバックグラウンドインデックスの作成が 1 つのみ許可されます。バックグラウンドインデックスの作成中に `createIndex()` や `dropIndex()` などの DDL (データ定義言語) オペレーションが発生すると、バックグラウンドインデックスの作成は失敗します。
## データベースインデックスの肥大化
Amazon DocumentDB は、複数バージョンの同時実行制御 (MVCC) を使用して同時トランザクションを管理します。ドキュメントを削除または更新しても、以前のバージョンはコレクションとインデックスに「デッド」バージョンとして残ります。ガベージコレクションプロセスは、将来のオペレーションのために、これらのデッドバージョンからスペースを自動的に再利用します。
インデックスの肥大化は、デッドインデックスエントリや古いインデックスエントリの蓄積、またはページ内のフラグメント化により、コレクションのインデックスが大きくなった場合に発生します。レポートされる割合は、将来のインデックスエントリで使用できるインデックススペースの量を表します。この肥大化は、バッファキャッシュとストレージの両方の領域を消費します。肥大化を削除する場合は、インデックスを再構築する必要があります。
**Example 例**
次のコマンドを実行して、インデックスの未使用のストレージを確認します。
```
db.coll.aggregate({$indexStats:{}});
```
結果は以下のようになります。
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
`reIndex` コマンドを使用して、ダウンタイムなしでインデックスを再構築できます。これには、コレクション全体のスキャンが必要です。「[`reIndex` を使用したインデックスのメンテナンス](managing-indexes.md#reIndex)」を参照してください。
# パフォーマンスとリソース使用率のトラブルシューティング
このセクションでは、Amazon DocumentDB デプロイにおける一般的な診断の問題に関する質問と解決策を示します。提供されている例では *mongo シェル*を使用し、個々のインスタンスに範囲を設定しています。インスタンスエンドポイントを見つけるには、「[Amazon DocumentDB エンドポイントについて](endpoints.md)」を参照してください 。
**Topics**
+ [Mongo API を使用してコレクションに対して実行された挿入、更新、削除操作の数を確認する方法](#user-diag-performed-operations)
+ [キャッシュのパフォーマンスを分析する方法](#user-diag-cache-perf)
+ [長時間実行されているクエリやブロックされているクエリを見つけて終了する方法](#user_diagnostics-query_terminating)
+ [クエリプランを参照してクエリを最適化する方法](#user_diagnostics-query_plan)
+ [Elastic クラスターのクエリプランを確認する方法](#user-diagnostics-ec-query-plan)
+ [インスタンスで実行中のすべての操作をリストする方法](#user_diagnostics-list_queries)
+ [クエリの進捗状況を知る方法](#user_diagnostics-query_progressing)
+ [システムの実行速度が突然遅くなった理由を判断する方法](#user_diagnostics-speed_change)
+ [1 つ以上のクラスターインスタンスで CPU 使用率が高くなる原因を特定する方法](#user_diagnostics-cpu_utilization)
+ [インスタンスで開いているカーソルを確認する方法](#user_diagnostics-open_cursors)
+ [現在の Amazon DocumentDB エンジンのバージョンを確認する方法](#user_diagnostics-engine_version)
+ [インデックスの使用状況を分析し、未使用のインデックスを特定する方法](#user-diag-index-usage)
+ [欠落しているインデックスを特定する方法](#user_diagnostics-identify_missing_indexes)
+ [データベースコレクションの肥大化を確認するにはどうすればよいですか?](#performance-collection-bloat)
+ [便利なクエリの概要](#user_diagnostics-useful_queries)
## Mongo API を使用してコレクションに対して実行された挿入、更新、削除操作の数を確認する方法
特定のコレクションに対して実行された挿入、更新、削除操作の数を表示するには、そのコレクションで以下のコマンドを実行します。
```
db.collection.stats()
```
このコマンドの出力は、`opCounters` フィールドの下に以下のように記述されています。
+ **numDocsIns**: このコレクションに挿入されたドキュメントの数。これには、`insert` および `insertMany` コマンドを使用して挿入されたドキュメントと、アップサートによって挿入されたドキュメントが含まれます。
+ **numDocsUpd**: このコレクションで更新されたドキュメントの数。これには、`update` および `findAndModify` コマンドを使用して更新されたドキュメントが含まれます。
+ **NumDocsDel**: このコレクションから削除されたドキュメントの数。これには `deleteOne`、`deleteMany`、`remove`、および `findAndModify` コマンドを使用して削除されたドキュメントも含まれます。
+ **LastReset**: これらのカウンタが最後にリセットされた時刻。このコマンドによって提供される統計は、クラスターを起動/停止したり、インスタンスをスケールアップ/スケールダウンしたりするとリセットされます。
以下に示しているのは、`db.collection.stats()` 実行時の出力例です。
```
{
"ns" : "db.test",
"count" : ...,
"size" : ...,
"avgObjSize" : ...,
"storageSize" : ...,
"capped" : false,
"nindexes" : ...,
"totalIndexSize" : ...,
"indexSizes" : {
"_id_" : ...,
"x_1" : ...
},
"collScans" : ...,
"idxScans" : ...,
"opCounter" : {
"numDocsIns" : ...,
"numDocsUpd" : ...,
"numDocsDel" : ...
},
"cacheStats" : {
"collBlksHit" : ...,
"collBlksRead" : ..,
"collHitRatio" : ...,
"idxBlksHit" : ...,
"idxBlksRead" : ...,
"idxHitRatio" : ...
},
"lastReset" : "2022-09-02 19:41:40.471473+00",
"ok" : 1,
"operationTime" : Timestamp(1662159707, 1)
}
```
この stats コマンドは、Mongo API を使用して挿入、更新、削除操作を行うコレクション固有のカウンターを表示する場合に使用してください。コレクション固有の操作カウンターを表示するもう 1 つの方法は、DML 監査を有効にすることです。[Amazon DocumentDB と CloudWatch のモニタリング](cloud_watch.md) では、1 分間隔で発生した全コレクションの挿入、更新、削除操作の数を表示できます。
## キャッシュのパフォーマンスを分析する方法
キャッシュのパフォーマンスを分析することで、データ取得の効率とシステムパフォーマンスを把握できます。分析は、キャッシュとディスクから読み取られるデータの量に基づいています。キャッシュのパフォーマンスを把握するために、キャッシュヒット (キャッシュから読み取られたデータ) とキャッシュミス (キャッシュに見つからず、ディスクから読み取られたデータ) の数に関するキャッシュ統計を提供します。特定のコレクションのキャッシュ統計は、そのコレクションで以下のコマンドを実行すると確認できます。
```
db.collection.stats()
```
このコマンドの出力の `cacheStats` フィールドの値は、コレクションのキャッシュ統計と、コレクション上に作成されたインデックスの合計キャッシュ統計を提供します。これらの統計を以下に示します。
+ **`collBlksHit`**: このコレクションの操作中にキャッシュから読み取られたブロック数。
+ **`collBlksRead`**: このコレクションの操作中にディスクから読み込まれた (キャッシュミス) ブロック数。
+ **`collHitRatio`**: このコレクションのキャッシュヒット率 (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`)。
+ **`idxBlksHit`**: このコレクションで作成されたインデックスのキャッシュから読み取られたブロック数。
+ **`idxBlksRead`**: このコレクションで作成されたインデックスのディスクから読み込まれた (キャッシュミス) ブロック数。
+ `idxHitRatio`: このコレクションで作成されたインデックスのキャッシュヒット率 (`100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`)。
+ **`lastReset`**: これらの統計が最後にリセットされた時刻。`db.collection.stats()` によって提供される統計は、クラスターを起動/停止したり、インスタンスをスケールアップ/スケールダウンしたりするとリセットされます。
各インデックスの `idxBlksHit` および `idxBlksRead` フィールドの内訳は、`indexStats` コマンドを使用して確認することもできます。インデックス固有のキャッシュ統計は、以下のコマンドを実行して参照できます。
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
各インデックスについて、以下のキャッシュ統計が `cacheStats` フィールドの下に表示されます。
+ **`blksHit`**: このインデックスのキャッシュから読み取られるブロック数。
+ **`blksRead`**: このインデックスのディスクから読み取られるブロック数。
+ **`blksHitRatio`**: キャッシュヒット率は、`100 * [blksHit / (blksHit + blksRead)]` で計算され、小数点以下 4 桁に四捨五入されました。
## 長時間実行されているクエリやブロックされているクエリを見つけて終了する方法
ユーザークエリの実行は、最適でないクエリプランのために遅くなることも、リソースの競合のためにブロックされる可能性もあります。
クエリプランが最適でないために長時間実行されているクエリ、またはリソースの競合のためにブロックされているクエリを見つけるには、`currentOp` コマンドを使用します。コマンドをフィルタリングすると、終了する関連クエリのリストを絞り込むことができます。クエリを終了できるようにするには、長時間実行されているクエリに `opid` を関連付ける必要があります。
次のクエリでは、`currentOp` コマンドを使用して、ブロックされている、または 10 秒以上実行されているクエリをすべてリストします。
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or: [
{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0, opid: 1, secs_running: 1}}],
cursor: {}
});
```
次に、クエリを絞り込み、10 秒以上実行されているクエリの `opid` を見つけて終了できます。
**10 秒以上実行されているクエリを見つけ出して終了するには**
1. クエリの `opid` を見つけます。
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or:
[{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}}],
cursor: {}
});
```
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 24646,
"secs_running" : 12
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
1. `killOp` オペレーションを使用してクエリを終了します。
```
db.adminCommand({killOp: 1, op: 24646});
```
## クエリプランを参照してクエリを最適化する方法
クエリの実行が遅い場合は、関連するドキュメントを選択するためにクエリの実行でコレクションのフルスキャンが必要である可能性があります。場合によっては、適切なインデックスの作成により、クエリの実行を高速化できます。このシナリオを検出し、インデックスを作成するフィールドを決定するには、`explain` コマンドを使用します。
**注記**
Amazon DocumentDB は分散型で耐障害性が高く、自己復旧ストレージシステムを利用する専用データベースエンジンで MongoDB 3.6 API をエミュレートしています。その結果、Amazon DocumentDB と MongoDB では、クエリプランと `explain()` の出力が異なる場合があります。クエリプランを制御する場合は、`$hint` 演算子を使用して優先インデックスの選択を強制できます。
次のように、`explain` コマンドで改善対象のクエリを実行します。
```
db.runCommand({explain: {}})
```
以下に示しているのは、オペレーションの例です。
```
db.runCommand({explain:{
aggregate: "sample-document",
pipeline: [{$match: {x: {$eq: 1}}}],
cursor: {batchSize: 1}}
});
```
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "COLLSCAN"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
前述の出力は、`$match` ステージでコレクション全体をスキャンし、各ドキュメントのフィールド `"x"` が 1 に等しいかどうか確認する必要があることを示しています。コレクションに多くのドキュメントがある場合、コレクションのスキャン（および全体的なクエリのパフォーマンス）は非常に低速になります。したがって、`explain` コマンドの出力に `"COLLSCAN"` が存在することは、適切なインデックスを作成することで、クエリのパフォーマンスを向上できることを示します。
この例では、クエリはすべてのドキュメントでフィールド `"x"` が 1 と等しいかどうかを確認します。したがって、フィールド `"x"` でインデックスを作成すると、クエリは完全なコレクションスキャンを回避し、インデックスを使用して関連ドキュメントをより早く返すことができます。
フィールド `"x"` でインデックスを作成した後、`explain` 出力は次のようになります。
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
フィールド `"x"` にインデックスを作成すると、`$match` ステージはインデックススキャンを使用して、述語 `"x = 1"` を評価する必要があるドキュメントの数を減らすことができます。
小規模なコレクションで、パフォーマンスの向上がごくわずかである場合、Amazon DocumentDB クエリプロセッサはインデックスを使用しないことがあります。
## Elastic クラスターのクエリプランを確認する方法
Elastic クラスターのクエリプランを調べるには、`explain` コマンドを使用します。以下は、シャードコレクションを対象とする検索クエリの `explain` 操作の例です。
```
db.runCommand(
{
explain: { find: "cities", filter: {"name": "Seoul"}}
}
)
```
**注記**
Amazon DocumentDB は、目的別データベースエンジンで MongoDB をエミュレートします。その結果、クエリプランと `explain()` の出力は、Amazon DocumentDB と MongoDB の間で異なる場合があります。`$hint` オペレーターを使ってクエリプランを制御し、優先インデックスの選択を強制することができます。
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"queryPlanner" : {
"elasticPlannerVersion" : 1,
"winningPlan" : {
"stage" : "SINGLE_SHARD",
"shards" : [
{
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "SHARD_MERGE",
"shards" : [
{
"shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 22
}
]
}
}
]
},
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
}
]
}
},
"serverInfo" : {
"host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
"version" : "5.0.0"
},
"ok" : 1,
"operationTime" : Timestamp(1695097923, 1)
}
```
上記の出力は、3 つのシャードクラスターでの `find` クエリのクエリプランを示しています。各シャードには複数のデータパーティションがあり、それぞれ異なる入力ステージを設定できます。この例では、各シャード内の「PARTITION\$1MERGE」ステージで結果がマージされる前に、すべてのパーティションで「COLLSCAN」 (コレクションスキャン) が実行されます。その後、シャード全体の結果は「SHARD\$1MERGE」ステージでマージされ、その後クライアントに送り返されます。
## インスタンスで実行中のすべての操作をリストする方法
ユーザーまたはプライマリユーザーが、診断およびトラブルシューティングのために、インスタンスで実行されている現在のすべてのオペレーションをリストアップしたい場合があります。（ユーザーの管理の詳細については、[Amazon DocumentDB ユーザーの管理](security.managing-users.md) を参照してください。）
`mongo` シェルで、次のクエリを使用して、Amazon DocumentDB インスタンスで実行中のすべてのオペレーションをリストできます。
```
db.adminCommand({currentOp: 1, $all: 1});
```
クエリは、インスタンス上で現在動作しているすべてのユーザークエリと内部システムタスクの完全なリストを返します。
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"inprog" : [
{
"desc" : "INTERNAL"
},
{
"desc" : "TTLMonitor",
"active" : false
},
{
"client" : ...,
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 195,
"ns" : "admin.$cmd",
"command" : {
"currentOp" : 1,
"$all" : 1
},
"op" : "command",
"$db" : "admin",
"secs_running" : 0,
"microsecs_running" : NumberLong(68),
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
}
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionA"
},
"secs_running": 3,
"microsecs_running": NumberLong(3123456)
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionB"
},
"secs_running": 4,
"microsecs_running": NumberLong(4123456)
}
],
"ok" : 1
}
```
次に示すのは、`"desc"` フィールドの有効な値です。
+ **INTERNAL** - カーソルのクリーンアップや古いユーザーのクリーンアップタスクなどの内部システムタスク。
+ **TTLMonitor** - 有効期限 (TTL) モニタリングスレッド。その実行ステータスが `"active"` フィールドに反映されています。
+ **GARBAGE\$1COLLECTION** - 内部ガベージコレクタースレッド。
+ **CONN** - ユーザーのクエリ。
+ **CURSOR** — 操作はユーザーが「getMore」コマンドを呼び出して次の結果のバッチを取得するのを待っているアイドルカーソルです。この状態では、カーソルはメモリを消費していますが、計算は消費されません。
前の出力では、システムで実行されているすべてのユーザークエリもリストされます。各ユーザークエリはデータベースとコレクションのコンテキストで実行され、これらの 2 つを統合したものが、*名前空間*と呼ばれます。各ユーザークエリの名前空間は、`"ns"` フィールドで利用できます。
特定の名前空間で実行されているすべてのユーザークエリをリストする必要がある場合があります。したがって、前の出力は `"ns"` フィールドでフィルタリングする必要があります。次にフィルター処理の出力を達成するためのクエリの例を示します。クエリは、データベース `"db"` とコレクション `"test"`（つまり、`"db.test"` 名前空間）で現在実行されているすべてのユーザークエリをリストします。
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$match: {ns: {$eq: "db.test"}}}],
cursor: {}
});
```
システムのプライマリユーザーは、すべてのユーザーのクエリと、すべての内部システムタスクを確認できます。他のすべてのユーザーは、各自のクエリのみを表示できます。
クエリと内部システムタスクの合計数が、デフォルトのバッチカーソルサイズを超えている場合、`mongo` シェルは残りの結果を表示するイテレーターオブジェクト `'it'` を自動的に生成します。すべての結果がなくなるまで、コマンド `'it'` の実行を継続します。
## クエリの進捗状況を知る方法
ユーザーのクエリは、最適とはいえないクエリプランが原因で実行速度が遅くなったり、リソースの競合が原因でブロックされたりすることがあります。このようなクエリのデバッグは複数ステップのプロセスであり、同じステップを複数回実行することが必要になる場合があります。
デバッグの最初のステップでは、長時間実行されているか、ブロックされているすべてのクエリをリストします。次のクエリは、10 秒以上実行されているか、リソースを待機しているすべてのユーザークエリをリストします。
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
前述のクエリを定期的に繰り返して、クエリのリストが変更されているかどうかを確認し、実行時間が長いクエリまたはブロックされているクエリを識別します。
対象のクエリの出力ドキュメントに `WaitState` フィールドがある場合、クエリの実行が低速であるかブロックされている理由は、リソースの競合であることを示しています。リソースの競合は、I/O、内部システムタスク、またはその他のユーザークエリが原因である可能性があります。
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 201,
"command" : {
"aggregate" : ...
},
"secs_running" : 208,
"WaitState" : "IO"
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
同じインスタンスで同時に実行されているさまざまなコレクションで多くのクエリが実行されているか、クエリを実行中のデータセットのインスタンスサイズが小さすぎると、I/O がボトルネックとなる場合があります。クエリが読み取り専用クエリである場合、各コレクションのクエリを別々のレプリカに分離することで、以前の状況を軽減できます。さまざまなコレクション間で同時更新を行う場合、またはデータセットに対するインスタンスサイズが小さすぎる場合の軽減策は、インスタンスをスケールアップすることです。
リソースの競合の原因が他のユーザークエリである場合、出力ドキュメントの `"blockedOn"` フィールドに、このクエリに影響しているクエリの `"opid"` が含まれます。`"opid"` を使用して、すべてのクエリの `"WaitState"` および `"blockedOn"` フィールドのチェーンに従って、チェーンの先頭にあるクエリを調べます。
チェーンの先頭にあるタスクが内部タスクである場合の唯一の緩和策は、クエリを終了し、後で再実行することです。
以下は、検索クエリが別のタスクによって所有されているコレクションロックでブロックされるサンプル出力です。
```
{
"inprog" : [
{
"client" : "...",
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 75,
"ns" : "...",
"command" : {
"find" : "...",
"filter" : {
}
},
"op" : "query",
"$db" : "test",
"secs_running" : 9,
"microsecs_running" : NumberLong(9449440),
"threadId" : 24773,
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
},
"WaitState" : "CollectionLock",
"blockedOn" : "INTERNAL"
},
{
"desc" : "INTERNAL"
},
{
"client" : "...",
...
"command" : {
"currentOp" : 1
},
...
}
],
"ok" : 1
}
```
`"WaitState"` の値が `"Latch"`、`"SystemLock"`、`"BufferLock"`、`"BackgroundActivity"`、または `"Other"` の場合、リソース競合の原因は内部システムタスクにあります。この状態が長時間続く場合、唯一の緩和策は、クエリを終了し、後で再実行することです。
## システムの実行速度が突然遅くなった理由を判断する方法
以下にシステムの速度が低下する一般的な理由を示します。
+ 同時クエリ間の過剰なリソースの競合
+ 時間の経過とともに増加するアクティブな同時クエリの数
+ `"GARBAGE_COLLECTION"` などの内部システムタスク
時間の経過とともにシステムの使用状況をモニタリングするには、以下の `"currentOp"` クエリを定期的に実行し、外部ストアに結果を出力します。クエリは、システムの各名前空間内のクエリとオペレーションの数をカウントします。次に、システムの使用状況の結果を分析し、システムへの負荷を把握して適切なアクションを行うことができます。
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
このクエリは、各名前空間で実行されているすべてのクエリとすべての内部システムタスクの合計を返します。また、名前空間ごとに存在する場合は、待機状態の一意の数を返します。
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"_id" : {
"desc" : "Conn",
"ns" : "db.test",
"WaitState" : "CollectionLock"
},
"count" : 2
},
{
"_id" : {
"desc" : "Conn",
"ns" : "admin.$cmd"
},
"count" : 1
},
{
"_id" : {
"desc" : "TTLMonitor"
},
"count" : 1
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
上記の出力では、コレクションロックでブロックされている名前空間 `"db.test"` に 2 つのユーザークエリ、名前空間 `"admin.$cmd"` に 1 つのクエリ、および 1 つの内部 `"TTLMonitor"` タスクがあります。
出力が、ブロック待機状態の多くのクエリを示す場合は、「[長時間実行されているクエリやブロックされているクエリを見つけて終了する方法](#user_diagnostics-query_terminating)」を参照してください。
## 1 つ以上のクラスターインスタンスで CPU 使用率が高くなる原因を特定する方法
以下のセクションは、インスタンスの CPU 使用率が高い原因を特定するのに役立ちます。結果は、ワークロードによって異なります。
+ インスタンスが突然遅くなる原因を特定するには、「[システムの実行速度が突然遅くなった理由を判断する方法](#user_diagnostics-speed_change)」を参照してください。
+ 特定のインスタンスで長時間実行されるクエリを特定して終了するには、「[長時間実行されているクエリやブロックされているクエリを見つけて終了する方法](#user_diagnostics-query_terminating)」を参照してください。
+ クエリが進行中かどうかを理解するには、「[クエリの進捗状況を知る方法](#user_diagnostics-query_progressing)」を参照してください。
+ クエリの実行に時間がかかる理由を確認するには、「[クエリプランを参照してクエリを最適化する方法](#user_diagnostics-query_plan)」を参照してください。
+ 実行時間が長いクエリを長期間にわたって追跡するには、「[Amazon DocumentDB オペレーションのプロファイリング](profiling.md)」を参照してください 。
インスタンスの CPU 使用率が高い理由に応じて、以下の 1 つ以上の操作を行うと役立ちます。
+ プライマリインスタンスで高い CPU 使用率が示され、レプリカインスタンスではそうではない場合、クライアントの読み込み優先設定（`secondaryPreferred` など）を使用してレプリカ間で読み込みトラフィックを分散することを検討してください。詳細については、「[レプリカセットとしての Amazon DocumentDB に接続する](connect-to-replica-set.md)」を参照してください。
レプリカを読み込みに使用すると、プライマリインスタンスでより多くの書き込みトラフィックを処理できるようになり、クラスターのリソースをより有効に活用できます。レプリカからの読み込みには結果整合性があります。
+ CPU 使用率が高いことが書き込みワークロードの結果である場合、クラスターのインスタンスのサイズをより大きいインスタンスタイプに変更すると、ワークロードに対応する CPU コアの数が増えます。詳細については、「[インスタンス](what-is.md#what-is-db-instances)」および「[インスタンスクラスの仕様](db-instance-classes.md#db-instance-class-specs)」を参照してください。
+ すべてのクラスターインスタンスで高い CPU 使用率が示され、ワークロードでレプリカが読み取りに使用されている場合、クラスターにレプリカを追加すると、読み取りトラフィックに使用できるリソースが増えます。詳細については、「[クラスターへの Amazon DocumentDB インスタンスの追加](db-instance-add.md)」を参照してください。
## インスタンスで開いているカーソルを確認する方法
Amazon DocumentDB インスタンスに接続している場合、コマンド `db.runCommand("listCursors")` を使用して、そのインスタンスで開いているカーソルを一覧表示できます。特定の Amazon DocumentDB インスタンスで特定の時間に開くことができる 4,560 個までのアクティブカーソルの数は 4,560 個に制限されています。インスタンスタイプによって異なります。通常、カーソルはインスタンスのリソースを消費し、開いている数に上限があるため、不要になったカーソルは閉じることをお勧めします。特定の制限については「[Amazon DocumentDB のクォータと制限事項](limits.md)」を参照してください。
```
db.runCommand("listCursors")
```
## 現在の Amazon DocumentDB エンジンのバージョンを確認する方法
現在の Amazon DocumentDB エンジンのバージョンを確認するには、次のコマンドを実行します。
```
db.runCommand({getEngineVersion: 1})
```
このオペレーションによる出力は、次のようになります (JSON 形式)。
```
{ "engineVersion" : "2.x.x", "ok" : 1 }
```
**注記**
Amazon DocumentDB 3.6 のエンジンバージョンは 1.x.x、Amazon DocumentDB 4.0 のエンジンバージョンは 2.x.x、Amazon DocumentDB 5.0 のエンジンバージョンは 3.x.x、Amazon DocumentDB 8.0 のエンジンバージョンは 4.x.x です。
## インデックスの使用状況を分析し、未使用のインデックスを特定する方法
特定のコレクションのインデックスを識別するには、次のコマンドを実行します。
```
db.collection.getIndexes()
```
コレクションに対して実行された操作中にどれだけのインデックスが使用されているかを分析するには、`collStats` および `indexStats` コマンドを使用できます。インデックスを使用して実行されたスキャン (インデックススキャン) の総数とインデックスなしで実行されたスキャンの数 (コレクションスキャン) を比較するには、次のコマンドを実行します。
```
db.collection.stats()
```
このコマンドの出力には、以下の値が含まれます。
+ **`idxScans`**: インデックスを使用してこのコレクションに対して実行されたスキャンの数。
+ **`collScans`**: インデックスを使用せずにこのコレクションに対して実行されたスキャンの数。これらのスキャンでは、コレクション内のドキュメントを一度に 1 つずつ調べる必要がありました。
+ **`lastReset`**: これらのカウンタが最後にリセットされた時刻。このコマンドによって提供される統計は、クラスターを起動/停止したり、インスタンスをスケールアップ/スケールダウンしたりするとリセットされます。
各インデックスの使用量の内訳は、次のコマンドの出力で参照できます。パフォーマンスを向上させ、コストを削減するために、ベストプラクティスとして、未使用のインデックスを定期的に識別して削除することをお勧めします。インデックスを維持するために不必要なコンピューティング、ストレージ、I/O が使用されなくなるためです。
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
このコマンドの出力では、コレクションで作成された各インデックスについて次の値が表示されます。
+ **`ops`** - インデックスを使用したオペレーションの数。ワークロードが十分に長時間実行されており、ワークロードが安定していることがはっきりわかる場合、`ops` 値 0 は、インデックスがまったく使用されていないことを示しています。
+ **`numDocsRead`**: このインデックスを使用する操作中に読み取られたドキュメントの数。
+ **`since`** - インデックス使用状況に関する統計情報の収集が Amazon DocumentDB により開始されてからの時間。通常は、前回のデータベース再起動またはメンテナンスアクション以降の値です。
+ **`size`** - このインデックスのサイズをバイト数で表す。
次の例は、上記のコマンドを実行したときの出力例です。
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
{
"name" : "x_1",
"key" : {
"x" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
```
コレクションの全体的なインデックスサイズを確認するには、次のコマンドを実行します。
```
db.collection.stats()
```
未使用のインデックスを削除するには、次のコマンドを実行します。
```
db.collection.dropIndex("indexName")
```
## 欠落しているインデックスを特定する方法
[Amazon DocumentDB プロファイラを使用して、低速なクエリをログに記録](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html) できます。低速なクエリのログに繰り返し現れるクエリがある場合、そのクエリのパフォーマンスを向上させるために追加のインデックスが必要であることを示している可能性があります。
少なくとも 1 つの `COLLSCAN` ステージで実行される 1 つ以上のステージを持つ長時間実行クエリ (つまり、クエリのステージは、クエリへのレスポンスを生成するために、コレクション内のすべてのドキュメントを読み取る必要がある) を探すと、どのインデックスが役に立つ可能性があるかを見分けることができます。
次の例は、大規模なコレクションで実行されたタクシー乗車のコレクションに対するクエリを示しています。
```
db.rides.count({"fare.totalAmount":{$gt:10.0}}))
```
この例を実行するには、`fare.totalAmount` フィールドにインデックスがないため、クエリはコレクションスキャン (つまり、コレクション内のすべてのドキュメントを読み込む) を実行する必要がありました。このクエリの Amazon DocumentDB プロファイラからの出力は、次のようになります。
```
{
...
"cursorExhausted": true,
"nreturned": 0,
"responseLength": 0,
"protocol": "op_query",
"millis": 300679,
"planSummary": "COLLSCAN",
"execStats": {
"stage": "COLLSCAN",
"nReturned": "0",
"executionTimeMillisEstimate": "300678.042"
},
"client": "172.31.5.63:53878",
"appName": "MongoDB Shell",
"user": "example"
}
```
この例のクエリを高速化するには、以下に示すように `fare.totalAmount` にインデックスを作成します。
```
db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
```
**注記**
フォアグラウンドで作成されたインデックス (つまり、インデックスの作成時に `{background:true}` オプションが指定されなかった場合) は、排他的な書き込みロックを使用します。これにより、インデックス構築が完了するまでアプリケーションがコレクションにデータを書き込めなくなります。本番稼働クラスターでインデックスを作成する場合は、このような影響が生じる可能性がある点に注意してください。インデックスを作成するときは、`{background:true}` を設定することをお勧めします。
一般に、カーディナリティが高いフィールド (たとえば、多数の一意の値) でインデックスを作成します。カーディナリティの低いフィールドにインデックスを作成すると、使用されないインデックスが大きくなることがあります。Amazon DocumentDB クエリオプティマイザは、クエリプランの作成時に、コレクション全体のサイズとインデックスの選択性を考慮します。インデックスが存在する場合でも、クエリプロセッサが `COLLSCAN` を選択することがあります。これは、インデックスを利用しても、コレクション全体をスキャンした場合よりパフォーマンスが高くならないとクエリプロセッサが推定したときに発生します。特定のインデックスの利用をクエリプロセッサに強制する場合、以下に示すように、`hint()` 演算子を使用できます。
```
db.collection.find().hint("indexName")
```
## データベースコレクションの肥大化を確認するにはどうすればよいですか?
コレクションの肥大化は、デッドドキュメントや古いドキュメントの蓄積、またはデータベースページ内のフラグメント化により、コレクションのサイズが大きくなった場合に発生します。レポートされる割合は、将来のドキュメントで使用できるドキュメントスペースの量を表します。この肥大化は、バッファキャッシュとストレージの両方の領域を消費します。肥大化を取り除くには、ダンプ/復元、またはメンテナンスウィンドウ中の移行ループバックとスイッチオーバーを使用してコレクションを再ロードする必要があります。
**Example 例**
次のコマンドを実行して、コレクションの未使用のストレージを確認します。
```
db.runCommand({collStats:'coll'})
```
結果は以下のようになります。
```
{
"ns" : "test.coll",
"count" : 7500,
"size" : 23250,
"avgObjSize" : 31,
"storageSize" : 106496,
"unusedStorageSize" : {
"unusedBytes" : 16384,
"unusedPercent" : 25.12
},
"compression" : {
"enable" : false
},
"capped" : false,
"nindexes" : 1,
"totalIndexSize" : 57344,
"indexSizes" : {
"_id_" : 57344
},
"collScans" : 4,
"idxScans" : 10000,
"opCounter" : {
"numDocsIns" : 1000,
"numDocsUpd" : 0,
"numDocsDel" : 250
},
"cacheStats" : {
"collBlksHit" : 3570,
"collBlksRead" : 8,
"collHitRatio" : 99.7765,
"idxBlksHit" : 12293,
"idxBlksRead" : 6,
"idxHitRatio" : 99.9513
},
"lastReset" : "2024-12-18 00:30:21.552019+00",
"ok" : 1,
"operationTime" : Timestamp(1734632375, 1)
}
```
## 便利なクエリの概要
以下のクエリは、Amazon DocumentDB のパフォーマンスとリソース使用率をモニタリングするのに役立ちます 。
+ 以下のコマンドを使用して、オペレーションカウンター、キャッシュ統計、アクセス統計、サイズ統計など、特定のコレクションに関する統計を表示します。
```
db.collection.stats()
```
+ 以下のコマンドを使用して、コレクション上に作成された各インデックスに関する統計情報 (インデックスのサイズ、インデックス固有のキャッシュ統計、インデックス使用統計など) を表示します。
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
+ 次のクエリを使用して、すべてのアクティビティをリストします。
```
db.adminCommand({currentOp: 1, $all: 1});
```
+ 次のコードは、実行時間が長いクエリまたはブロックされたすべてのクエリをリストします。
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
+ 次のコードは、クエリを終了します。
```
db.adminCommand({killOp: 1, op: });
```
+ 次のコードを使用して、システム状態の集約ビューを取得します。
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
# Amazon DocumentDB のガベージコレクション
Amazon DocumentDB は、更新オペレーションごとにドキュメントエントリとインデックスエントリの新しいバージョンを作成するマルチバージョン同時実行制御 (MVCC) データベースアーキテクチャを実装します。このアーキテクチャにより、トランザクションの分離が可能になり、あるトランザクションの変更が別のトランザクションに表示されなくなります。
**Topics**
+ [Amazon DocumentDB のガベージコレクションについて](#understanding-garbage-collection)
+ [ガベージコレクションプロセス](#garbage-collection-process)
+ [ストレージアーキテクチャと拡張ストレージ](#storage-architecture)
+ [ガベージコレクションのモニタリング](#monitoring-garbage-collection)
+ [collStats 出力の例](#example-collstats-output)
+ [よくある質問](#garbage-collection-faq)
## Amazon DocumentDB のガベージコレクションについて
ガベージコレクション (GC) は、Amazon DocumentDB で最適なシステムパフォーマンスと可用性を維持する自動化されたバックグラウンドプロセスです。多くの最新のデータベースと同様に、Amazon DocumentDB の MVCC アーキテクチャは、更新ごとに新しいドキュメントバージョンとインデックスバージョンを作成します。各書き込みオペレーションは、有限カウンターから一意の MVCC ID を消費します。これらの IDsは、ドキュメントバージョンが属するトランザクションと、コミットされたかロールバックされたかを識別します。時間の経過とともに、これらの古いバージョンとその MVCC IDsが蓄積され、パフォーマンスの低下を防ぐためにクリーンアップが必要になります。
### ガベージコレクションの機能
ガベージコレクターには 3 つの重要な機能があります。
+ **ストレージスペースの再利用** — アクティブなクエリで不要になった古いドキュメントバージョンとインデックスバージョンを削除し、将来の書き込みオペレーションのためのスペースを解放します。
+ **MVCC ID オーバーフローの防止** — MVCC ID の有限カウンターを管理することで、MVCC ID のオーバーフローを防止します。この管理を行わないと、カウンターは最終的に制限に達し、ID がリサイクルされるまで、データベースを強制的に一時的な読み取り専用モードにします。
+ **クエリパフォーマンスを維持** — そうしない場合にクエリ処理が蓄積および遅くなるデッドドキュメントバージョンを排除することで、最適なクエリパフォーマンスを維持します。
## ガベージコレクションプロセス
GC プロセスはコレクションごとに動作し、異なるコレクションで複数のプロセスを同時に実行できます。このプロセスは 4 つのシーケンシャルフェーズで構成されます。
1. **識別** — システムは、アクティブなトランザクションまたはクエリによって参照されなくなったドキュメントバージョンとインデックスバージョンを識別します。
1. **メモリロード**—古いドキュメントとインデックスエントリがメモリに存在しない場合、メモリにロードされます。
1. **削除** — 古いバージョンは、ストレージ容量を再利用するために完全に削除されます。
1. **MVCC ID リサイクル** — システムは、新しいオペレーションのために、削除されたバージョンの MVCC ID をリサイクルします。
ガベージコレクションが古いドキュメントバージョンの処理を完了すると、システムから最も古い MVCC ID が削除されます。このクリーンアップは、MVCC ID をリサイクルして MVCC ID のオーバーフローを防ぎ、クラスター全体の新しい書き込みオペレーションで使用できるようにするために不可欠です。このリサイクルプロセスがないと、システムは最終的に有限の MVCC ID カウンターを使い果たし、読み取り専用状態になります。
### ガベージコレクションのスケジューリング
ガベージコレクションは、定期的にバックグラウンドで自動的に実行されます。タイミングと頻度は、システム負荷、使用可能なリソース、書き込み容量、MVCC ID 消費レベルに基づいて動的に調整されます。書き込みアクティビティが多い場合、GC プロセスはより頻繁に実行され、ドキュメントバージョン数の増加を管理します。
## ストレージアーキテクチャと拡張ストレージ
Amazon DocumentDB は、ドキュメントストレージを 2 つの異なるセグメントに分割する高度なストレージアーキテクチャを使用します。
### ベースストレージセグメント
ベースストレージセグメントには、プライマリドキュメントデータとメタデータが含まれます。このセグメントは以下を保存します。
+ 標準ページサイズ (8 KB) に収まるコンテンツを文書化します。
+ ドキュメントメタデータと構造情報。
+ プライマリインデックスとそのエントリ。
+ コレクションレベルの統計と設定。
### 拡張ストレージセグメント
拡張ストレージセグメントは、標準ストレージページサイズを超えるドキュメントを処理するように設計された特殊なラージドキュメントオブジェクトストアを使用します。このセグメントは以下を提供します。
+ **効率的な大規模ドキュメント処理 — **ベースストレージのしきい値を超えるドキュメントは、拡張ストレージセグメントに自動的に移動されます。
+ **最適化ストレージレイアウト** — セグメントは、大きなオブジェクト用に最適化された異なるストレージ形式を使用するため、断片化が軽減され、アクセスパターンが向上します。
+ **独立したガベージコレクション** — 拡張ストレージセグメントには、ベースストレージのクリーンアップとは独立して実行できる独自のガベージコレクションプロセスがあります。
+ **透過的なアクセス** — アプリケーションは、データを含むストレージセグメントを知ることなく、大規模なドキュメントにシームレスにアクセスします。
拡張ストレージセグメントは、以下にとって特に有益です。
+ 大きな埋め込み配列を含むドキュメントを含むコレクション。
+ 広範なネスト構造を持つドキュメント。
+ バイナリデータまたは大きなテキストフィールドを保存するコレクション。
+ 一部のドキュメントが平均サイズを大幅に超える、ドキュメントサイズが混在するアプリケーション。
## ガベージコレクションのモニタリング
### クラスターレベルのメトリクス
**`AvailableMVCCIds`**
+ **場所** — Amazon CloudWatch
+ **説明** — 最大制限 18 億から使用可能な残りの書き込みオペレーションの数を示すカウンター。このカウンターがゼロに達すると、ID が再利用されてリサイクルされるまで、クラスターは読み取り専用モードになります。カウンターは書き込みオペレーションごとに減少し、ガベージコレクションが古い MVCC ID をリサイクルすると増加します。
+ **推奨事項** — 値が 13 億を下回ったときにアラームを設定します。この早期警告により、後で説明する推奨手順を実行できます。
**`LongestActiveGCRuntime`**
+ **場所** — Amazon CloudWatch
+ **説明** — 最も長いアクティブなガベージコレクションプロセスの秒単位の期間。1 分ごとに更新し、1 分以内に完了したプロセスを除き、アクティブなオペレーションのみを追跡します。
+ **推奨事項** — `gcRuntimeStats`履歴データと比較して、一括削除中の拡張ランタイムなど、異常なガベージコレクション動作を特定します。
### コレクションレベルのメトリクス
**`MVCCIDStats: MVCCIdScale`**
+ **場所** — Database collStats コマンド
+ **説明** — 0～1 のスケールで MVCC ID の経過時間を測定します。1 は、クラスターが読み取り専用状態になる前の最大経過時間を示します。このメトリクスを `AvailableMVCCIds` と一緒に使用して、クラスターを古くしている最も古い MVCC ID を含むコレクションを識別します。
+ **推奨事項** — コレクションごとに 0.3 未満の値を維持します。
**`gcRuntimeStats`**
+ **場所** — Database collStats コマンド
+ **説明** — 合計実行数、平均期間、最大期間など、ガベージコレクションメトリクスの 2 か月の履歴を提供します。意味のある統計を確保するために 5 分以上続くガベージコレクションオペレーションのみが含まれます。
**重要**
`gcRuntimeStats`、`documentFragmentStats`、およびコレクションレベルのメトリクスの `storageSegmentBase`および への分割`storageSegmentExtended`は、Amazon DocumentDB 8.0 でのみ使用できます。
**`storageSizeStats`**
+ **場所** — Database collStats コマンド
+ **説明** — さまざまなストレージセグメントのストレージ使用率の詳細な内訳を示します。
+ `storageSegmentBase` — 標準ドキュメントのベースストレージセグメントで使用されるストレージ
+ `storageSegmentExtended` — ラージドキュメントの拡張ストレージセグメントで使用されるストレージ
+ **使用状況** — 大規模なドキュメントストレージを持つコレクションを特定し、ストレージの分散パターンを理解するのに役立ちます。
**`unusedStorageSize`** (コレクションレベル)
+ **場所** — Database collStats コマンド
+ **説明** — サンプル統計に基づいて、コレクション内の未使用のストレージ領域を推定します。削除されたドキュメントと空のセグメントからのスペースが含まれます。メトリクスは、合計とセグメントごとの内訳の両方を提供します。
+ すべてのストレージセグメント`unusedPercent`で `unusedBytes`と を結合
+ `storageSegmentBase` — 特にベースストレージセグメントで未使用のスペース
+ `storageSegmentExtended` — 拡張ストレージセグメントで特に未使用のスペース
**`documentFragmentStats`**
+ **場所** — Database collStats コマンド
+ **説明** — コレクション内のドキュメントフラグメントとデッドデータに関する詳細情報を提供します。ドキュメントフラグメントは、データベースエンジンで使用される内部ストレージユニットを表し、デッドフラグメントは、アクセスできなくなり、まだ再利用されていないデータを示します。このメトリクスには以下が含まれます。
+ `totalDocFragmentsCount` — コレクション内のドキュメントフラグメントの合計数
+ `deadDocFragmentsCount` — デッド (アクセスできない) データを含むフラグメントの数
+ `deadDocFragmentsPercent` — デッドデータを含むフラグメントの割合
+ `deadDocFragmentBytes` — デッドドキュメントフラグメントによって消費される推定バイト数
+ `storageSegmentBase` および のセグメントごとの内訳 `storageSegmentExtended`
+ **使用状況** — このメトリクスをモニタリングしてガベージコレクションの有効性を理解し、メンテナンスオペレーションの恩恵を受ける可能性のあるコレクションを特定します。デッドフラグメントの割合が高いことは、ガベージコレクションが遅れているか、コレクションが最適化の恩恵を受ける可能性があることを示しています。
### インデックスレベルのメトリクス
**`unusedStorageSize`** (インデックスレベル)
+ **場所** — データベース indexStats コマンド
+ **説明** — サンプル統計に基づいて、インデックス内の未使用のストレージ領域を推定します。これには、古いインデックスエントリと空のセグメントからのスペースが含まれます。
+ **推奨事項** — `reIndex` コマンドを使用してダウンタイムなしでインデックスを再構築し、未使用のスペースを再利用します。詳細については、「インデックスの管理」を参照してください。
## collStats 出力の例
次の例は、ガベージコレクションとストレージメトリクスを含む一般的な`collStats`出力を示しています。
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"unusedPercent" : 65.05
}
},
"cacheStats" : {
"collBlksHit" : 171659016,
"collBlksRead" : 754061,
"collHitRatio" : 99.5627,
"idxBlksHit" : 692563636,
"idxBlksRead" : 1177921,
"idxHitRatio" : 99.8303
},
"idxScans" : 41823984,
"opCounter" : {
"numDocsIns" : 0,
"numDocsUpd" : 20911992,
"numDocsDel" : 0
},
"lastReset" : "2025-06-24 05:57:08.219711+00",
"ok" : 1,
"operationTime" : Timestamp(1750968826, 1)
}
```
## よくある質問
### ガベージコレクションが効率的に機能していないかどうかを確認するにはどうすればよいですか?
非効率的なガベージコレクションを示す次の警告サインをモニタリングします。
+ **過剰なコレクション肥大化** — 特に大きなインデックスでは、大量の書き込みや一括削除中に`unusedStorageSize`メトリクスが着実に増加します。
+ **高いデッドフラグメントの割合 — **一貫して高い`deadDocFragmentsPercent`値 (10～15% 以上) `documentFragmentStats`を示します。
+ **クエリレイテンシーの低下** — デッドドキュメントの蓄積によるクエリレイテンシーの増加。
+ **延長 GC 期間** — ガベージコレクションオペレーションには、 の履歴平均よりも時間がかかります`gcRuntimeStats`。
+ **GC 処理の引き上げ** — ガベージコレクターがシステムの需要に追いついていない`LongestActiveGCRuntime`ことを示す高。
### ガベージコレクションはデータベースのパフォーマンスに影響しますか?
通常の条件下では、ガベージコレクションのパフォーマンスへの影響は最小限です。ただし、ガベージコレクションが遅れると、以下が発生する可能性があります。
+ 蓄積されたデッドドキュメントのストレージコストが増加しました。
+ 古いインデックスエントリにより、クエリのパフォーマンスが遅くなります。
+ MVCC IDsが枯渇した場合の一時的な読み取り専用モード。
+ 特に小規模なインスタンスでは、集中的な収集の実行中のリソース使用量が増加します。
+ 大規模なドキュメントの拡張ストレージセグメントオペレーションの効率が低下しました。
### ガベージコレクションを手動でトリガーできますか?
いいえ。Amazon DocumentDB のガベージコレクションを手動でトリガーすることはできません。システムは、内部メンテナンスオペレーションの一部としてガベージコレクションを自動的に管理します。
### 運用上のベストプラクティスとして設定する必要があるアラームは何ですか?
Amazon DocumentDB システムの最適なパフォーマンスを確保するために、クラスターレベルとコレクションレベルの両方でモニタリングをセットアップすることをお勧めします。
クラスターレベルのモニタリングでは、まずしきい値が 13 億の`AvailableMVCCIds`メトリクスの Amazon CloudWatch アラームを作成します。これにより、メトリクスが 0 に達する前にアクションを実行するのに十分な時間が与えられます。ゼロに達した時点で、クラスターは読み取り専用モードになります。このメトリクスは、特定の使用パターンに基づいて変動する場合があることに注意してください。一部のお客様は、ガベージコレクションが作業を完了すると 13 億を下回ってから 15 億を回復します。
また、Amazon CloudWatch を介して`LongestActiveGCRuntime`メトリクスをモニタリングすることも重要です。このメトリクスは、`gcRuntimeStats` とともに、システム全体でのガベージコレクションのパフォーマンスを理解するのに役立ちます。
コレクションレベルのモニタリングでは、次の主要なメトリクスに焦点を当てます。
+ `MVCCIdScale` — MVCC IDs が古くなっていて注意が必要な可能性があることを示す値の増加に注意してください。
+ `gcRuntimeStats` — ガベージコレクションプロセスが異常に長くかかるか、数日間にわたって延長されることを特定します。
+ `documentFragmentStats` — `deadDocFragmentsPercent`値をモニタリングする - 一貫して高い割合 (10～15%) は、ガベージコレクションが遅れていることを示している可能性があります。
+ `storageSizeStats` および `unusedStorageSize` — ストレージ使用率パターンを追跡し、いずれかのストレージセグメントに大量の未使用領域があるコレクションを特定します。
書き込みオペレーションが頻繁なコレクションでは、ガベージコレクターの作業が増えるため、特に注意が必要です。ガベージコレクションがワークロードに遅れないように、書き込みアクティビティが多いコレクションでは、これらのメトリクスをより頻繁にチェックすることをお勧めします。
これらのモニタリングレコメンデーションが出発点となることに注意してください。システムの動作に慣れたら、特定の使用パターンと要件に合わせてこれらのしきい値を調整することをお勧めします。
### `AvailableMVCCIds` が 13 億を下回った場合はどうすればよいですか?
`AvailableMVCCIds` メトリクスが 13 億を下回る場合は、クラスターが読み取り専用モードにならないようにすぐにアクションを実行することをお勧めします。まずインスタンスサイズをスケールアップして、ガベージコレクターにより多くのコンピューティングリソースを提供することをお勧めします。これは、アプリケーションが通常のオペレーションを継続し、ガベージコレクターに追いつくために必要な追加の能力を与えることができるため、当社の主な推奨事項です。
単独でスケールアップしても状況が改善しない場合は、書き込みオペレーションの削減を検討することをお勧めします。`MVCCIdScale` メトリクスを使用して、注意が必要な古い MVCC ID を含む特定のコレクションを特定します。さらに、モニタリング`documentFragmentStats`して、ガベージコレクションの非効率に寄与している可能性のあるデッドフラグメントの割合が高いコレクションを特定します。
これらのコレクションを特定したら、ガベージコレクションが追いつくことができるように、それらのコレクションへの書き込みオペレーションを一時的に減らす必要がある場合があります。復旧期間中は、`AvailableMVCCIds` メトリクスを注意深くモニタリングして、アクションが望ましい効果を持っていることを確認することをお勧めします。`AvailableMVCCIds` 値が 15 億以上に戻ると、クラスターは正常と見なされます。
これらのステップは、システムが重大な状態になる前に復旧するための予防策であることに注意してください。メトリクスが 13 億を下回った後に早くアクションを実行すればするほど、書き込みオペレーションへの影響を回避できる可能性が高くなります。