| Subject | Re: DB deletion |
|---|---|
| Author | Milan Babuskov |
| Post date | 2007-07-11T08:45:47Z |
--- Duleep wrote:
newcomers are completely unaware of the following issue: you can
freely delete or move the database file open by Firebird server (or
any other process). It will keep running without noticing and still be
writing at the old file - even if it's 'officially' deleted. Example,
you have a database file in:
/dbases/database.fdb
You connect to it and do some SELECTs, etc. Then you log in as root
user and move the file to /dbases/old.fdb. The connection still works
and you can select, insert, update, and do whatever you want.
Now, we can create a new database (or move some other file) to
/dbases/database.fdb. A new user can come in and establish connection.
The old one would still be working as if nothing changed. All this
time you get absolutely no errors from either Firebird or your
applications. It's a disaster waiting to happen.
To prevent this, make sure nobody is using the database file when you
delete or rename it. Useful tools for that are fuser and lsof. Make
sure you run fuser at root user, otherwise it will simply tell you
whether you are using the database file - and not whether anyone is
using it. The fuser command returns the PID (process ID) of the
program using it and you can use 'ps ax' command to determine which
process it is (probably Firebird server).
Also, make sure no uneducated user has access to database file.
BTW, if you notice this has happened while some user is still
connected, you can save your database as there is a link to it in
/proc/PID/fd/, where PID is process ID of the firebird server holding
the file open.
--
Milan Babuskov
http://fbexport.sourceforge.net
> The project has a 300 table production database which justOn Linux, the filesystem behaves differently than on Windows and many
> disappeared. Could be that someone deleted as we had open shares.
> However there were 2 developers connected for 48 hours. We realised
> the problem after rebooting the server.
>
> Subsequently we tried to delete an open database and the connected
> application continued to work until the reboot.
newcomers are completely unaware of the following issue: you can
freely delete or move the database file open by Firebird server (or
any other process). It will keep running without noticing and still be
writing at the old file - even if it's 'officially' deleted. Example,
you have a database file in:
/dbases/database.fdb
You connect to it and do some SELECTs, etc. Then you log in as root
user and move the file to /dbases/old.fdb. The connection still works
and you can select, insert, update, and do whatever you want.
Now, we can create a new database (or move some other file) to
/dbases/database.fdb. A new user can come in and establish connection.
The old one would still be working as if nothing changed. All this
time you get absolutely no errors from either Firebird or your
applications. It's a disaster waiting to happen.
To prevent this, make sure nobody is using the database file when you
delete or rename it. Useful tools for that are fuser and lsof. Make
sure you run fuser at root user, otherwise it will simply tell you
whether you are using the database file - and not whether anyone is
using it. The fuser command returns the PID (process ID) of the
program using it and you can use 'ps ax' command to determine which
process it is (probably Firebird server).
Also, make sure no uneducated user has access to database file.
BTW, if you notice this has happened while some user is still
connected, you can save your database as there is a link to it in
/proc/PID/fd/, where PID is process ID of the firebird server holding
the file open.
--
Milan Babuskov
http://fbexport.sourceforge.net