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 12:39:31 GMT

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

Øystein Grøvlen commented on DERBY-2872:

Jørgen Løland (JIRA) wrote:
> 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.

I would think the online backup mechanism has already solved some these issues.  Have you
consider using an online backup to get a copy of the database and existing log?

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

I do not understand why it needs to be exactly the same database.  Recovery already handles
redo of log records that are already reflected in the database.  What harm would it make if
you sent log records with LogInstant less than 'i'?

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

I assume the failover command is sent to the slave.  Both 1) and 3)  will then require some
mechanism where the slave sends commands to the master.  If you want keep the work down, another
alternative could be
4) take down the connection to the master and perform failover. But maybe that creates a too
high risk for inconsistencies since you may end up with two masters that both will serve clients.

I think an important use-case is to be able to switch to another master during planned maintenance.
 That could be done without loosing any transactions if the sequence of operations are as
1. Stop new transaction on master
2. Flush all existing log to slave
3. Redo all log on slave
4. Do failover

There is already a mechanism for 1.  I guess 3. is part of 4.  So it is really about being
able make sure existing  log is flushed to disk sending the failover command.  Do we need
a separate command for that, or could it be part of the stop replication command.  That is,
when stop replication is received, existing log is sent before replication is stopped.  Then
the three steps of a "planned failover" would be:
1. freeze database on master
2. stop replication on master
3. failover on slave

> 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