Hi Stuart, That sounds so familiar to my problem. I get this if there are transactions committed to node1 while making a backup on node2.
hth Stuart James wrote: > Hi Emmanuel, > > > > We ran into the same issue again last night. I actually missed out part > mentioning in yesterday's response, we do indeed use transactions with > Begin/Commit, but not on our primary application, which is where I had > focused my attention. Last night, as the night before where I was > misguided to what I thought the problem was, it was in fact our Web > application tier, which is a Hibernate implementation which uses the > c3p0 JDBC pool implementation. Is there any known issues for c3p0 and > Sequoia? > > > We did see this also last night > > 2008-05-21 01:45:08,483 WARN sequoia.controller.recoverylog Recovery > log is dirty. Clearing. Please use restore log > > Currently our automated script, will take an image, and then purge the > log from the image taken 3 days ago, so the above could have been > related to anything from the 3 days prior. > > 2008-05-21 01:49:48,599 WARN sequoia.controller.scheduler Timeout in > begin, still waiting for 0 pending transactions to complete > > 2008-05-21 01:49:48,599 WARN controller.virtualdatabase.XXXX Begin > failed (Timeout in begin, still waiting for 0 pending > transactions to complete) > > 2008-05-21 01:49:48,599 INFO > virtualdatabase.VirtualDatabaseWorkerThread.XXXX Error during command > execution (Timeout in begin, still waiting for 0 pending transactions > to complete) > > > For me to fix this last night, I had to disable our web application > servers from accessing the Sequoia cluster (not our primary > application which does not use transactions) as a result of doing this > the pg_dump started up. > > My question is, now that I know it is related to these web > applications, which are using proper transactions, is it possible there > is a begin without a commit / rollback in the recovery log, and if so > is this why the sequoia is telling me it is a dirty recovery log as > I had to manually shut those web applications down to release the lock > on the transaction? If this is true, is there a potential that there is > a pending open transaction from one of the web applications? > > I would try to tie that up based on our recovery log, but it was purged > as a result of Sequoia claiming it was dirty. > > Would the same occur if we had just done a disable on the backend ? > > Regards, > > > Stuart > _______________________________________________ > Sequoia mailing list > [email protected] > https://forge.continuent.org/mailman/listinfo/sequoia > > > > +----------------------------------------------------------------------+ > | Z1 SecureMail Gateway Info - http://www.zertificon.com | > +----------------------------------------------------------------------+ > | - Die Nachricht war weder verschluesselt noch digital unterschrieben | > +----------------------------------------------------------------------+ > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
