db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Sanity Manager Assertion starting slave database with debug libs
Date Thu, 02 Oct 2008 10:35:47 GMT
Andrew Lawrenson <andrew.lawrenson@coppereye.com> writes:

> Hi again,
>     I've come across another issue trying to debug my earlier issue with replication.
 This is with derby
> &, running under java 1.6 on solaris x86.
>     I've got database replication working (with a non-encrypted database), where everything
appears to be
> fine.  The master & slave both start ok, and the actual replication appears to be
working fine, so if I
> perform work on the master then fail-over, the secondary has all the changes.
>     However, I've now tried using the derby debug libs ( and, and when
doing this, I'm
> experiencing the following assertion from the derby sanity manager:
> Caused by: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Wrong LogInstant
on log
> record (0,0) version real position (3215,92720)
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
>         at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
>         at org.apache.derby.impl.store.raw.log.Scan.getNextRecordBackward(Scan.java:403)
>         at org.apache.derby.impl.store.raw.log.Scan.getNextRecord(Scan.java:204)
>         at org.apache.derby.impl.store.raw.log.FileLogger.undo(FileLogger.java:939)
>         at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:949)
>         at org.apache.derby.impl.store.raw.xact.Xact.destroy(Xact.java:1105)
>         at org.apache.derby.impl.store.access.RAMTransaction.destroy(RAMTransaction.java:2033)
>         at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.boot(DataDictionaryImpl.java:790)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019)
>         at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(BaseMonitor.java:573)
>         at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Monitor.java:427)
>         at org.apache.derby.impl.db.BasicDatabase.boot(BasicDatabase.java:214)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2019)
>         at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:291)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1856)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1722)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService
> (BaseMonitor.java:1602)
>         at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService
> (BaseMonitor.java:1021)
>         at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
>         at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2416)
>         ... 12 more
> Now, as far as I'm aware, I'm performing all the steps required of starting replication:
> 1) I boot the master database.  the slave db should not be started at this stage.
> 2) I freeze the database with SYSCS_UTIL.SYSCS_FREEZE_DATABASE()
> 3) I zip up the database directory, and transfer it to the slave
> 4) unzip the database on the slave
> 5) I boot the slave database with startSlave=true;slaveHost=;slavePort=6959
> 6) I restart the master database with startMaster=true;slaveHost=;slavePort=6959
> This works fine with the production libs, but gets the above error on the slave (during
step 5) when
> using the debug libs.
> So, my question is - am I doing something wrong?  Or is this assertion not really valid
when using
> replication?  Any advice?

Hi Andrew,

It sounds like you're doing it the correct way. I tried to do the same,
with a debug build, but I didn't run into this problem. Please file a
bug report at https://issues.apache.org/jira/browse/DERBY so that we can
track this problem.


Knut Anders

View raw message