[
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: 10.4.0.0
> 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,
> replication_script.txt
>
>
> 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 these:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL
> PROTECTED]
> 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.
