All Of My Zope 2.6 Transactions Since 2/6/07 Are Gone!
Zope 2.6.2 on Red Hat 7.3 started acting flaky a week or two ago. It started dying every day or so. Then it lost all transactions since 2/6/07, displaying content as it was two months ago. Then it recovered the lost content, now it has lost it again. Zope Undo shows incorrectly that there were no transactions between 2/6/07 and 3/28/07 when the data loss occurred. What is the best approach to getting this data back?
Have you checked the Data.fs to determine if it has been coddled? How large is the Data.fs? Which version of Python are you using to run Zope? On Fri, 30 Mar 2007, Mark, Jonathan (Integic) wrote:
Zope 2.6.2 on Red Hat 7.3 started acting flaky a week or two ago. It started dying every day or so. Then it lost all transactions since 2/6/07, displaying content as it was two months ago.
Then it recovered the lost content, now it has lost it again. Zope Undo shows incorrectly that there were no transactions between 2/6/07 and 3/28/07 when the data loss occurred.
What is the best approach to getting this data back?
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
--
Mark, Jonathan (Integic) wrote at 2007-3-30 12:46 -0400:
Zope 2.6.2 on Red Hat 7.3 started acting flaky a week or two ago. It started dying every day or so. Then it lost all transactions since 2/6/07, displaying content as it was two months ago.
Then it recovered the lost content, now it has lost it again. Zope Undo shows incorrectly that there were no transactions between 2/6/07 and 3/28/07 when the data loss occurred.
Zope by itself cannot loose content: It stores data (by default) in a "FileStorage" and a "FileStorage" is a transaction log file. All modifications are additional transaction logs appended to the file. If you see that the latest transactions are lost, then someone else modified the storage. I know of 2 situations where such things can happen unexpectedly: * When you move or remove an open file under *nix, then all processes that have this file open continue to use it (even though it is now in a different place). Any new process, however, may no longer see modifications done after the "move/remove" (at least not at the original place). * About 2 years ago, one of my disks started to die. Linux gave me the impression that my work proceeds, just a bit slow and with tons of disk problem reports. The warning signals have been heavy enough. I made a complete backup. That was very wise because after a Linux restart, my work has been wiped out: Linux had been no longer able to store my changes on disk. It had worked only in its buffers -- and after the restart, the buffers were empty. -- Dieter
"""I know of 2 situations where such things can happen unexpectedly:""" Thanks for the assistance. I was able to recover using an XML data backup outside of Zope and move the missing content as flat files to the Apache document root on a new server. Since I have decided to abandon the old machine now I won't bother to investigate why the data disappeared. What is the lesson learned? That when you are using an old (2.6.2) version of Zope there is an increased likelihood of something bad happening. Presumably Zope 2 gets more stable with later versions. So use Yum to upgrade Zope 2 regularly.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark, Jonathan (Integic) wrote:
"""I know of 2 situations where such things can happen unexpectedly:"""
Thanks for the assistance. I was able to recover using an XML data backup outside of Zope and move the missing content as flat files to the Apache document root on a new server. Since I have decided to abandon the old machine now I won't bother to investigate why the data disappeared.
What is the lesson learned? That when you are using an old (2.6.2) version of Zope there is an increased likelihood of something bad happening.
Strictly speaking, your *first* problem was in running 2.6.*2*, rather than 2.6.4 (the latest stable release in the 2.6 line). That one should've been a "no brainer, just do it" upgrade, with fairly minimal testing. The changelogs for 2.6.3 and 2.6.4 contain a large number of bugfixes, many of which had important security or stability implications. Upgrading acros *major* versions (from 2.6.x to 2.7.x, for instance) is potentially much riskier, and should normally require more careful change management, as the chance that your third-party or custom code might break during the upgrade is much higher. For best support from the community, you really need to be running the latest stable version of a release line which is still in maintenance: at this point, 2.8.x is just about at EOL, so finding a way to migrate to 2.9.x soon would be your best bet. I would advise doing that "stepwise", moving across one major release line at a time.
Presumably Zope 2 gets more stable with later versions. So use Yum to upgrade Zope 2 regularly.
I can't say for sure what happened in your case: that you used yum to upgrade suggsests that you were also running with the RPM-supplied version of Python. For the 2.6.x line, that would've been a Python 2.1.3 or 2.1.4: the "system" verions of those Python's on RH-derived boxes were not built with large-file support enabled, which might explain the symptom you saw (rollowver on the 2Gb file size limit). Python 2.2 and later built with LFS enabled by default on almost all platforms, and thus would not have been subject to the "wraparound". Thus, most "old hands" never run with the '/usr/bin/python' supplied by their distribution for production Zope use, but rather build a separate Python which is used only to run Zope. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEbdT+gerLs4ltQ4RAregAJ47mkwUqPXWzEAvp7eWsHgcAi6E+QCfXzvq skkO2chBTrbK0ztlDMAn/vo= =lE5k -----END PGP SIGNATURE-----
participants (4)
-
Dennis Allison -
Dieter Maurer -
Mark, Jonathan (Integic) -
Tres Seaver