From derby-dev-return-46969-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Mon Jul 23 16:11:57 2007 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 4522 invoked from network); 23 Jul 2007 16:11:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Jul 2007 16:11:56 -0000 Received: (qmail 21386 invoked by uid 500); 23 Jul 2007 16:11:55 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 21264 invoked by uid 500); 23 Jul 2007 16:11:55 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 21114 invoked by uid 99); 23 Jul 2007 16:11:54 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jul 2007 09:11:54 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Jul 2007 09:11:52 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7E93F7141EE for ; Mon, 23 Jul 2007 09:11:31 -0700 (PDT) Message-ID: <33250454.1185207091515.JavaMail.jira@brutus> Date: Mon, 23 Jul 2007 09:11:31 -0700 (PDT) From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-2872) Add Replication functionality to Derby In-Reply-To: <16039538.1182851726399.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-2872?page=3Dcom.atlassian= .jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514661 ]=20 =C3=98ystein Gr=C3=B8vlen commented on DERBY-2872: ---------------------------------------- J=C3=B8rgen L=C3=B8land (JIRA) wrote: >> 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'? >=20 > The problem is caused by us writing the log record to the slave > log file *before* recovering it. >=20 > Unfortunately (in this case), the LSN in > Derby (LogInstant) is the byte position where the log record > starts in the log file. Since undo operations seem to identify > their respective do operations using the LogInstant (seems to me > to be "hidden" inside an undo log record's byte[] data), all log > records must be found exactly the same place in the master and > slave log files. Hence, duplicates of log records cannot exist on > file without invalidating the LSNs.=20 I do not understand what avoiding duplicate log records has to do with requiring a specific state of the database. With respect to having log records appear in the same place in the log files, you could consider forcing a log file switch on the master before sending the first log record. Then, the first log record will be at the start of a log file both on the master and the slave. Could that simplify things? > We could, of course, start sending log records < i, and let the > slave ignore these. Even if we decide to send a backup of the=20 > database, it would still be simple to start log shipping at exactly=20 > 'i', however. I see no reason for not using exactly 'i'... I think you said that one reason for the starting of replication to be blocking was that you needed to identify a specific log record 'i'. In other words, if you did not need to identify 'i', there would be one less reason to make the start of the replication be blocking. > 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=C3=B8rgen L=C3=B8land > Assignee: J=C3=B8rgen L=C3=B8land > Attachments: proof_of_concept_master.diff, proof_of_concept_maste= r.stat, proof_of_concept_slave.diff, proof_of_concept_slave.stat, replicati= on_funcspec.html, replication_funcspec_v2.html, replication_funcspec_v3.htm= l, replication_script.txt > > > It would be nice to have replication functionality to Derby; many potenti= al Derby users seem to want this. The attached functional specification lis= ts some initial thoughts for how this feature may work. > Dag Wanvik had a look at this functionality some months ago. He wrote a p= roof of concept patch that enables replication by copying (using file syste= m copy) and redoing the existing Derby transaction log to the slave (unfort= unately, 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 threa= ds, including these: > http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/%3c426= E04C1.1070904@yahoo.de%3e > http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.h= tml --=20 This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.