[jira] [Commented] (DERBY-7017) Derby replication not working

["Rick Hillegas (JIRA)" <ji...@apache.org>]

    [ 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)