db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Mon, 23 Jul 2007 16:11:31 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514661

Øystein Grøvlen commented on DERBY-2872:

Jørgen Løland (JIRA) wrote:
>> I do not understand why it needs to be exactly the same database.
>> Recovery already handles redo of log records that are already
>> reflected in the database.  What harm would it make if you sent log
>> records with LogInstant less than 'i'?
> The problem is caused by us writing the log record to the slave
> log file *before* recovering it.
> Unfortunately (in this case), the LSN in
> Derby (LogInstant) is the byte position where the log record
> starts in the log file. Since undo operations seem to identify
> their respective do operations using the LogInstant (seems to me
> to be "hidden" inside an undo log record's byte[] data), all log
> records must be found exactly the same place in the master and
> slave log files. Hence, duplicates of log records cannot exist on
> file without invalidating the LSNs. 

I do not understand what avoiding duplicate log records has to do with
requiring a specific state of the database.

With respect to having log records appear in the same place in the log
files, you could consider forcing a log file switch on the master
before sending the first log record.  Then, the first log record will
be at the start of a log file both on the master and the slave.  Could
that simplify things?

> We could, of course, start sending log records < i, and let the
> slave ignore these. Even if we decide to send a backup of the 
> database, it would still be simple to start log shipping at exactly 
> 'i', however. I see no reason for not using exactly 'i'...

I think you said that one reason for the starting of replication to be
blocking was that you needed to identify a specific log record 'i'.
In other words, if you did not need to identify 'i', there would be
one less reason to make the start of the replication be blocking.

> Add Replication functionality to Derby
> --------------------------------------
>                 Key: DERBY-2872
>                 URL: https://issues.apache.org/jira/browse/DERBY-2872
>             Project: Derby
>          Issue Type: New Feature
>          Components: Miscellaneous
>    Affects Versions:
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: proof_of_concept_master.diff, proof_of_concept_master.stat, proof_of_concept_slave.diff,
proof_of_concept_slave.stat, replication_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.html,
> It would be nice to have replication functionality to Derby; many potential Derby users
seem to want this. The attached functional specification lists some initial thoughts for how
this feature may work.
> Dag Wanvik had a look at this functionality some months ago. He wrote a proof of concept
patch that enables replication by copying (using file system copy) and redoing the existing
Derby transaction log to the slave (unfortunately, I can not find the mail thread now).
> DERBY-2852 contains a patch that enables replication by sending dedicated logical log
records to the slave through a network connection and redoing these.
> Replication has been requested and discussed previously in multiple threads, including
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/%3c426E04C1.1070904@yahoo.de%3e
> http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message