[
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.
