[ https://issues.apache.org/jira/browse/DERBY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533660 ]
jorgenlo edited comment on DERBY-3071 at 10/10/07 2:01 AM: ---------------------------------------------------------------- Attaching a patch, continuous-recovery_1a, that addresses the third bullet - making the database boot thread stay in recovery mode and wait to redo log file X until it is allowed to do so by the slave replication thread. This only affects recovery of a database booted in slave mode. I ran into intermittent failure ProcedureInTriggerTest, but could not reproduce. All other tests pass cleanly. The patch contains cleaned-up code from proof of concept v2b attached to DERBY-2872 and has been tested to some extent in replication slave mode. was (Author: jorgenlo): Attaching a patch, continuous-recovery_1, that addresses the third bullet - making the database boot thread stay in recovery mode and wait to redo log file X until it is allowed to do so by the slave replication thread. This only affects recovery of a database booted in slave mode. I ran into intermittent failure ProcedureInTriggerTest, but could not reproduce. All other tests pass cleanly. > Replication: Modify logging subsystem for slave replication mode > ---------------------------------------------------------------- > > Key: DERBY-3071 > URL: https://issues.apache.org/jira/browse/DERBY-3071 > Project: Derby > Issue Type: Sub-task > Components: Services, Store > Reporter: Jørgen Løland > Assignee: Jørgen Løland > Attachments: derby-3071_continuous-recovery_1a.diff, > derby-3071_continuous-recovery_1a.stat > > > When a database is booted in slave replication mode, it should apply log > records received from the master but must not generate log by itself. As > described in the functional specification (see DERBY-2872), a database booted > in slave mode should enter LogToFile#recover, but not leave this method until > the database is no longer in slave mode. > The current plan for this issue is to modify LogToFile the following ways: > * LogToFile is put in slave mode automatically during boot (if property > SlaveFactory.SLAVE_MODE is set, see DERBY-3021), but a method is needed to > take LogToFile out of recovery mode. > * SlaveFactory (DERBY-3021) will receive log records from the master and use > LogToFile#appendLogRecord to write these to disk. While in slave mode, only > SlaveFactory will be allowed to append log records. > * The thread running LogToFile#recover will recover (redo) one log file at a > time (like now), but will not be allowed to open a log file X until that file > is no longer being written to. Thus, while appenLogFile writes to logX.dat, > recover will be allowed to read all log files up to and including logX-1.dat > but will then have to wait until appendLogRecord starts writing to logX+1.dat. > All the described changes will only apply when in slave mode -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.