[Zope] Corrupt ZODB on W2k
Chris Kratz
chris.kratz@vistashare.com
Sat, 12 Jan 2002 11:08:32 -0500
On Friday 11 January 2002 07:24 pm, Tom Cameron wrote:
> They are packing manually from the ZMI, so I dont think that is it, but you
> have just reminded me that they are also backing up the ZODB nightly from a
> batch script, by copying the ZODB to another location.
>
> Perhaps this could be the problem - a conflict at the time of reading??.
>
> Tom
I really don't know how this behaves under Win2k, but we back up nightly
without interrupting zope. We are running under Linux, so your mileage may
vary under W2k. It would seem unlikely that copying from the data.fs would
cause it to become corrupted under any OS. If you were making some change to
the data.fs during the backup, that might explain it. I think perhaps the
problem lies elsewhere. But, if you want to be sure, you might add bringing
down the zope service before your backup each night and then bring it back up.
Have you tried checking your backups to pinpoint when the corruption
happened? If not much changes, you might be able to find at what point the
files are getting corrupted. Perhaps someone else with more experience can
suggest an easier way to track down the issue. When we started having the
problems, I simply went day by day back through the backups reloading the
data.fs into a test zope. Our errors always happened when we accessed a
specific folder, so it was pretty easy to find the day that no longer caused
this error. You might try comparing that day with the next days backups and
perhaps check the calendar to see if anything else unusual happened that day.
Once we tracked down what was causing our problems, zope has been rock solid.
One final thing, I find it interesting that exporting and importing seems to
fix your problem. For us, the export/import trick didn't fix the corruption,
nor running the fsrecover.py(nothing to fix) script provided with zope. That
almost implies that for your problem, the data is fine, but something else is
getting messed up. Do you export and import the acl_users? Are you using
standard user folders, or an add-in. If it is permision related, you might
want to check that out.
Good luck,
-Chris
> => -----Original Message-----
> => From: Chris Kratz [mailto:chris.kratz@vistashare.com]
> => Sent: Saturday, 12 January 2002 9:57 AM
> => To: tom@mooball.com
> => Subject: Re: [Zope] Corrupt ZODB on W2k
> =>
> =>
> => Hello Tom,
> =>
> => How are you packing your database? We had a corruption problem
> => on a regular
> => basis that happened because I had automated the packing of our
> => database by
> => using client.py in a nightly script. I removed this call from
> => nightly script
> => and have been packing by hand since and have not had any
> => corruption problems.
> => After having tracked it down, I was able to duplicate the problem very
> => easily by doing the pack from the python script on a backed up
> => known good
> => version of the zope file. The next time the pack ran from a script, for
> => whatever reason, it corupted the database every time. If I
> => packed manually
> => (from the web interface) on the backup, it ran without incident and the
> => database was not corrupted. Our corruption tended to be folders
> => that became
> => inaccessible from the zmi due to key not found errors.
> =>
> => I don't know if this is applicable to your problem or not as our
> => platforms
> => are different and the symptoms are not exactly the same, but I thought I
> => would through it in for good measure. It might give you a good place to
> => start looking.
> =>
> => Good luck,
> =>
> => -Chris
> =>
> => On Friday 11 January 2002 05:20 pm, you wrote:
> => > A client of mine insisted in running Zope on Win2k, so I installed
> Zope => > 2.3.4 (some time ago) on their server and also a few
> => products/sites I built
> => > for them.
> => >
> => > The machine has been running now for about 8 months. They don't change
> => > much, but it is relatively heavily loaded. They pack the ZODB
> => monthly and
> => > backup regularly.
> => >
> => > On two occasions in the past 8 months, we have noticed very peculiar
> => > permissions problems. Several months ago, all of a sudden,
> => several of the
> => > users could no longer access the ZMI. Also sections of the
> => site returned
> => > permissions errors for no reason. Sometimes specific DTML
> => methods simply
> => > refused to display with permissions errors.
> => >
> => > After many hours of investigating we found no possible logic to this.
> I => > then exported the entire ZODB and re-imported it all into a
> => fresh ZODB. All
> => > was fine again.
> => >
> => > Now, several months later the same problem has re-appeared.
> => Again they get
> => > weird permissions errors on certain objects, but no real logic
> => or pattern
> => > to the errors. Creating new users does not always work. Old users get
> => > locked out. Some DTML methods will not work.
> => >
> => > It looks very much like the ZODB simply gets corrupt over time.
> => >
> => > I can fix this by exporting-importing again, but I am
> => wondering if anybody
> => > else has any experience of a similar problem or solution?
> => >
> => > Tom
> => >
> => >
> => >
> => > _______________________________________________
> => > Zope maillist - Zope@zope.org
> => > http://lists.zope.org/mailman/listinfo/zope
> => > ** No cross posts or HTML encoding! **
> => > (Related lists -
> => > http://lists.zope.org/mailman/listinfo/zope-announce
> => > http://lists.zope.org/mailman/listinfo/zope-dev )
> =>
> => --
> => Chris Kratz
> => Systems Analyst/Programmer
> => VistaShare LLC
> => www.vistashare.com
> =>
>
>
> _______________________________________________
> Zope maillist - Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope-dev )
--
Chris Kratz
Systems Analyst/Programmer
VistaShare LLC
www.vistashare.com
--
Chris Kratz
Systems Analyst/Programmer
VistaShare LLC
www.vistashare.com