db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4196) Document initiation of replication from cleanly shut down database
Date Fri, 10 Jul 2009 18:21:14 GMT

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

Dag H. Wanvik commented on DERBY-4196:

I am wondering if DERBY-4299 doesn't really call into question the soundness of the "freeze
database" approach.
In DERBY-4299, the ASSERT seen happens because LogToFile.appendLogRecord does no writing of
a log record that is later
accessed in the boot phase in "SLAVE_PRE_MODE" (log records are not written in this "pre"
boot used to authenticate to avoid
getting out of synch with the master).

> 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:
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
> 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.

View raw message