db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Fri, 13 Jul 2007 16:39:04 GMT

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

Dag H. Wanvik commented on DERBY-2872:

Great that you guys are running with this one! Some comments to the
functional specification:

* Derby doesn't log all operations by default, e.g. bulk
  import, deleting all records from a table, creating an index.  These
  issues were addressed in the work on online backup (DERBY-239),
  partially by denying online backup if non-logged operations are not
  yet committed, and partly by making them do logging when online
  backup is in effect (the reason for not logging some operations is
  performance). I guess for replication you would need to make them
  do logging for the duration.

* Overview of characteristics: you mention the network line as a
  single point of failure, that's fine in a first version. One could
  imagine having the replication service support more network interfaces 
  to alleviate this vulnerability.

* Fail-over: When fail-over is performed (with a command on the
  slave), I assume will the master be told to stop its replication so
  it can tidy up? Since you describe the semantics of the stop
  replication command as shutting down the slave database, I assume
  failover can be performed without requiring a prior stop replication
  command on the master.

  If reaching master is not possible (lost connection), can the stop
  replication command be used against the master to tidy up even when
  connection has been lost?

  Perhaps it would be good to include in your table of commands any
  preconditions for the commands. BTW, It seems a good idea to not
  impose an order on starting server or slave first.

* Presumably, the master will time out if it is unable to send logs to
  the slave for some (configurable?) period. It could keep trying for
  some time but eventually it would need to stop or overflow the
  buffer mechanism you suggest in DERBY-2926. Will you require that
  the user has LOG_ARCHIVE_MODE enabled? If you do, it would seem a
  nice addition to later be able to resume replication even if the
  buffer had to be abandoned (as you suggest). *Before* the buffer is
  abandoned, if the network becomes available again, it would be
  trivial to resume shipping of logs I expect?

* Given that the system privileges work of DERBY-2109 provides us with
  necessary security, I would hope we can lift the restriction that
  administration commands can only be run from the same machine as the
  server is started on, but for the time being the restriction makes

* You describe the replication commands as CLI commands against
  NetworkServerControl; will you be making the commands available in
  API form as well, so replication can be embedded in an application?

* typos: "enclypted", "it's local log"

> 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