Dear All, The system clock of our Zope 2.7 machine accidentally got set to 2009. We noticed this mistake 6 hours later and we decided to set back the clock to 2008. How does this affect the integrity of Data.fs ?
From our observation :
1. Session write errors suddenly began to appear 2. Data.fs.index won't grow anymore and its timestamp remained at the time we set back the clock 3. Packing the database (which was 8 GB at the time) took too long without any signs of any Data.fs.pack file in the var folder. We decided to restart Zope after a few minutes. 4. There seem to be some catalog indexing problems as our catalog searches on a certain field doesn't work as reliably as it did before. We tried reindexing the field and even the catalog, but it timed out on us (lots of objects in the database). Has anyone here had any similar experiences ? How do I go about fixing this ? Using repozo.py last night, I made a full backup of Data.fs, copied it to a new instance, was able to create a new Data.fs.index, and eventually succeeded in packing the 8 GB database to just 2.4 GB. But it took quite a while - like 10 or 15 minutes before any Data.fs.pack appeared. I haven't checked yet if the catalog indexing problem has gone away. Regards, Danny
--On 6. Mai 2008 10:28:29 +0800 "Sinang, Danny" <D.Sinang@spi-bpo.com> wrote:
Dear All,
The system clock of our Zope 2.7 machine accidentally got set to 2009. We noticed this mistake 6 hours later and we decided to set back the clock to 2008.
How does this affect the integrity of Data.fs ?
From our observation :
1. Session write errors suddenly began to appear
2. Data.fs.index won't grow anymore and its timestamp remained at the time we set back the clock
3. Packing the database (which was 8 GB at the time) took too long without any signs of any Data.fs.pack file in the var folder. We decided to restart Zope after a few minutes.
4. There seem to be some catalog indexing problems as our catalog searches on a certain field doesn't work as reliably as it did before. We tried reindexing the field and even the catalog, but it timed out on us (lots of objects in the database).
Has anyone here had any similar experiences ? How do I go about fixing this ?
Turning the clock back is known to result in data inconsistencies. It is is best-practice having NTP installed on all Zope machines. -aj
Thanks. Is there a way to spot these data inconsistencies in Data.fs and remove or fix them ? Regards, Danny -----Original Message----- From: Andreas Jung [mailto:lists@zopyx.com] Sent: Tuesday, May 06, 2008 12:31 PM To: Sinang, Danny; zope@zope.org Subject: Re: [Zope] Turning back system clock --On 6. Mai 2008 10:28:29 +0800 "Sinang, Danny" <D.Sinang@spi-bpo.com> wrote:
Dear All,
The system clock of our Zope 2.7 machine accidentally got set to 2009. We noticed this mistake 6 hours later and we decided to set back the clock to 2008.
How does this affect the integrity of Data.fs ?
From our observation :
1. Session write errors suddenly began to appear
2. Data.fs.index won't grow anymore and its timestamp remained at the time we set back the clock
3. Packing the database (which was 8 GB at the time) took too long without any signs of any Data.fs.pack file in the var folder. We decided to restart Zope after a few minutes.
4. There seem to be some catalog indexing problems as our catalog searches on a certain field doesn't work as reliably as it did before. We tried reindexing the field and even the catalog, but it timed out on us (lots of objects in the database).
Has anyone here had any similar experiences ? How do I go about fixing
this ?
Turning the clock back is known to result in data inconsistencies. It is is best-practice having NTP installed on all Zope machines. -aj
--On 6. Mai 2008 12:37:50 +0800 "Sinang, Danny" <D.Sinang@spi-bpo.com> wrote:
Thanks.
Is there a way to spot these data inconsistencies in Data.fs and remove or fix them ?
You might ask Google. This topic came up several times in the past. -aj
Sinang, Danny wrote at 2008-5-6 10:28 +0800:
The system clock of our Zope 2.7 machine accidentally got set to 2009. We noticed this mistake 6 hours later and we decided to set back the clock to 2008.
How does this affect the integrity of Data.fs ?
Formerly, it was deadly. Nowadays, most operations will succeed but packing will no longer be possible (until 2009). Here some explications. A "FileStorage" file is a list of transaction records, identified by a transaction id, which usually is also a timestamp. "FileStorage" requires that the transaction ids are strictly increasing. If transactions records were written (i.e. the corresponding transactions committed) while you have had the wrong time, then your storage contains some transaction records with ids corresponding to a date in 2009. To ensure that transaction ids are increasing, all new transaction ids are forced to be larger than all existing ones. This means, they seem to have happened in 2009 immediately after the latest one -- all of them within an incredibly short time span. As packing is usually important, you need to fix your storage before it can be used again in a normal way. You would use the "transaction iterators" in the "FileStorage" package to read all transactions, fix the transaction id (if necessary) and then write it to a new storage file. -- Dieter
participants (3)
-
Andreas Jung -
Dieter Maurer -
Sinang, Danny