1.断片化を判断する方法

1.データベーススペースの占有情報を照会します

1）データベースが占有しているストレージスペースを表示する

-- 通过db.stats()函数查询storageSize参数大小
use db
db.stats()
-- 直接查看目标DB物理存储大小
use db
db.runCommand({dbStats : 1,scale : 1073741824})   //scale指定单位为GB

2）コレクションが占めるストレージスペースを表示する

-- 通过db.collname.stats()函数查询storageSize参数大小
use db
db.collname.stats()
-- 直接查看目标DB物理存储大小
use db
db.runCommand({"collStats":"oplog.rs",scale:1048576})  //scale指定单位，单位为MB

2.断片化の問題を確認し、現在のコレクションの再利用可能なスペースを確認します

db.collname.stats().wiredTiger["block-manager"]["file bytes available for reuse"]

rs0:PRIMARY> db.aa.stats().wiredTiger["block-manager"]["file bytes available for reuse"]
16384

2.断片化に対処する方法

2.1コンパクト

1.文法

db.runCommand({compact:'dsir',force:true})

2.コンパクトには許可が必要です

use admin
db.createRole(
   {
      role: "myCustomCompactRole",
      privileges: [
         {
            resource: { "db" : "<database>" , "collection" : "<collection>" },
            actions: [ "compact" ]
         }
      ],
      roles: []
   }
)

db.grantRoleToUser("myCompactUser", [ "dbAdmin" | "myCustomCompactRole" ] )

3.コンパクトの主な操作は何ですか？

1）操作されたコンパクトコレクションが条件を満たすかどうかを確認します

スペースの最初の80％には、ファイルの背後にあるデータの20％を書き込むための20％の空きスペースがありますか
スペースの最初の90％には、ファイルの背後にあるデータの10％を書き込むための10％の空きスペースがありますか

2）いずれかの条件が満たされると、エンジンレイヤーはコンパクトの実行を開始し、実行中にDBの左右の読み取りおよび書き込み操作をブロックし、コレクションファイルの背後にあるデータを前面の空き領域に書き込みます。ファイルを徐々に切り捨てて、物理スペースを再利用します。

3）上記の条件のいずれかが満たされない場合、コンパクト実行では物理スペースの10％を再利用できないことを意味します。その場合、コレクションは現在コンパクトである必要はなく、コンパクト操作は直接終了します。

4.コンパクトの影響

1）コンパクトコレクションは、コレクションが配置されているDBの排他的書き込みロックを追加します。これにより、DBでのすべての読み取りおよび書き込み要求がブロックされます。コンパクトの実行時間は、データの量に関連します。データ量が多いほど、コンパクトの実行時間が長くなりますので、ビジネスへの影響を避けるため、ビジネスのピーク時の低い時間帯に実行することを強くお勧めします。

2）db.killOp（）メソッドを使用して操作を終了する場合、または圧縮操作が完了する前にサーバーを再起動する場合は、次の点に注意してください。

ロギングが有効になっている場合、データは圧縮操作のステータスに関係なく有効で使用可能なままになります。インデックスを手動で再構築する必要がある場合があります。
ロギングが有効になっていないと、コンパクト操作が中断されたときにデータの有効性が保証されません。
どちらの場合も、コレクション内の既存の空き領域のほとんどは再利用できない可能性があります。スペースの使用を回復するには、コンパクトを再実行する必要があります。

3）コンパクト操作は各ノードに依存せず、プライマリノードの操作でセカンダリノードに転送されません。

4）プライマリノードでコンパクトな操作を実行する場合は、forceを特定する必要があります。true;

5）セカンダリノードでコンパクト操作を実行すると、ノードの状態がRECOVERINGに変換され、その間、ビジネスはノードにアクセスできなくなります。

2.2各ストレージエンジンの下のコンパクトなリリーススペースはどのようになっていますか

1、WiredTiger

1）コンパクトな操作では、データとインデックススペースがオペレーティングシステムに解放されます
。2）コンパクトな実行には追加のスペースが必要です。

2、MMAPv1

1）commpact操作により、データスペースが削減され、インデックスが再構築されますが、これらのスペースはオペレーティングシステムに返されず、後続のデータ書き込みのためにMongoDBにのみ残されます
。2）のディスクスペースを再利用する場合MMAPv1、初期同期を実行する必要があります;
3）コンパクト操作の実行を実行するには、現在のインスタンスに少なくとも2Gの空き領域が必要です。

断片化に対処するための3つの一般的なソリューション

3.1直接操作

シングルノード環境
での直接コンパクト操作
レプリカセット環境では、
1）ビジネスの低ピーク時に、セカンダリノードでcompactコマンドを実行します
。2）
圧縮されたセカンダリノードをプライマリノードにプロモートします。3）ダウングレードされたノードを圧縮します。二次へ。

3.2コレクションの再構築

新しいセカンダリノードを追加してから、ノードをプライマリノードにアップグレードします（データ量が非常に多い場合にビジネスに影響を与えないようにするため）。

3.3シングルノード起動モードの循環処理

1）レプリカセット内のセカンダリノードをシングルノードとして起動し、compactコマンドを実行してコレクションの断片化を処理します

2）レプリカセットとして断片化されたノードを再起動すると、ノードはプライマリノードに昇格します

3）残りのセカンダリノードを1）の方法でフラグメント化します。

ドキュメントリファレンス：

https://docs.mongodb.com/manual/reference/command/compact/index.html
https://blog.csdn.net/u013162930/article/details/78580083

MongoDBディスクスペース断片化トラブルシューティングガイド

記事のディレクトリ