MongoDBには、埋め込み配列や配列オブジェクトなど、大量のデータセットの操作が含まれることがよくあります。したがって、読み取りおよび書き込み操作を強化するために、データベースの処理速度を可能な限り高速にすることが常に重要です。さらに、データの不整合が原因で発生する可能性のあるデータの異常を回避するには、ハードウェア障害やサービスの中断が発生した場合に備えて、データの可用性を高めておく必要があります。 MongoDBは、その目的のために、ReplicaSetsとShardingという2つの概念を提供します。
MongoDBでのレプリケーション
マスター/スレーブレプリケーション
これは、1つのシステムに障害が発生した場合でも、ユーザーがデータを常に利用できるようにするために使用される最も古い手法の1つです。ただし、マスタースレーブレプリケーションは、最新バージョンのMongoDBでは3.2以降で非推奨になっているため、レプリカセットに置き換えられました。
この構成を行うには、1つがマスターモードでもう1つがスレーブモードであると見なしながら、2つのmongodインスタンスを開始します。
インスタンスをマスターモードで開始するには、次を実行します。
mongod --master --port portNumber--masterオプションは、mongodにlocal.oplog。$ mainコレクションを作成するように指示します。このコレクションを使用して、スレーブがデータの複製に適用する操作のリストがキューに入れられます。
スレーブモードでmongodインスタンスを開始するには、次のコマンドを実行します。
mongod --slave --source <masterhostname><:<port>>ここでは、マスターインスタンスのホスト名とポートを--source引数に指定する必要があります。これは、マスタースレーブレプリケーションの使用の概要をまとめたものであり、廃止されたため、レプリカセットに関心があります。
レプリカセット
これは、基本的に同じデータセットをホストするmongodインスタンスと呼ばれるMongoDBプロセスのグループです。これは、データを保持するための1つのプライマリノードと複数のセカンダリノードによって機能されます。プライマリノードはすべての書き込み操作を受け取り、データセットに対する他のすべての変更を操作ログに記録します。もう一方の端のセカンダリノードは、プライマリの操作ログを複製し、データセットがプライマリのデータセットを反映するようにデータセットに操作を適用します。簡単に言うと、プライマリノードとしてマシンAがあり、セカンダリノードとしてマシンBとCがあると言えます。マシンAは書き込み操作を受け取り、そのデータに変更を加えてから、行われた変更のリストを作成します。次に、マシンBとCは、提供されたリスト（この場合はoplog）から操作をコピーし、結果のデータがマシンAと同じになるようにそれらを実行します。
前述のように、特に本番環境では、データの高可用性を確保することが常に重要です。レプリケーションは、さまざまなMongodインスタンスでデータの冗長性を提供することで役立ちます。データが失われた場合、同じデータのコピーが複数の場所にある異なるデータベースに保存されるため、既存のデータベースで簡単に復元できます。
多くのインスタンスが実行されている場合、クライアントからの読み取りおよび書き込み操作は異なるサーバーに送信されるため、処理速度が向上します。レプリケーションプロセスの基本構造を以下に示します。
インターネットの切断やサービスの中断などにより、プライマリが利用できない場合があります。この場合、レプリカセットはセカンダリをプライマリノードとして指定します。読み取り要求は基本的にプライマリに対して行われますが、読み取り要求をセカンダリに送信できる場合もありますが、返されるデータがプライマリの内容を反映していないか、データが最新でない可能性があるため、注意が必要です。
アービター
予備選挙の場合、選挙プロセスで投票を追加するには、レプリカセットに追加のmongodインスタンスが必要になります。このインスタンスはアービターと呼ばれ、その顕著な特徴は次のとおりです。
- データセットのコピーがないため、データを保持するノードほど強力なハードウェアは必要ありません。
- プライマリに昇格することはできません。
- データを複製する追加のメンバーのオーバーヘッドなしに、レプリカセットが不均等な数の投票メンバーを持つことができるように、常に1つの選挙投票があります。したがって、その重要な役割は、プライマリノードが利用できないときにプライマリノードを選択することです。
- 変更はありません。
アービターとは異なり、他のレプリカセットはセカンダリからプライマリに変換でき、その逆も可能です。
非同期レプリケーション
レプリケーションのプロセスは、2つの形式のデータ同期で行われます。まず、セット内のメンバーに、初期同期で完全なデータが入力されます。後続のレプリケーションは、データセット全体に高度な変更を適用するために行われます。
初期同期では、データはレプリカセットの1つのメンバーから別のメンバーにコピーされます。プロセスが完了すると、メンバーはセカンダリノードに移行します。
MongoDB自動フェイルオーバー
プライマリとセカンダリ間の通信を終了した結果として生じるネットワーク切断のようなサービスの中断が発生する可能性があります。切断が10秒を超えるか、完全に失敗した場合、残りのレプリカセットは、メンバーが新しいプライマリになるように投票します。投票の過半数を獲得したセカンダリノードが新しいプライマリになります。
MongoDBのバージョン3.0では、レプリカセットに最大50のメンバーと、7つの投票メンバーを含めることができます。
優先度ゼロのレプリカセットメンバー
これらはセカンダリメンバーであり、プライマリノードになることも、選挙をトリガーすることもできません。データセットには、データセットのコピーを維持し、プライマリノードを選択し、読み取り操作を実行するという重要な役割があります。これらは、新しいメンバーがすぐに追加できない可能性があるバックアップのように機能します。したがって、更新されたデータが保存され、利用できないメンバーをすぐに置き換えることができます。
MongoDB隠しレプリカセットメンバー
これらは、クライアントアプリケーションに接続されていないメンバーです。これらは、他のセカンダリメンバーとは異なる使用要件を持つワークロードに使用されます。これらは、初期同期中の基本的なレプリケーショントラフィックのみを受信します。
MongoDB遅延レプリカセットメンバー
これらは、指定された期間内にプライマリノードのoplogファイルからデータをコピーします。それらは常に遅延状態またはセットの以前の形式を反映します。したがって、これらはエラーを検出する上で重要であり、たとえば、ドロップされたデータベースがある場合に、それらのエラーから回復する方法についてのヒントを提供します。遅延の量を選択するときは、これを考慮に入れる必要があります。
- 期間は、WiredTiger、MMAPv1、およびIn-Memoryストレージエンジンの場合は50GBである操作ログの容量よりも短くする必要があります。そうしないと、遅延したメンバーは操作を正常に複製できません。
- 遅延時間は、予想されるメンテナンスウィンドウの時間と同じかわずかに長くする必要があります。
構成
これは優先度ゼロのメンバーであり、非表示になっているため、アプリケーションには表示されず、最後に選挙プロセスに参加できます。したがって、優先度を構成するには、レプリカセットに10個のメンバーがあるとします。たとえば、位置nのメンバーをmember [n]として選択し、そのプロパティを次のように設定できます。
{
“_id”: <num>,
“Host”: <hostname: port>,
“Priority”: 0,
“slaveDelay”: <seconds>,
“Hidden”: true
} または、プライマリに接続されたmongoシェルを使用して、次のコマンドを実行して、レプリカセットの最初のメンバーを遅延として設定できます。
cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)この構成を設定した後、遅延したセカンダリはプライマリになることができないため、アプリケーションから隠されます。メンバーは、oplog操作から1時間（3600秒）遅れます。
SomeninesがMongoDBDBAになる-MongoDBを本番環境に導入MongoDBDownloadを無料でデプロイ、監視、管理、スケーリングするために知っておくべきことを学びましょうレプリカセットの開始方法
このガイドでは、MongoDBでレプリカセットを構成する方法を段階的に説明します。
- 複製するmongodbが3つあり、それらが次のように構成されているとします。
- ポート27017で実行されているMongod1.conf
- ポート27018で実行されているMongod2.conf
- ポート27019で実行されているMongod3.conf
各ファイルで変更されないレプリカセット名を必ず追加してください。これを行うには、オプションreplSet値を任意の名前に追加または変更します。
-
を実行して最初のインスタンスを開始できます
sudo mongod --config /etc/mongo/mongod1.confこれは、mongodを実行しているインスタンスがない場合です。次に、他のインスタンスについても同じようにします。マシンで実行中のインスタンスを確認するには、実行します
ps -ax | grep mongo次のようなリストが表示されます：
これは、MongoDBの最初のインスタンスがデフォルトでポート27017で実行されることを意味します。したがって、リストの最初のインスタンスとしてそれを持っています。他のユーザーを開始した場合は、対応するパスのURLとともにリストに概要が表示されます。 mongoシェルのインスタンスに接続するには、次のコマンドを実行します：4328 ttys000 0:06.15 mongod 4950 ttys001 0:00.00 grep mongo
ただし、この場合、レプリカセット名で接続する必要があるため、コマンドに名前を追加する必要があります。mongo --port port_number i.e mongo --port 27017.
この場合、replicaSetName =“ testrep”mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017 -
rs.status（）
を実行して有効になっているレプリカセットがあるかどうかを確認しましょう。次のような結果が得られた場合：
{ "ok" : 0, "errmsg" : "not running with --replSet", "code" : 76, "codeName" : "NoReplicationEnabled" }次に、レプリカセットが有効になっていないことを意味します。それ以外の場合は、次のように結果を取得します
{ "operationTime" : Timestamp(0, 0), "ok" : 0, "errmsg" : "no replset config has been received", "code" : 94, "codeName" : "NotYetInitialized", "$clusterTime" : { "clusterTime" : Timestamp(0, 0), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } }レプリカがまだ開始されていないことを意味します。
-
rs.initiate（）メソッドは、新しいレプリカセットを開始するのに役立ち、それが開始されるインスタンスがプライマリノードになります。したがって、initiateメソッドを実行することにより、インスタンスで1つを開始できます。 rs.initiate（）。
-
rs.status（）。membersを実行して、レプリカセットのステータスを再度確認します。
のようなものが表示されます。"members" : [ { "_id" : 0, "name" : "localhost:27018", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 577, "optime" : { "ts" : Timestamp(1535301271, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2018-08-26T16:34:31Z"), "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "could not find member to sync from", "electionTime" : Timestamp(1535301265, 1), "electionDate" : ISODate("2018-08-26T16:34:25Z"), "configVersion" : 1, "self" : true, "lastHeartbeatMessage" : "" } ]さて、行ってよかった。 1つのメンバーを含むn配列であることがわかるので、メンバーオプションに関心があります。この場合、最初のメンバーのstateStrオプションをチェックすると、プライマリに設定されます。これは、これがプライマリノードとして機能することを意味します。
-
ホスト名を使用してレプリカセットに新しいメンバーを追加します。追加する接続インスタンスのホスト名を確認するにはrun
db.serverStatus().host
のようなものが得られますervername.local:27019したがって、PRIMARYから、mongoシェルで次のコマンドを実行して別のメンバーを追加できます。
rs.add("servername.local:27019"); -
ステータスコマンドを実行します
rs.status().members変更が加えられたかどうかを確認します。
これで、次のようになります。
[ { "_id" : 0, "name" : "localhost:27018", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 11479, "optime" : { "ts" : Timestamp(1535312183, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2018-08-26T19:36:23Z"), "syncingTo" : "", "syncSourceHost" : "", "syncSourceId" : -1, "infoMessage" : "", "electionTime" : Timestamp(1535301265, 1), "electionDate" : ISODate("2018-08-26T16:34:25Z"), "configVersion" : 2, "self" : true, "lastHeartbeatMessage" : "" }, { "_id" : 1, "name" : "127.0.0.1:27019", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 15, "optime" : { "ts" : Timestamp(1535312183, 1), "t" : NumberLong(1) }, "optimeDurable" : { "ts" : Timestamp(1535312183, 1), "t" : NumberLong(1) }, "optimeDate" : ISODate("2018-08-26T19:36:23Z"), "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"), "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"), "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"), "pingMs" : NumberLong(0), "lastHeartbeatMessage" : "", "syncingTo" : "localhost:27018", "syncSourceHost" : "localhost:27018", "syncSourceId" : 0, "infoMessage" : "", "configVersion" : 2 } ]これで2つのメンバーができました。1つはPRIMARYノードで、もう1つはSECONDARYノードです。メンバーをさらに追加できますが、50を超えないようにします。次に、プライマリとしてポート27018のインスタンスにデータベースを作成しましょう。
プライマリを切断すると、フェイルオーバーが発生し、プライマリが1つしかないため、自動的にセカンダリに移行されます。これで、ポート27019に接続すると、ドキュメントと同じデータベースとコレクションを取得できるはずです。
これで、切断されたプライマリノードが再接続されると、既存のプライマリのoplogから操作をコピーするため、セカンダリとして追加されます。
MongoDBレプリカセットの書き込みに関する懸念
MongoDBが正常なジャーナル書き込みの懸念を返した場合、データはディスクに保存されるため、mongodの再起動後に使用可能になります。ただし、書き込み操作の場合、データは、レプリカセットの投票メンバーの過半数から賛成して複製され、ジャーナルにコミットされた後にのみ耐久性があります。
一部のデータは大きすぎて更新または挿入できない場合があるため、データが他のメンバーに複製されるまでに予想よりも時間がかかる場合があります。このため、writeConcern構成を編集して、操作が実行される期間に対応することをお勧めします。デフォルトのwriteConcern構成では、レプリカセットはプライマリメンバーからの確認応答のみを必要とします。デフォルトの書き込み懸念は、プライマリのみの書き込み操作を確認しますが、特定の書き込み操作の書き込み懸念を指定することにより、一部のレプリカセットメンバーの書き込み操作をチェックするためにオーバーライドできます。例：
db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})この場合の書き込みオプションは、操作がプライマリと少なくとも2つのセカンダリに拡散された後、または3.6秒後にタイムアウトした場合にのみ応答を返すように指示します。
MongoDBの書き込みに関する懸念事項の構成
MongoDB getLastErrorDefaultsオプションは、レプリカセット構成の書き込み関連のデフォルト設定を変更するためのパラメーターを提供します。これは、結果を返す前に、ほとんどの投票メンバーで操作を完了する必要があることを意味します。
cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)タイムアウト値は、書き込み操作のブロックを防ぎます。つまり、書き込みの懸念を確認するメンバーが5つあるはずなのに、残念ながらレプリカセットにメンバーが4つ以下の場合、すべてのメンバーが使用可能になるまで操作がブロックされます。タイムアウトしきい値を追加することにより、この期間が経過すると、操作のブロックは破棄されます。
レプリケーションのブロック
特にすべてのメンバーが複製されたときに操作をブロックすると、応答を返すために別のレプリカセットメンバーが使用可能になるのを待つために無駄な時間がなくなります。 MongoDB getLastErrorコマンドオプションは、オプションの「w」属性を使用してレプリケーションの更新を行う方法を指定します。
たとえば、このクエリ
db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});N個のメンバーが最後の書き込み操作を複製するまでブロッキングが発生する必要があります。 Nが使用可能であるか、2未満の場合、クエリが返されます。それ以外の場合、Nの値が2に等しい場合、プライマリに相当するマスターは、そのスレーブの1つが最後の操作に複製された後にのみ応答します。
wtimeout パラメータは基本的に、最後のオプションが複製される前にgetLastErrorコマンドがタイムアウトしてエラーを返すまでの時間をミリ秒単位で設定することです。
ブロッキングはなんらかの利点がありますが、制限がある場合もあります。特に「w」の値を大きく設定しすぎると、読み取り操作が大幅に遅くなります。安全性と効率を向上させるために、「w」の値を2または3に設定することをお勧めします。
MongoDBの読み取り設定
これは基本的に、クライアントの読み取り操作がレプリカセットに対して行われる隣接ルートです。デフォルトのMongoDBセットアップは、読み取り操作をプライマリに構成します。これは、フェッチしているドキュメントの最新バージョンを使用しているためです。前述のように、レプリカセットを利用する最大の利点は、データベースシステムのパフォーマンスを向上させることです。したがって、必ずしも最新のデータを必要としないアプリケーションの遅延を減らすために、読み取り操作を多くのセカンダリメンバーに分散することをお勧めします。ただし、基本的な好みとしてプライマリも使用する必要がある、より重要な理由があります。
- フェイルオーバー中のデータの可用性の維持。
- 地理的に分散したアプリケーションの場合、プライマリは同じデータセンター内のクライアントにローカル読み取りを提供します。
- フロントエンドアプリケーション、特にシステム操作を実行しているアプリケーションには影響しません。
Mongo.setReadPref（） 方法
この方法は基本的に、クライアントがすべてのクエリをレプリカセットのメンバーにルーティングする方法を定義するためのものです。 modeとtagSetの2つの引数を取ります。
mode引数は、primary、primaryPreferred、secondary、secondaryPreferred、または最も近い読み取りプリファレンスを指定します。
tagSetモードは、カスタム読み取りプリファレンスを指定します。オブジェクトの配列として指定することもできます。セットアップの例は次のとおりです。
db.getMongo().setReadPref('primaryPreferred',
[ { "dc": "east", "use": "production" },
{ "dc": "east", "use": "reporting" },
{ "dc": "east" },
{}
] )ここで何が起こるかというと、クライアントが最初のタグにアクセスしようとしても、リクエストが通過しない場合、2番目の読み取り設定が選択されます。
優先モードの読み取り
- プライマリ：これは、特定のレプリカセットから読み取られるすべての読み取り操作がプライマリであり、デフォルトの優先読み取りモードであることを定義します。
- PrimaryPreferred：プライマリのみが使用できない場合は、セカンダリから読み取り操作を実行できます。
- セカンダリ：すべての読み取り操作は、レプリカセットのセカンダリメンバーから行われます。
- SecondaryPreferred：使用可能なセカンダリがない場合のみ、プライマリから読み取り操作を実行できます。
- 最も近い：ネットワーク遅延が最も少ないメンバーが、そのタイプに関係なく、読み取り操作に選択されます。
タグセットとその構成
これらは、書き込みの懸念と読み取りの設定をどのように見せたいかをモデル化できるオプションです。これらは、レプリカセット構成オブジェクト内に格納されます。 rs.conf（）。membersを実行すると、次のオブジェクトが返されます：
[
{
"_id" : 0,
"host" : "localhost:27018",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "127.0.0.1:27019",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
]ご覧のとおり、各メンバーにはタグ属性があります。
読み取り設定と書き込み懸念の主な違いは、前者は読み取り元のメンバーを選択するときにタグの値を考慮するのに対し、後者は考慮しないことです。
読み取り操作に設定されたタグが次のように設定されているとします。
{ "disk": "ssd", "use": "reporting" }レプリカセットのメンバーは、読み取り操作を実行するためにこれらのタグを満たす必要があります。したがって、このような構成
{ "disk": "ssd", "use": "reporting", "rack": "a" }クエリを満たしますが、これは
{ "disk": "ssd", "use": "production", "rack": "k" }クエリを満たしません。
セットレプリカへのタグの追加
レプリカセットで選択したメンバーについて、MongoDBのrs.conf（）メソッドを使用してタグセットを追加できます。
レプリカセット配列の位置1でメンバーを選択したとすると、次のようにタグセットを追加できます。
conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production" }
conf.members[1].tags = { "dc": "LON", "use": "reporting" }
conf.members[2].tags = { "use": "production" }
rs.reconfig(conf)MongoDBレプリカセットのデプロイパターン
- 地理的に分散されたレプリカセット-電力損失などの障害からデータを保護するだけでなく、データの冗長性を強化します。実行中のインスタンスは複数の場所にあります。
- 3つのメンバーのレプリカセット-レプリカセットの基本的な標準アーキテクチャ。
- 4つ以上のメンバーのレプリカセット-データのより広い冗長性を有効にし、レプリカセットでの読み取り操作のより広い分散もサポートします。
MongoDBレプリカセットのデプロイメントチューニングテクニック
理想的なレプリカセットには、本番システム用に少なくとも3つのメンバーを備えた適切にレイアウトされたアーキテクチャが必要です。これらの導入戦略は、優れたレプリカセットを実現するのに役立ちます。
- 遅延メンバーと非表示メンバーを使用して、レポートやバックアップなどの専用機能をサポートします。
- 常にデプロイされたメンバーの数を奇数にします。上で議論したように、プライマリーを選出する際には奇数のメンバーが必要になります。したがって、奇数であることを確認してください。そうでない場合は、いつでもアービターを追加できます。
- 読み取りが多い展開の場合、負荷を分散する必要があります。したがって、読み取りパフォーマンスを向上させるために、読み取りをセカンダリに分散する必要があります。さらに、データが時間の経過とともに大きくなる場合は、メンバーを追加して配布できますが、最も重要な設計がプライマリを選択するように構成する必要があることに注意してください。
- 常にフォールトトレランスを考慮してください。これは基本的に、特定の時間に利用できないメンバーの数と、プライマリーの選挙プロセスを維持するために残っているメンバーの数を決定することです。プライマリがない場合、残念ながらレプリカセットは書き込み操作を受け入れません。
- 需要が発生する前に、既存のレプリカセットに新しいメンバーを追加します。
- レプリカセットタグセットを使用して、すべての操作が特定のデータセンターで確実に複製されるようにします。これらのタグを特定のデプロイメントマシンの読み取り操作のルーティングに使用することもできます。
- ほとんどのメンバーを1つの場所に配置して、ネットワークのパーティション分割から生じる挫折を回避します。ネットワークのパーティション分割は、データセンター間の通信が切断された結果である可能性があり、その結果、レプリケーションプロセスとプライマリを選択するプロセスが妨げられます。
- 安全上の理由から、メンバーを地理的に分散させるだけでなく、一部を非表示にします。少なくとも2つまたは3つのメンバーの優先度をゼロに設定して、メンバーがプライマリにならないようにすることができます。
- 停電などの原因となる可能性のあるデータ損失を保護するために、ジャーナリングを採用します。これにより、突然のシャットダウンが発生した場合にデータが確実にディスクに書き込まれます。
操作ログ（Oplog）
oplogは、スレーブに適用されるマスター操作の記録を保持します。これは、oplog。$mainコレクションのlocalというデータベースに保存されます。レプリカセットメンバーを初めて起動したときに作成されます。上限では、oplogはすべてのストレージエンジンで50GBのサイズに制限されています。 oplogサイズはデフォルト設定から変更できます。たとえば24時間の運用でこのサイズに達すると、セカンダリはこの期間中は快適にコピーできなくなり、まったくコピーできなくなる可能性があります。オプションreplSetResizeOplogを使用して、oplogのサイズを変更できます。つまり
db.database({replSetResizeOplog:1, size: 16384})このoplogのサイズを小さくすると、一部のデータが削除されます。レプリカセットでのこれの主な影響は、このノードに同期されたメンバーが古くなることです。したがって、これらのメンバーを再同期する必要があります。
大きなOplogサイズを必要とするワークロードパターン
- 一度に複数のドキュメントに更新します。ノード全体の結果を改善するには、複数の更新操作を個別の操作に変換する必要があります。この操作では、oplogスペースの広大なスペースが使用されます。
- かなりの数のインプレース更新。これは通常、ドキュメントのデータを更新するときに発生しますが、必ずしもこのドキュメントのサイズを大きくする必要はありません。データベースはoplogに多数の操作を記録するため、そのサイズが大きくなります。
- 削除は挿入と同じ量のデータに相当します。これは、挿入したデータの量と（ほぼ）等しい量のデータを削除しようとしたときに発生します。この操作により、oplogのサイズが大きくなる傾向があります。
結論
レプリケーションは、開発者が理解する必要のあるデータベースの重要な側面の1つです。これにより、データの可用性が向上します。たとえば、停電が原因でMongoDBサーバーがダウンする可能性がありますが、それでもクライアントにそのデータへのアクセスを許可します。別のサーバーにデータを複製した場合、プライマリサーバーに障害が発生した場合でも、クライアントはそのサーバーからデータにアクセスし続けることができます。さらに、負荷分散が強化されているため、すべてのユーザーが1つのサーバーにアクセスする代わりに、セカンダリレプリカからのトラフィックを処理することのトレードオフが見られます。