Subject | Re: [Firebird-Architect] Re: [Firebird-devel] New backup technology |
---|---|
Author | Artur Anjos |
Post date | 2003-07-09T20:00:24Z |
Hi,
is that we have an option to create a shadow at any time, and the problem
remains in stopping it.
DROP SHADOW will delete the shadow file as well, so this is not an option.
Also, we have an 'obscure parameter' (obscure=not documented) in
gfix, -kill, that will make the database stop using the shadow. I'm really a
newbie in Fb source code, but it seems to me that the kill implementation is
just 'stop it, I don't care about nothing'.
(Please someone correct me here, but looking at the source it seems to me
that this operation just deletes the shadow reference in internal tables,
and change some flags to inform the engine to stop using it)
AFAIU, some work on this "kill" method will be enough to give us a workable
backup file 'on the fly'.
[
But Nickolay's propose method bring us a way not just to do to a very fast
snapshot of the database: it will open a way for incremental backups.
]
I hope this info help on this discussion.
are one of them. You can replace an hard disk without turning the unit off
(and the os will know it, and bring back the disk online)
Another issue will be 'handling'. If it's removable, we drop it all the
time. :-)
IDE hard disks prices are really atractive. Not just replacing tapes, but
almost replacing the cheap cd. :-)
Artur
> I think a strategy well worth considering is to implement a "cloneWe have been just talking about this option in fb-support. The actual state
> database" operation using
> the "create shadow" code, but closes the file as soon as the copy is
> complete. As mentioned
> earlier, this a page level copy with the engine propagating random
> access page updates below
> the running high water mark to the shadow. Following the operation, the
> clone is an exact
> copy of the database file as it existed when the last page was written.
> The clone database
> can either be copied or just retained.
is that we have an option to create a shadow at any time, and the problem
remains in stopping it.
DROP SHADOW will delete the shadow file as well, so this is not an option.
Also, we have an 'obscure parameter' (obscure=not documented) in
gfix, -kill, that will make the database stop using the shadow. I'm really a
newbie in Fb source code, but it seems to me that the kill implementation is
just 'stop it, I don't care about nothing'.
(Please someone correct me here, but looking at the source it seems to me
that this operation just deletes the shadow reference in internal tables,
and change some flags to inform the engine to stop using it)
AFAIU, some work on this "kill" method will be enough to give us a workable
backup file 'on the fly'.
[
But Nickolay's propose method bring us a way not just to do to a very fast
snapshot of the database: it will open a way for incremental backups.
]
I hope this info help on this discussion.
> An interesting observation is that IDE disks are now cheaper per unitWell, there are already equipment that uses IDE disks hot-swap. Snap Servers
> storage than high performance
> removable tapes. There are issues of removability, (snip)
are one of them. You can replace an hard disk without turning the unit off
(and the os will know it, and bring back the disk online)
Another issue will be 'handling'. If it's removable, we drop it all the
time. :-)
IDE hard disks prices are really atractive. Not just replacing tapes, but
almost replacing the cheap cd. :-)
Artur