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] Updated: (DERBY-2977) Replication: Add a ReplicationMaster controller that will manage replication on the master side
Date Tue, 04 Sep 2007 13:36:45 GMT

     [ 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

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
> -----------------------------------------------------------------------------------------------
>                 Key: DERBY-2977
>                 URL: https://issues.apache.org/jira/browse/DERBY-2977
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions:
>            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.

View raw message