Oplog update entry without set or unset operation

Working with Data
1

Hello All,

We have a oplog entry with an unusual value, understand that the o2 object id says the object to be updated and “o” says what is being updated. In this particular instance “o2” has the objectid which is expected, but “o” also has the same object id instead of the update to be done. Any idea when can we get such an oplog as mentioned below without $set or $unset operations.

{
        "ts" : Timestamp(1596778564, 9),
        "t" : NumberLong(7),
        "h" : NumberLong(0),
        "v" : 2,
        "op" : "u",
        "ns" : "db.collectionName",
        "ui" : UUID("2947862a-8fb7-4342-87d1-a0ab5f8bc0bd"),
        "o2" : {
                "_id" : ObjectId("5f27e94e0174081a3feb5c6b")
        },
        "wall" : ISODate("2020-08-07T05:36:04.402Z"),
        "lsid" : {
                "id" : UUID("cbd4b90f-1bff-4ad1-b4e2-4c286fc25450"),
                "uid" : BinData(0,"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=")
        },
        "txnNumber" : NumberLong(1269),
        "stmtId" : 0,
        "prevOpTime" : {
                "ts" : Timestamp(0, 0),
                "t" : NumberLong(-1)
        },
        "o" : {
                "_id" : ObjectId("5f27e94e0174081a3feb5c6b")
        }
}

The update oplog for the same object few millisec ago is given below. Which has the right set of operations.

{
        "ts" : Timestamp(1596778564, 8),
        "t" : NumberLong(7),
        "h" : NumberLong(0),
        "v" : 2,
        "op" : "u",
        "ns" : "db.collectionName",
        "ui" : UUID("2947862a-8fb7-4342-87d1-a0ab5f8bc0bd"),
        "o2" : {
                "_id" : ObjectId("5f27e94e0174081a3feb5c6b")
        },
        "wall" : ISODate("2020-08-07T05:36:04.398Z"),
        "lsid" : {
                "id" : UUID("cbd4b90f-1bff-4ad1-b4e2-4c286fc25450"),
                "uid" : BinData(0,"47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=")
        },
        "txnNumber" : NumberLong(1268),
        "stmtId" : 0,
        "prevOpTime" : {
                "ts" : Timestamp(0, 0),
                "t" : NumberLong(-1)
        },
        "o" : {
                "$v" : 1,
                "$set" : {
                        .....
                       .......
                      ......... //All the values to be updated
                }
        }
}

Thanks,
Mahudees

2

Hi @Mahudeeswaran_Palani,

I think we use the oplog in the retryable writes and in transactions so a single operation might result in a chain of oplogs.

Best
Pavel

3

Hi @Pavel_Duchovny,
Many thanks for your reply. Actually these are two different update operations happening on same data one after the other. Could the retryable writes in this scenario is because any failure in connecting DB, any pointers to check from any logs or somewhere why it was trying to retry write this operation.

And how to do we identify it is actually a retryable write operation.

Thanks,
Mahudees

4

Hi @Mahudeeswaran_Palani,

Several oplog entires might be written to the oplog regardless if operations were retried or not.

See the following blog:

I am trying to understand what is the underlying issue. Do you see latency or much higher consumption of oplog space?

Best regards
Pavel

5

I don’t see that this has anything to do with retryable writes - this looks like the client did an update with replacement document with just the _id field so all the other fields would get unset. Is that what the effect of this was?

Asya

1 Like
6

Yes, found that in our code the values are setup to ‘Update’ based on the condition if values are available or not, but update is called in all the case. So when the values are not available for setting, empty Update is called which makes this as replacement document. Have added my observation and findings in this question in stack-overflow.

Many thanks you for helping.

Regards,
Mahudees

1 Like
7

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.