Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <32235030.1184258224482.JavaMail.jira@brutus>
Date: Thu, 12 Jul 2007 09:37:04 -0700 (PDT)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-2926) Replication: Add a log buffer for log
 records that should be shipped to the slave
In-Reply-To: <27751116.1184228044443.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DERBY-2926?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Matrigali updated DERBY-2926:
----------------------------------


Do you have a writeup on the architecture for replication you are implement=
ing other
than what is in this JIRA and DERBY-2922.  It is hard to comment without un=
derstanding
the architecture you envision.

Have you considered rather than having a linked list of log records, using =
the existing functionality to scan the log records as the base for your lis=
t of log records to write?  Some
of this depends on what kind of replication guarantee you are trying to pro=
vide.  In other
systems I have seen this describes similar to levels of transaction durabil=
ity, ie. levels
like (all basically are tradeoffs about how much you impact master side com=
mit
response time against guaranteeing slave consistency):
o don't allow transaction to commit until log records are synced to remote =
system
o queue write of log records at commit to remote, wait for network reply bu=
t not disk sync
o queue write of log records at commit to remove, don't wait for network re=
ply

If you are looking for any sort of coordination between transaction commit =
and guaranteeing
records on the remote I think I would tie into the existing log writing cod=
e rather than add
a separate beast.  Basically just enhance the small piece of code that actu=
ally writes log
records to disk to also call a new routine that would also write log record=
s somewhere
else.  This does mean impacting performance of master response time dependi=
ng on
the overhead of the secondary write method.  Using multiple threads to do I=
/O locally and
remote at same time would probably help a lot.


> Replication: Add a log buffer for log records that should be shipped to t=
he slave
> -------------------------------------------------------------------------=
--------
>
>                 Key: DERBY-2926
>                 URL: https://issues.apache.org/jira/browse/DERBY-2926
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Store
>    Affects Versions: 10.4.0.0
>            Reporter: J=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>
> 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 rec=
ords to a buffer instead of sending them immediately removes the network co=
mmunication from the critical path for the transaction.

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