Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major - P3
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: Backup
-
Labels:
-
Story Points:8
-
Sprint:Storage Engines 2020-04-06
Description
See the attached data files captured with a backup cursor + duplicate backup cursor.
The backup cursor copies a checkpoint with the following properties:
{
|
"oplogStart" : { "ts" : Timestamp(1585249255, 1), "t" : NumberLong(1) },
|
"oplogEnd" : { "ts" : Timestamp(1585249275, 1), "t" : NumberLong(1) },
|
"checkpointTimestamp" : Timestamp(1585249255, 1)
|
}
|
Note the oplogEnd is not expected to be in the checkpoint, but rather the journal file ./data_tmp_backup/db1/journal/WiredTigerLog.0000000001
For kicks, I also added more data and duplicated the backup cursor (./data_tmp_backup/db1/journal/WiredTigerLog.0000000002 in the attached data files). We extended to Timestamp(1585249400, 1). A working binary (master/v4.2) starting up on the attached data files finds this as timestamp as the last oplog entry: "ts" : Timestamp(1585249468, 3).
However, using the tip of v4.4 (5599378dc4137896c87ec7104a9b1fe9917f9795), the last oplog entry matches the recovery/checkpoint timestamp:
{"t":{"$date":"2020-03-26T15:16:07.215-04:00"},"s":"I", "c":"STORAGE", "id":22430,"ctx":"initandlisten","msg":"WiredTiger message {message}","attr":{"message":"[1585250167:215211][15142:0x7f53c94f9a80], txn-recover: Set global recovery timestamp: (1585249255, 1)"}}
|
test> oplog.lfindOne()
|
{
|
"ts" : Timestamp(1585249255, 1),
|
"t" : NumberLong(1),
|
"h" : NumberLong(0),
|
"v" : 2,
|
"op" : "n",
|
"ns" : "",
|
"wall" : ISODate("2020-03-26T19:00:55.364Z"),
|
"o" : {
|
"msg" : "Reconfig set",
|
"version" : 2
|
}
|
}
|
In the attached datafiles, the oplog is WT table collection-16--1190650592073264752. which is WT fileid 20.
Attachments
Issue Links
- related to
-
WT-6015 (4.4-only) Backup test appears to be missing oplog entries
-
- Closed
-