[
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 follows:
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: 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.
