Subject | Re: Stopping Firebird on Linux |
---|---|
Author | Alexander V.Nevsky |
Post date | 2004-04-20T19:09:59Z |
--- In firebird-support@yahoogroups.com, "elangelct" <elangelct@y...>
wrote:
database shutdown before this you can decrease risk but not entirely.
years. Anyway, you are very risky person if you make restore
overwriting production database. Some kinds of database corruption can
be detected on restore only and in this case you lost source database
(where problem usually can be easy fixed) because restore was already
started, and have only unrestorable gbk. I recommend make backup and
restore into another file to be sure gbk is restorable but replace
source database only manually being absolutely sure. BTW, why you want
to refresh your database daily? It is enough usually to make sweep at
night. When I worked on IB4 I could'nt use backups because there were
many explicitly planned queries in stored procedures within my
database and IB4 gbak could'nt restore such procedures. So, I nightly
killed forgotten by users connections and made file copy to have
reserve copy each day. My statistics was - approximately 1 corruption
for 8 month, one time corruption was unrecoverable. Since I migrated
to FB and make at night
shutdown database
backup without garbage collection
transfer gbk onto another computer and perform control restore
simultaneously sweep on main database
online database
I had only 1 corruption because of hard drive malfunction.
Best regards,
Alexander.
wrote:
> I have Firebird CS 1.0.3 on Debian Linux.Yes, you can (not necessary, but can) corrupt database. Making
>
> The service is installed in inetd.
>
> I'm doing a nigthly backup script that backup and restore the gdb, but
> in one momment of the script i need noone connected to te gdb.
>
> If the firebird was installed on init.d scripts /etc/init.d/firebird
> stop -> Stop the server.
>
> But inetd stop doesnt disconnect the clients.
>
> Killall gds_inet_server disconnect all the clients, but i think that
> is not the correct way.
database shutdown before this you can decrease risk but not entirely.
> There is a way to cleanly disconnect all the clients connected to theUnfortunately - no or at least I don't know, though searched this 8
> server when the server is running on inetd?
years. Anyway, you are very risky person if you make restore
overwriting production database. Some kinds of database corruption can
be detected on restore only and in this case you lost source database
(where problem usually can be easy fixed) because restore was already
started, and have only unrestorable gbk. I recommend make backup and
restore into another file to be sure gbk is restorable but replace
source database only manually being absolutely sure. BTW, why you want
to refresh your database daily? It is enough usually to make sweep at
night. When I worked on IB4 I could'nt use backups because there were
many explicitly planned queries in stored procedures within my
database and IB4 gbak could'nt restore such procedures. So, I nightly
killed forgotten by users connections and made file copy to have
reserve copy each day. My statistics was - approximately 1 corruption
for 8 month, one time corruption was unrecoverable. Since I migrated
to FB and make at night
shutdown database
backup without garbage collection
transfer gbk onto another computer and perform control restore
simultaneously sweep on main database
online database
I had only 1 corruption because of hard drive malfunction.
Best regards,
Alexander.