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:50:31 GMT

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

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

Jørgen Løland (JIRA) wrote:
> From the adminguide, topic "Online backups":
> "The SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure puts the database
> into a state in which it can be safely copied, then copies the
> entire original database directory (including data files, online
> transaction log files, and jar files) to the specified backup
> directory. Files that are not within the original database directory
> (for example, derby.properties) are not copied."

This citation is from the 10.1 version of the guide.  If you look at
the 10.2 guide, you will see that it has been changed and that the
backup is now non-blocking.

> 
> If this is the mechanism you are referring to, we can use backup
> to do the "or copied to a backup location, from where it can be
> sent to the slave" part. That strategy will freeze the database
> for a shorter time iff the disk is faster than the network. On
> the other hand, it will require 2x diskspace and potentially much
> memory because log records will accumulate while the backed-up
> database is being sent to the slave. 

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.





> 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