[
https://issues.apache.org/jira/browse/DERBY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-3071:
---------------------------------
Attachment: derby-3071_continuous-recovery_1b.diff
Patch 1b supersedes 1a. All tests pass.
The patch includes the modifications from 1a. It also adds a method
initializeSlaveReplication that sets up the log file so that log records
received from the master can be applied to the slave log files.
In a normal bootup of a database, the log file is initialized in
LogToFile.recover() after the redo loop. That is too late for the slave
functionality to work since the recovery thread will get stuck in that redo
loop for the duration of the slave mode.
Requesting review on patch 1b.
> 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, derby-3071_continuous-recovery_1b.diff
>
>
> 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.
