db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-2872) Add Replication functionality to Derby
Date Mon, 23 Jul 2007 11:38:35 GMT

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

Jørgen Løland commented on DERBY-2872:
--------------------------------------

>1. You say, "the database is only booted, not created, on the slave".
>   I think I understand how things will be done, but the booting part
>   is a bit confusing.
>
>3. You say, "The master can now continue to process transaction", but
>   you do not say anything about when such processing is stopped.
>   What advatange does pausing the transaction processing give? 
>

The functional spec will be modified to better describe these. 

Regarding 3) - Processing on the master must be paused while the
following happens: 

* buffered log records and buffered data pages are forced to
  disk. Actually, forcing the data pages is not strictly
  necessary, but we might as well ship all write operations that
  have been performed to the slave.
* the entire database directory is sent to the slave (or copied
  to a backup location, from where it can be sent to the slave)
* the replication log buffer has been started and the logFactory
  has been informed to append log records to the buffer as well
  as to disk.

The reason for this is that the slave requires a copy of the
database that is exactly equal to that on the master when log
shipment starts. When we start sending log records to the slave,
we need to know that the slave has a database that includes all
log records up to a LogInstant 'i'. The first log record that is
sent to the slave must be the one immediately following 'i'.
Hence the pause.

>4. What will happen if the failover command is executed while the
>   master is alive and doing replication?  

I can think of at least three alternatives: 1) stop the master,
and make the old slave a normal Derby instance for the database.
2) not allow failover to be executed on a slave when the master
is alive. 3) perform a "switch", i.e., make the old slave the new
master, and the old master the new slave.

For now, I think 1) is the best alternative to keep the amount of
work down while alternative 3) would make a good extension
candidate to the functionality.

> 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