Geraldine created DERBY-7017:
--------------------------------
Summary: 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.2.0, 10.14.1.0
Environment: Linux
Reporter: Geraldine
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)