[
https://issues.apache.org/jira/browse/DERBY-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685324#comment-16685324
]
Rick Hillegas commented on DERBY-7017:
--------------------------------------
I'm afraid that Derby's replication experts are not active contributors
currently--but maybe one of them will respond. The replication code can be
found under the following branches of the source tree...
{noformat}
trunk/java/org.apache.derby.engine/org/apache/derby/iapi/store/replication
trunk/java/org.apache.derby.engine/org/apache/derby/impl/store/replication
{noformat}
...and, as you know better than I do, sparse documentation can be found in the
Derby Server and Administration Guide under the topic "Replicating databases".
If you want to study that code, I am sure that active contributors can help you
understand the broader context of the surrounding codebase.
The REPLICATION_LOG_OUT_OF_SYNCH (XRE05.C) error message is raised at two
places in the source code. It indicates that the slave database has moved ahead
of the master database. I don't know how this can happen other than if someone
connects to the slave database and generates transactional activity there.
I cannot say whether the following is significant: Your process for creating a
slave database does not hew exactly to the instructions at
http://db.apache.org/derby/docs/10.14/adminguide/cadminreplicstartrun.html.
According to those instructions, the slave database should be cloned from a
master database which has been shut down completely, not merely quiesced via
the FREEZE command.
Hope this helps,
-Rick
> Derby replication not working
> -----------------------------
>
> Key: DERBY-7017
> URL: https://issues.apache.org/jira/browse/DERBY-7017
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.14.1.0, 10.14.2.0
> Environment: Linux
> Reporter: Geraldine
> Priority: Major
>
> I am running Apache Derby 10.14 on Linux and I intermittently (yet
> frequently) see an issue when trying to start derby replication:
> Attempt 1: ERRORCODE: 40000, SQLSTATE: XRE05, SQLERRMC: The log files on the
> master and slave are not in synch for replicated database 'ImpactDB'. The
> master log instant is 67:619207, whereas the slave log instant is 67:620032.
> This is fatal for replication - replication will be stopped.
> Attempt 2: ERRORCODE: 40000, SQLSTATE: XRE05, SQLERRMC: The log files on the
> master and slave are not in synch for replicated database 'ImpactDB'. The
> master log instant is 67:619207, whereas the slave log instant is 67:619207.
> This is fatal for replication - replication will be stopped.
> Attempt 3: ERRORCODE: 40000, SQLSTATE: XRE05, SQLERRMC: The log files on the
> master and slave are not in synch for replicated database 'ImpactDB'. The
> master log instant is 67:619207, whereas the slave log instant is 67:620406.
> This is fatal for replication - replication will be stopped.
> Attempt 4: ERRORCODE: 40000, SQLSTATE: XRE05, SQLERRMC: The log files on the
> master and slave are not in synch for replicated database 'ImpactDB'. The
> master log instant is 67:619207, whereas the slave log instant is 67:620780.
> This is fatal for replication - replication will be stopped.
> Before starting the slave, I freeze the master database. I ensure that no
> connections are made to the master and that all existing connections are
> closed. I wait for the disk to flush and then zip the derby files and copy to
> the slave host. I then start the slave (startSlave=true) followed by the
> master (startMaster=true).
> As you see each time, the slave log record number gets higher and higher.
> Yet, the master log record does not change as no change is made to the DB.
> When I look at the files on disk in the log and seg0 directories, they are
> the same.
> I turn on trace level logging for derby and I do not see any unexpected
> connections or SQL run during the replication attempt. Indeed, given the log
> record for the master stays unchanged it can be seen that nothing is changed
> in the database. The *.trace files show no activity between the FREEZE call
> and that start call.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
