| Subject | "Mysterious" data loss |
|---|---|
| Author | Pavel Cisar |
| Post date | 2005-01-18T15:08:16Z |
Hi all,
I would like hear from anyone who have ever experienced a "mysterious"
data loss from Firebird/InterBase database on Linux. I've heard about
two such incidents before and now I've got another fresh one. It's rare,
but very real and serious phenomenon, and I would like find out the
conditions that lead to it, so I would appreciate any information about
its other occurrences in the field.
Problem description:
Data mysteriously vanish from database. It could be any data, or whole
tables etc. when database structure was altered, but database is not
damaged or corrupted in any way. From user's point, it looks like
database was suddenly reverted to some previous state (a time warp in
past), like an accidental database restore, although it didn't happen
(and from the info I've collected so far, it couldn't be this case,
although I haven't a strong evidence). This "old state" could vary from
hours to several days.
Reports that I've collected so far indicate, that this problem depends
or may depend on:
- Linux. reported on 2.4 kernel, so far no reports with other kernels
- SuperServer (no reports involving Classic)
- forced writes OFF
- the "time warp" happens when FB is restarted, or all users are
detached from the database (db is closed by server).
There is a *strong suspicion*, that this issue is related to cases, when
database is copied at OS level (cp) while opened/used by Firebird. But
due to delayed nature of this issue, I haven't any evidence of it, and
it's not easily reproducible that way (may depend on other unknown
factors). Although I haven't a strong evidence, the database is very
likely reverted to the state in the time when copy was made.
My personal opinion for now is that this is an unfortunate interaction
between FB server and OS (file cache, software raid, whatever) that
results in unsaved (or overwritten by older version) header page/tips.
Some sort of hiccup at OS file level when live db is copied.
Note for Firebird core developers:
Although I think that this isn't a Firebird bug or fault, Firebird
should prevent such "accidents" whatever the cause really is. It seems
that we have similar problem on Linux like we have on Windows file
cache. Because this problem is real and very dangerous for end users, it
would be nice if core engine Linux developers would seriously take a
look at this issue.
Best regards
Pavel Cisar
I would like hear from anyone who have ever experienced a "mysterious"
data loss from Firebird/InterBase database on Linux. I've heard about
two such incidents before and now I've got another fresh one. It's rare,
but very real and serious phenomenon, and I would like find out the
conditions that lead to it, so I would appreciate any information about
its other occurrences in the field.
Problem description:
Data mysteriously vanish from database. It could be any data, or whole
tables etc. when database structure was altered, but database is not
damaged or corrupted in any way. From user's point, it looks like
database was suddenly reverted to some previous state (a time warp in
past), like an accidental database restore, although it didn't happen
(and from the info I've collected so far, it couldn't be this case,
although I haven't a strong evidence). This "old state" could vary from
hours to several days.
Reports that I've collected so far indicate, that this problem depends
or may depend on:
- Linux. reported on 2.4 kernel, so far no reports with other kernels
- SuperServer (no reports involving Classic)
- forced writes OFF
- the "time warp" happens when FB is restarted, or all users are
detached from the database (db is closed by server).
There is a *strong suspicion*, that this issue is related to cases, when
database is copied at OS level (cp) while opened/used by Firebird. But
due to delayed nature of this issue, I haven't any evidence of it, and
it's not easily reproducible that way (may depend on other unknown
factors). Although I haven't a strong evidence, the database is very
likely reverted to the state in the time when copy was made.
My personal opinion for now is that this is an unfortunate interaction
between FB server and OS (file cache, software raid, whatever) that
results in unsaved (or overwritten by older version) header page/tips.
Some sort of hiccup at OS file level when live db is copied.
Note for Firebird core developers:
Although I think that this isn't a Firebird bug or fault, Firebird
should prevent such "accidents" whatever the cause really is. It seems
that we have similar problem on Linux like we have on Windows file
cache. Because this problem is real and very dangerous for end users, it
would be nice if core engine Linux developers would seriously take a
look at this issue.
Best regards
Pavel Cisar