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-2926) Replication: Add a log buffer for log records that should be shipped to the slave
Date Mon, 16 Jul 2007 07:20:04 GMT

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

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

>How do you imagine flow control if the network gets slow? Would you
>block a transaction whose record would overflow the buffer? 

There are at least two simple alternatives for how to handle a full replication buffer:

* Stop replication
* Block transactions

I think the first alternative would be the better one since blocking transactions would mean
no availability. This is the exact opposite of what we want to achieve with replication.

The functional spec of DERBY-2872 states that resuming replication after it has been stopped
is a good candidate for extending the functionality. Once that issue has been addressed, we
have a third alternative if the buffer gets full:

* Stop replication for now, but store the log files so that replication can be resumed later.

> Replication: Add a log buffer for log records that should be shipped to the slave
> ---------------------------------------------------------------------------------
>                 Key: DERBY-2926
>                 URL: https://issues.apache.org/jira/browse/DERBY-2926
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Store
>    Affects Versions:
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
> When a Derby instance has the master role for a database, log records are shipped to
the slave to keep it up to date. A buffer is needed because the log records should not be
shipped one at a time. Also, writing the log records to a buffer instead of sending them immediately
removes the network communication from the critical path for the transaction.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message