db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3071) Replication: Modify logging subsystem for slave replication mode
Date Wed, 10 Oct 2007 09:01:51 GMT

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


Mime
View raw message