ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-1149

users cannot migrate from 3.4->3.3->3.4 server code against a single datadir

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.4.0, 3.5.0
    • Fix Version/s: 3.4.0, 3.5.0
    • Component/s: server
    • Labels:
      None
    • Hadoop Flags:
      Incompatible change
    • Release Note:
      Hide
      The ZooKeeper server cannot be migrated from version 3.4 to version 3.3 and then back to version 3.4 without user intervention.

      Upgrading from 3.3 to 3.4 is supported as is downgrading from 3.4 to 3.3. However moving from 3.4 to 3.3 and back to 3.4 will fail. 3.4 is checking the datadir for "acceptedEpoch" and "currentEpoch" files and comparing these against the snapshot and log files contained in the same directory. These epoch files are new in 3.4.

      As a result:
      1) upgrading from 3.3 to 3.4 is fine - the files don't exist, the server creates them
      2) downgrading from 3.4 to 3.3 - this is also fine as version 3.3 ignores these files
      3) however, 3.4->3.3->3.4 fails because 3.4 will see invalid *Epoch files in the datadir (as 3.3 would have ignored them, applying changes to snap/log w/o updating them)

      A workaround for this problem is to delete the epoch files if this situation occurrs - the version 3.4 server will create them similar to case 1) above.
      Show
      The ZooKeeper server cannot be migrated from version 3.4 to version 3.3 and then back to version 3.4 without user intervention. Upgrading from 3.3 to 3.4 is supported as is downgrading from 3.4 to 3.3. However moving from 3.4 to 3.3 and back to 3.4 will fail. 3.4 is checking the datadir for "acceptedEpoch" and "currentEpoch" files and comparing these against the snapshot and log files contained in the same directory. These epoch files are new in 3.4. As a result: 1) upgrading from 3.3 to 3.4 is fine - the files don't exist, the server creates them 2) downgrading from 3.4 to 3.3 - this is also fine as version 3.3 ignores these files 3) however, 3.4->3.3->3.4 fails because 3.4 will see invalid *Epoch files in the datadir (as 3.3 would have ignored them, applying changes to snap/log w/o updating them) A workaround for this problem is to delete the epoch files if this situation occurrs - the version 3.4 server will create them similar to case 1) above.

      Description

      3.4 is checking acceptedEpoch/currentEpoch files against the snap/log files in datadir. These files are new in 3.4. If they don't exist the server will create them, however if they do exist the server will validate them.

      As a result if a user
      1) upgrades from 3.3 to 3.4 this is fine
      2) downgrades from 3.4 to 3.3 this is also fine (3.3 ignores these files)
      3) however, 3.4->3.3->3.4 fails because 3.4 will see invalid *Epoch files in the datadir (as 3.3 would have ignored them, applying changes to snap/log w/o updating them)

        Activity

        Patrick Hunt created issue -
        Hide
        Mahadev konar added a comment -

        Pat,
        Should we add this to the release notes? Anything else you think we should do regarding this jira?

        Show
        Mahadev konar added a comment - Pat, Should we add this to the release notes? Anything else you think we should do regarding this jira?
        Patrick Hunt made changes -
        Field Original Value New Value
        Assignee Patrick Hunt [ phunt ]
        Hide
        Patrick Hunt added a comment -

        How's this? (see the release notes on this jira).

        Show
        Patrick Hunt added a comment - How's this? (see the release notes on this jira).
        Patrick Hunt made changes -
        Release Note The ZooKeeper server cannot be migrated from version 3.4 to version 3.3 and then back to version 3.4 without user intervention.

        Upgrading from 3.3 to 3.4 is supported as is downgrading from 3.4 to 3.3. However moving from 3.4 to 3.3 and back to 3.4 will fail. 3.4 is checking the datadir for "acceptedEpoch" and "currentEpoch" files and comparing these against the snapshot and log files contained in the same directory. These epoch files are new in 3.4.

        As a result:
        1) upgrading from 3.3 to 3.4 is fine - the files don't exist, the server creates them
        2) downgrading from 3.4 to 3.3 - this is also fine as version 3.3 ignores these files
        3) however, 3.4->3.3->3.4 fails because 3.4 will see invalid *Epoch files in the datadir (as 3.3 would have ignored them, applying changes to snap/log w/o updating them)

        A workaround for this problem is to delete the epoch files if this situation occurrs - the version 3.4 server will create them similar to case 1) above.
        Patrick Hunt made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Affects Version/s 3.5.0 [ 12316644 ]
        Fix Version/s 3.5.0 [ 12316644 ]
        Hide
        Mahadev konar added a comment -

        Looks good to me. Marking resolved.

        Show
        Mahadev konar added a comment - Looks good to me. Marking resolved.
        Mahadev konar made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mahadev konar made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Patrick Hunt added a comment -

        Note to future searchers, if you see something like this error it's potentially/likely this issue:

        2013-10-11 08:11:37,319 ERROR org.apache.zookeeper.server.quorum.QuorumPeer: Unable to load database on disk
        java.io.IOException: The current epoch, 4, is older than the last zxid, 97270057040
        
        Show
        Patrick Hunt added a comment - Note to future searchers, if you see something like this error it's potentially/likely this issue: 2013-10-11 08:11:37,319 ERROR org.apache.zookeeper.server.quorum.QuorumPeer: Unable to load database on disk java.io.IOException: The current epoch, 4, is older than the last zxid, 97270057040

          People

          • Assignee:
            Patrick Hunt
            Reporter:
            Patrick Hunt
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development