Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5930

(4.4-only) Journaled data from 4.2 binaries not recovered at startup

    • 8
    • Storage Engines 2020-04-06

      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.

        1. journal_not_recovered_by_44.tgz
          841 kB
        2. test_bug023.py
          4 kB
        3. wt5930.cpp
          2 kB

            Assignee:
            sue.loverso@mongodb.com Susan LoVerso
            Reporter:
            daniel.gottlieb@mongodb.com Daniel Gottlieb (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: