Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1522861195.1247580974831.JavaMail.jira@brutus>
Date: Tue, 14 Jul 2009 07:16:14 -0700 (PDT)
From: "Kim Haase (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4196) Document initiation of replication
 from cleanly shut down database
In-Reply-To: <141096071.1241007570351.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730863#action_12730863 ] 

Kim Haase commented on DERBY-4196:
----------------------------------

Thanks very much, Knut! 

While I was in the middle of merging the patch to the branch, I did a final check and realized that the documentation of the startSlave attribute has another reference to freezing the database, so I'll need to do another patch after this one. Sorry, I should have checked more thoroughly before.

Committed patch DERBY-4196.diff to documentation trunk at revision 793902. 
Merged to 10.5 doc branch at revision 793905.

A second patch will follow.

> Document initiation of replication from cleanly shut down database
> ------------------------------------------------------------------
>
>                 Key: DERBY-4196
>                 URL: https://issues.apache.org/jira/browse/DERBY-4196
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation, Replication
>    Affects Versions: 10.4.1.3
>            Reporter: Knut Anders Hatlen
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-4196.diff, DERBY-4196.zip
>
>
> The admin guide describes how to start replication.
> http://db.apache.org/derby/docs/dev/adminguide/cadminreplicstartrun.html
> It describes two steps that must be performed before the database is copied from the master to the slave:
> 1. Boot the database on the master system
> 2. Freeze the database (CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE())
> Those two steps could be replaced with a single step:
> 1-2) Make sure the database on the master system is shut down cleanly
> This works because then there is no recovery to be performed when the database later is booted in master mode, and neither the log nor the database will be modified during boot, so the master database will stay completely in sync with the slave.
> Advantages with the alternative procedure are:
> - no need to keep a process running with the database booted and frozen while copying the database from the master system to the slave system
> - uncommitted transactions that are active at the time of the copying won't cause any problems (DERBY-3896)

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