0

1 つのプライマリ マシン、1 つのセカンダリ マシン、および 1 つのアービター マシンの mongodb レプリカ セット構成があります。プライマリ マシンとセカンダリ マシンには 2 つのコレクションがあります (それぞれ独自のデータベースにあります)。

1 つのコレクションから数 Gb を削除し、他のコレクションはそのままにしておく必要があります。私はこれでまったく新しいので、これに関するアイデア/落とし穴を得たいと思います. 私はこの手順に従うことを考えています:

  1. レプリカ セットからセカンダリを削除します。
  2. セカンダリでは、削除したいコレクションに対して、保持したいデータの mongodump を実行します。
  3. そのダンプから mongo restore を実行します。
  4. セカンダリをレプリカ セットに再度追加します。一次が二次にならないように優先順位をつけないといけないのではないでしょうか?
  5. セカンダリはプライマリと同期/追いつきますが、セカンダリで削除したデータはどうなりますか? プライマリはそれを自分自身から削除しますか? (これが私が欲しいものです)

  6. 初等協会で何かする必要はありますか?

4

1 に答える 1

2

ローリングメンテナンス:

  • oplog の時間を確認するには、セカンダリをダウンさせてキャッチアップします: db.printReplicationInfo()
  • Primary、Secondary、Arbiter を使用している場合、Secondary を削除するとリスクが生じる可能性があります。メンテナンス期間中に何かが発生した場合に備えて、プライマリにはフェイルオーバーがありません。Primary-Secondary-Secondary の方が安全です。
  • セカンダリをシャットダウンした後、 --replSet オプションを指定せずに再起動し、別のポートで再起動します。そうしないと、replicaSet の残りの部分が混乱します。
  • --replSet を使用してセカンダリを再起動すると、古いポートが再びそれを ReplicaSet に追加します。ご心配なく。あなたのプライマリーはプライマリーのままです。投票/選挙は、プライマリが消えたときに「のみ」発生します...セカンダリを追加する場合はそうではありません。
  • セカンダリは oplog に追いつきます。
  • 初等協会で働くこと。プライマリで rs.stepDown() を実行し、セカンダリに引き継がせて、プロセスを繰り返します。

ローリングメンテナンス中のクリーンアップ

これについてはまだテストしていないので、今のところ推測することしかできません。ローリングメンテナンス中にできることは次のとおりです。

  • バイナリの更新 (apt-get update/yum update/...)
  • インデックスを構築する
  • コンパクトにして修理

データの削除について ローカルの小さなレプリカでテストする必要があること。

  • 残念ながら、ダンプ/復元は悪い考えです。確信はないけど。
  • removeステートメントを実行します...それを行う方法があると思います。そのステートメントをプライマリで実行させますが、まだ方法がわかりません。
  • 最も単純な例: プライマリで remove ステートメントを実行し、それをセカンダリに広げてみませんか? データベースのサイズを小さくしたいからですか?さて、取り外した後、ローリングメンテナンスを実行して修復を行うことができます. Compact は余分なスペースを作成せず、事前に割り当てられたファイル内のデータのみを並べ替えます。そして修理、注意してください、構築するには2倍のスペースが必要です。修復を行うには、100 GB の DB に少なくとも 100 GB の空き容量が必要です。

https://dba.stackexchange.com/questions/28269/disk-space-recovery-on-mongodb-replicaset-secondaries

https://university.mongodb.com => M202: MongoDB Advanced Deployment and Operations ...をご覧ください。この問題は、これらの無料レッスンで扱われます。

于 2015-06-19T08:59:55.537 に答える