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 15:32:31 GMT

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

Øystein Grøvlen commented on DERBY-2872:
----------------------------------------

> Something like this? 
> 
> ij> connect 'jdbc:derby:db;replicationslave;...';
> 
> If so, I do not think we should add this connection attribute. The
> reason is that the replication idea is to prevent the slave from
> completing the database booting; it is supposed to stay in recovery
> and redo log records as they arrive until stop or failover is
> requested. Since the slave gets stuck in recovery, the statement
> above would never return a connection - it would just hang. As far
> as I know, this also means that the connection can not be used to
> stop replication or perform failover either.

The normal way to initiate recovery is to boot a database by opening a
connection to it.  Will you use another mechanism to boot a slave
database?

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.


> 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/%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.


Mime
View raw message