クラウドデータベースのMongoDBバージョンログのクリーンアップと詳細compactコマンド

問題の1説明:

今日はクラウドデータベースのMongoDBバージョンログのクリーンアップ作戦を見て、少し大きいoplog会社のMongoDBのを見ました。

頻繁に長期/書き込みデータや大量に削除されたのMongoDBデータベースは、大量のデータを削除し、物理的なスペースデブリの多くを生成します。

これらの作品は、ディスク領域を占有し、ディスクの使用率を削減します。

あなたは、書き換えや未使用領域を解放し、ディスク使用率とクエリのパフォーマンスを向上させるために、すべてのデータの収集とインデックスデフラグを実行することができます。

次の図は示しています。

前提条件

MongoのインスタンスストレージエンジンがWiredTigerです。

詳細については、

  • ユーザーの使用禁止  db.repairDatabase 命令を。
  • ログ領域が大きすぎる場合は、自動クリーンアップ作戦がトリガされます。

注意事項

  • この操作を実行する前に、データベースをバックアップすることをお勧めします
  • この操作は、コレクションにつながるデータベースに属しているロックされ、データベースの読み取りおよび書き込み操作がブロックされる、事業運営における低いピーク。
  • 説明:物理的空間回復コマンド(コンパクト)データ、システム負荷および他の要因の設定量に必要な時間行います。

削除し、その差をドロップ

すべての文書のMongoDBのコレクションを削除するには、2つの方法があります

  • db.collection.remove({}, {multi: true})一つの文書による一つはBTREEから取り出し、そして最終的にすべての文書は削除されますが、ファイルは物理的空間を回復することはありません
  • db.collection.drop() 物理ファイルのコレクションは、すぐに回収されるスペースを削除しました

マルチ:オプション、MongoDBのデフォルトは、このパラメータがtrueの場合、最初のレコードは、見つかった更新の条件はすべての更新をチェックするために多くのレコードを置くによると、偽です。

全体:

新しいデータは、物理的なスペースを使用するように書き込まれますので、シーンには、回収されないコマンドが頻繁に実行コンパクトは、物理的なスペースデブリを整理する必要はありません、書き込みデータを持続。

いくつかのシーンの後、大量のデータを削除するには、スペースを再利用したい場合は、以後の書き込みはあまりないかもしれません、そして、あなたは明示的にコンパクトを呼び出す必要があります。

何をすべきか、具体的圧縮?

ストレージエンジンWiredTiger、コンパクトの実装でWiredTiger後ろの空きスペースで確定コンパクトアクションは、データの収集は、王Qianmian書き込みをファイル続けます、

Truancateファイルは、その後、徐々に物理的なスペースを回復します。各ラウンドの前に、コンパクト、WTは、最初のコンプライアンスcomapact条件をチェックします。

  1. 前面80%的空间里,是否有20%的空闲空间,用于写入文件后面20%的数据,或者
  2. 前面90%的空间里,是否有10%的空闲空间,用于写入文件后面10%的数据

如果上面都不满足,说明执行compact肯定无法回收10%的物理空间,此时 compact 就回退出。

所以有时候遇到对一个大集合进行 compact,compact立马就返回ok:1,集合的物理空间也没有变化,就是因为 WiredTiger 认为这个集合没有 compact 的必要。

预估回收的物理空间

1、连接mongo实例parmary或scondary

2、切换至集合所在的数据库。

use <database_name>

3、执行下列命令查询预估回收空间。

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

4、执行结果示例:

整理单节点实例/副本集实例的碎片

1、通过mongo shell连接MongoDB实例的Primary节点

2、切换至集合所在的数据库。

use <database_name>

3、执行db.stats()命令查看碎片整理前数据库占用的磁盘空间。

4、执行以下命令,对某个集合进行碎片整理。

db.runCommand({compact:"<collection_name>",force:true})

5、等待执行,返回{ "ok" : 1 }代表执行完成。

6、碎片整理完毕后,可通过db.stats()命令查看碎片整理后数据库占用的磁盘空间

本案例碎片整理前后的对比如下图所示:

参数说明:

<database_name>:数据库名。
<collection_name>:集合名。
force为可选项,如您需要在副本集实例的Primary节点执行该命令,需要设置force的值为true。
compact操作不会传递给Secondary节点,当实例为副本集实例时,请重复上述步骤通过mongo shell连接至Secondary节点,执行碎片整理命令。

整理分片集群实例的碎片

1、通过mongo shell连接分片集群实例中的任一mongos节点

2、执行db.stats()命令查看碎片整理前数据库占用的磁盘空间。

3、执行以下命令,对Shard节点中的Primary节点进行集合的碎片整理。

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>",force:true}})

4、执行以下命令,对Shard节点中的Secondary节点进行集合的碎片整理。

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"},queryOptions: {$readPreference: {mode: 'secondary'}}})

参数说明:

<Shard ID>:Shard节点ID。
<collection_name>:集合名。

碎片整理完毕后,可通过db.runCommand({dbstats:1}) 命令查看碎片整理后数据库占用的磁盘空间。

 

おすすめ

転載: www.cnblogs.com/Sungeek/p/12022625.html