db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Tue, 24 Jul 2007 08:10:31 GMT

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

V.Narayanan commented on DERBY-2872:

>Doing a connect that boots the database and blocks until failover is
>done, could be a useful mechanism for users who want to embed a slave
>in their own solution (instead of using the Derby network server).
>Then the return of this call, will indicate that connections may
>opened towards the database (it has become master).

>I am not sure that it is a problem that you will need to use other
>connections to stop replication or perform failover. That will be
>similar to how the network server is managed. The command that start
>the server blocks, and you will need to use other connections to
>manage (e.g., stop) the server.

The use case pointed out here seems very valid and qualifies as good
enough for this startup mechanism. At first look this seems very doable.

I was trying to imagine what would be the changes we would need to do
to the replication mechanism to accomodate this. I guess there wouldn't
be anything other than being able to start the basic replication functionality
upon doing a connect with the replicatino attribute set.

>If you use the non-blocking backup mechanism, you will have to copy
>both database and log files and you will probably want to delay
>switching to replication of individual log records until the backup
>is completed.

Switching between two different messages sent across the network seems
like additional complication which we can avoid if we do not use online
backup. But then there is the additional complexity of handling unlogged
operation which online backup has already solved.

I am undecided about this, I even tried to imagine how much switching
between using single log records and using a log buffer would complicate
the Network code, but the overhead is not much.

Would the requirement of 2x space qualify not using online backup?

>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?

I the comments above a case has been pointed out

"If an transaction has been open since before replication was started, a
slave may need log from before log shipping started to be able to undo
the transaction at failover time."

Would it be easy in this case too? How would the switching happen in this

I will have to dig deeper here, I do not have an answer for this now.

>If an transaction has been open since before replication was started, a
>slave may need log from before log shipping started to be able to undo
>the transaction at failover time. In order to be sure that failover
>will succeed, I think there are two alternatives:
>2) Send old log records to the slave to make sure it has all
>    necessary log to do failover.
I agree with 2) and think it is the right approach.

> 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