[
https://issues.apache.org/jira/browse/DERBY-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-2977:
---------------------------------
Attachment: derby_2977_1c.diff
derby_2977_1c.stat
Thanks for the review of the patch, Øystein.
Attaching a patch, v1c, addressing the buffer size issue. I agree that the
replication buffer size should not depend on the disk buffer size. In lack of a
better size, I still use 32k, but now defined in a constant in
MasterController. This size will probably be subject to changes once we are
able to test replication performance :)
Regarding flushedTo: I do not see any good reason why we should not allow log
records to be sent to the slave before these are written to disk. Any
operations that are sent prematurely to the slave will be aborted if a commit
has not been received on the slave. The disk buffer also works this way - it
may write log to disk even when force has not been called.
There is, however, a possibility that the following sequence happens during
commit processing on the master:
1. Commit log record is appended to disk buffer
2. Commit log record is appended to replication buffer
3. Replication log shipping thread gets CPU time and ships all buffered log to
the slave
4. Master crashes before commit log record has been safely written to disk.
This would lead to a case where the commit log record is not on disk on the
master, but is on the slave. However, I do not think this is a problem because:
* Commit has been requested in the first place, so the client should agree that
committing was the intention.
* For the operations of that transaction to be seen by anyone connecting to the
previous slave, the failover command must be issued on the slave. The
functional specification states that when this happens, the database that had
the master role is no longer the active database. Thus, the actual disk image
of the crashed master database is not interesting.
I have started the tests, but expect no failures since the code in the patch is
not in use. I will revert with the results as soon as the tests complete.
> Replication: Add a ReplicationMaster controller that will manage replication
> on the master side
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-2977
> URL: https://issues.apache.org/jira/browse/DERBY-2977
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: derby_2977_1.diff, derby_2977_1.stat,
> derby_2977_1b.diff, derby_2977_1b.stat, derby_2977_1c.diff, derby_2977_1c.stat
>
>
> The replication master role includes many tasks:
> * set up a network connection to the slave
> * sending the database to the slave before starting replication
> * make sure that log records are appended to the network buffer, and that the
> log is later sent to the slave
> * etc
> This issue is for adding a controller that will start/stop/initiate all
> services needed for the replication master role.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
