1 Reply Latest reply: Aug 21, 2012 10:25 AM by Greybird-Oracle RSS

    Upgrade from Bdb4 to Bdb5

    956481
      We are in the process of upgrading our production environment running on Bdb JE HA 4.1.21 to Bdb JE HA 5.0.58.
      As part of our testing, we upgraded out test cluster to Bdb5. When opening the databases in Bdb5 we ran into some ReplicaWrite exceptions.
      Here is the full stack for it:

      ! com.sleepycat.je.rep.ReplicaWriteException: (JE 5.0.58) The current state is:REPLICA. The node transitioned to this state at:Wed Aug 15 17:14:29 PDT 2012
      ! at com.sleepycat.je.rep.txn.ReadonlyTxn.disallowReplicaWrite(ReadonlyTxn.java:83)
      ! at com.sleepycat.je.dbi.DbTree.checkReplicaWrite(DbTree.java:826)
      ! at com.sleepycat.je.dbi.DbTree.lockNameLN(DbTree.java:870)
      ! at com.sleepycat.je.dbi.DbTree.updateNameLN(DbTree.java:970)
      ! at com.sleepycat.je.Database.validateConfigAgainstExistingDb(Database.java:266)
      ! at com.sleepycat.je.Database.initExisting(Database.java:144)
      ! at com.sleepycat.je.Environment.setupDatabase(Environment.java:783)
      ! at com.sleepycat.je.Environment.openDatabase(Environment.java:607)
      ! at

      When we put this under the debugger, we noticed that when you open a database there is a check to verify that the key prefixing value on disk matches what is there in the DbConfig. If this differs, it tries to update the value on disk to whats in DbConfig. Doing this on a replica throws the above ReplicaWrite exception. The exact same scenario on Bdb4 updates the value on disk successfully.

      Was this a bug in Bdb4 which got fixed in Bdb5 or is this change unintended?

      Similarly we noticed that Bdb5 also tries to verify the value for maxNodeEntries while Bdb4 didn't.

      It would be great to get some clarification on this.

      Thanks
        • 1. Re: Upgrade from Bdb4 to Bdb5
          Greybird-Oracle
          Thank you for re-posting to this forum.
          Was this a bug in Bdb4 which got fixed in Bdb5 or is this change unintended?
          It is a bug fix in JE 5. Previously, changes to the database config were not replicated. The exception is thrown because at attempt to change the config is being made on a replica, rather than the master.

          Are you enabling key prefixing on the replica, when it has not been enabled on the master (or perhaps the change was made on the master but not yet replicated)?

          The other possibility is that this is a duplicates DB and there is a more subtle problem related to the fact that JE 5 automatically enables key prefixing for duplicates DBs. Do you call DatabaseConfig.setSortedDuplicates for this database?

          --mark