Hi Stefan, The issue yesterday, when it did not cleanse my recovery log (dirty recovery log), I went looking back in my recovery log, about 500 odd log_id up from the checkpoint, and all begin's had commits afterwards, although I did not check back throughout the period of the day from the previous unaffected image.
Other then doing a count on the begin / commit / rollbacks in the recovery log, I will not be able to tell. Regards, Stuart On Wed, 21 May 2008 14:28:17 +0200 "Stefan Lischke" <[EMAIL PROTECTED]> wrote: > 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 | > > +----------------------------------------------------------------------+ > > > > > > > _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
