13

oplogファイルが複数の更新を個々の更新に分割することを理解していますが、バッチ挿入はどうですか？それらも個々のインサートに分割されていますか？

約20Kのドキュメントのバッチが約30秒ごとに挿入される書き込み集中型のコレクションがある場合、デフォルトを超えてoplogサイズを増やすことを検討する必要がありますか？3メンバーのレプリカセットがあり、mongodは64ビットのUbuntuサーバーインストールで実行されており、Mongodbデータは100GBのボリュームにあります。

役立つ場合と役に立たない場合があるデータを次に示します。

    gs_rset:PRIMARY> db.getReplicationInfo()
    {
        "logSizeMB" : 4591.3134765625,
        "usedMB" : 3434.63,
        "timeDiff" : 68064,
        "timeDiffHours" : 18.91,
        "tFirst" : "Wed Oct 24 2012 22:35:10 GMT+0000 (UTC)",
        "tLast" : "Thu Oct 25 2012 17:29:34 GMT+0000 (UTC)",
        "now" : "Fri Oct 26 2012 19:42:19 GMT+0000 (UTC)"
    }
    gs_rset:PRIMARY> rs.status()
    {
        "set" : "gs_rset",
        "date" : ISODate("2012-10-26T19:44:00Z"),
        "myState" : 1,
        "members" : [
            {
                "_id" : 0,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 1,
                "stateStr" : "PRIMARY",
                "uptime" : 77531,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "self" : true
            },
            {
                "_id" : 1,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 2,
                "stateStr" : "SECONDARY",
                "uptime" : 76112,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "lastHeartbeat" : ISODate("2012-10-26T19:44:00Z"),
                "pingMs" : 1
            },
            {
                "_id" : 2,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 2,
                "stateStr" : "SECONDARY",
                "uptime" : 61301,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "lastHeartbeat" : ISODate("2012-10-26T19:43:59Z"),
                "pingMs" : 1
            }
        ],
        "ok" : 1
    }

gs_rset:PRIMARY> db.printCollectionStats()
dev_fbinsights
{
    "ns" : "dev_stats.dev_fbinsights",
    "count" : 6556181,
    "size" : 3117699832,
    "avgObjSize" : 475.53596095043747,
    "storageSize" : 3918532608,
    "numExtents" : 22,
    "nindexes" : 2,
    "lastExtentSize" : 1021419520,
    "paddingFactor" : 1,
    "systemFlags" : 0,
    "userFlags" : 0,
    "totalIndexSize" : 1150346848,
    "indexSizes" : {
        "_id_" : 212723168,
        "fbfanpage_id_1_date_1_data.id_1" : 937623680
    },
    "ok" : 1
}
4

1 に答える 1

15

現在のプライマリの oplog のサイズが大きいほど、レプリカ セットのメンバーがプライマリから大きく遅れることなく、オフラインのままでいられる時間枠が長くなります。あまりにも遅れている場合は、完全な再同期が必要になります。

timeDiffHoursによって返されるフィールドdb.getReplicationInfo()は、oplog が現在記録したデータの時間数を報告します。oplog がいっぱいになり、古いエントリを上書きし始めたら、この値の監視を開始します。特に、書き込み負荷が高い場合 (値が減少する場合) に行ってください。N 時間未満に下がらないと仮定すると、N はレプリカ セット メンバーが一時的にオフラインになることを許容できる最大時間数です (たとえば、定期的なメンテナンス、オフライン バックアップの作成、またはハードウェア障害の場合)。失敗) 完全な再同期を実行せずに。メンバーは、オンラインに戻った後、自動的にプライマリに追いつくことができます。

N の低さに満足できない場合は、oplog のサイズを大きくする必要があります。それは、メンテナンス期間の長さ、またはあなたまたはあなたの運用チームが災害シナリオにどれだけ迅速に対応できるかに完全に依存します. やむを得ないスペースの必要性がない限り、割り当てるディスク容量は自由に設定してください。

ここでは、すべてのレプリカ セット メンバーで oplog のサイズを一定に保っていると仮定しています。これは合理的なことです。そうでない場合は、最小の oplog を持つレプリカ セット メンバーがプライマリに選出されるシナリオを計画します。

（他の質問に答えるには：複数の更新と同様に、バッチ挿入もoplogの複数の操作にファンアウトされます）

編集：データのインポートと一括挿入/更新は、アプリケーションが通常の負荷が高い場合よりもはるかに高速にデータを oplog に書き込むことに注意してください。繰り返しますが、oplog がいっぱいになるまでにかかる時間を控えめに見積もってください。

于 2012-10-27T00:00:36.330 に答える