[
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
sense.
* 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: 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.
