Derby
  1. Derby
  2. DERBY-2922 Replication: Add master replication mode
  3. DERBY-3051

Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.1.3
    • Fix Version/s: 10.4.1.3
    • Component/s: Services, Store
    • Labels:
      None

      Description

      When Derby has the replication master role for a database 'x', it should ship all log records generated for this database to the Derby with the slave role. A replication buffer was added to Derby in DERBY-2926. This issue is for modifying the logging subsystem to append log records to this buffer every time a log records is appended to the disk buffer (LogAccessFile). This will, of course, only be done if it has the master role.

      Currently, I have identified two modifications that will be required in LogToFile:

      • LogToFile#appendLogRecord needs to append to the replication buffer after appending to the disk buffer
      • LogToFile#flush (i.e., the method used to force buffered log records to disk) must notify the Master Controller (DERBY-2977) that a flush has taken place. The MasterController will decide if any action is required because of this.
      1. derby_3051_1.diff
        10 kB
        Jørgen Løland
      2. derby_3051_1.stat
        0.4 kB
        Jørgen Løland
      3. derby_3051_1b.stat
        0.4 kB
        Jørgen Løland
      4. derby_3051_1b.diff
        14 kB
        Jørgen Løland

        Issue Links

          Activity

          Hide
          Jørgen Løland added a comment -

          Attaching a patch, v1, that makes LogToFile send log records to MasterFactory, and notifies the MF when a log disk flush has taken place. This only happens when boolean inReplicationMasterMode is true. The patch also adds two methods to LogFactory: startReplicationMasterRole and stopReplicationMasterRole.

          All tests have passed. Intermittent failure ProcedureInTriggerTest (see DERBY-1585) was encountered in one iteration of derbyall, but was not reproducable.

          Show
          Jørgen Løland added a comment - Attaching a patch, v1, that makes LogToFile send log records to MasterFactory, and notifies the MF when a log disk flush has taken place. This only happens when boolean inReplicationMasterMode is true. The patch also adds two methods to LogFactory: startReplicationMasterRole and stopReplicationMasterRole. All tests have passed. Intermittent failure ProcedureInTriggerTest (see DERBY-1585 ) was encountered in one iteration of derbyall, but was not reproducable.
          Hide
          V.Narayanan added a comment -

          Thank you for the patch Jorgen. The patch looks very good.

          I just have one very small doubt

          Would it be OK for the startReplicationMasterRole and stopReplicationMasterRole
          of the ReadOnly class to both throw an exception Or maybe the stopreplication
          inadvertently called on a read only database would have failed somewhere before
          itself since the replication would not have been started in the first place and
          this code is ideally speaking not reachable.

          Show
          V.Narayanan added a comment - Thank you for the patch Jorgen. The patch looks very good. I just have one very small doubt Would it be OK for the startReplicationMasterRole and stopReplicationMasterRole of the ReadOnly class to both throw an exception Or maybe the stopreplication inadvertently called on a read only database would have failed somewhere before itself since the replication would not have been started in the first place and this code is ideally speaking not reachable.
          Hide
          Øystein Grøvlen added a comment -

          Patch looks good. I have only nits on my list:

          1. LogToFile#inReplicationMasterMode:

          LogToFile also has a member inSlaveMode. Maybe that should be
          called inReplicationSlaveMode for uniformity? Also, I think the
          declaration of these two member fields should be placed together.

          2. LogToFile#appendLogRecord:

          Any particular reason that MasterFactory#appendLogRecord has a
          different ordering of the parameters than
          LogToFile#appendLogRecord. I think the code would be easier to
          read if the methods had the same parameter ordering.

          3. LogToFile#flush:

          What does the '?' behind INVALID_LOG_INSTANT mean?

          4. LogToFile#startReplicationMasterRole, javadoc:

          I would say 'pass log records' instead of 'send ...' in order to
          make it clearer that the MasterFactory is on the same node, and
          that we here are not talking about sending it over the network to
          the MasterFactory.

          5. LogToFile#stopReplicationMasterRole, javadoc:

          Seems not right to mention ReadOnly here since that is a different
          implementation of LogFactory.

          6. LogFactory#(start|stop)ReplicationMasterRole, javadoc:

          The javadoc references to the corresponding ReadOnly methods does
          not seem necessary to me.

          Show
          Øystein Grøvlen added a comment - Patch looks good. I have only nits on my list: 1. LogToFile#inReplicationMasterMode: LogToFile also has a member inSlaveMode. Maybe that should be called inReplicationSlaveMode for uniformity? Also, I think the declaration of these two member fields should be placed together. 2. LogToFile#appendLogRecord: Any particular reason that MasterFactory#appendLogRecord has a different ordering of the parameters than LogToFile#appendLogRecord. I think the code would be easier to read if the methods had the same parameter ordering. 3. LogToFile#flush: What does the '?' behind INVALID_LOG_INSTANT mean? 4. LogToFile#startReplicationMasterRole, javadoc: I would say 'pass log records' instead of 'send ...' in order to make it clearer that the MasterFactory is on the same node, and that we here are not talking about sending it over the network to the MasterFactory. 5. LogToFile#stopReplicationMasterRole, javadoc: Seems not right to mention ReadOnly here since that is a different implementation of LogFactory. 6. LogFactory#(start|stop)ReplicationMasterRole, javadoc: The javadoc references to the corresponding ReadOnly methods does not seem necessary to me.
          Hide
          Jørgen Løland added a comment -

          Attaching a patch, v1b, incorporating comments from Narayanan and Øystein.

          Narayanan: You are correct; before the stopReplicationMaster method is ever called, startReplicationMaster has been called. This means that in read only databases, a "cannot replicate readonly database" exception has already been thrown.

          Show
          Jørgen Løland added a comment - Attaching a patch, v1b, incorporating comments from Narayanan and Øystein. Narayanan: You are correct; before the stopReplicationMaster method is ever called, startReplicationMaster has been called. This means that in read only databases, a "cannot replicate readonly database" exception has already been thrown.
          Hide
          Jørgen Løland added a comment -

          Patch 1b passes all tests.

          Show
          Jørgen Løland added a comment - Patch 1b passes all tests.
          Hide
          Øystein Grøvlen added a comment -

          Committed patch, derby_3051_1b.diff, at revision 576835.

          Show
          Øystein Grøvlen added a comment - Committed patch, derby_3051_1b.diff, at revision 576835.

            People

            • Assignee:
              Jørgen Løland
              Reporter:
              Jørgen Løland
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development