23.03.2016 14:32, Dmitry Kuzmenko wrote:
> Здравствуйте!
>
> Tuesday, March 22, 2016, 4:40:23 PM, you wrote:
>>> 2) We added option into NBACKUP utility to create change set based on
>>> baseline GUID rather than level.
>
> VK> Basic tests show it works :) If anyone have idea how to improve it -
> you are welcome.
> VK> For example, we could introduce special switch to query backup GUID of
> target database
> VK> to pass in into backup automatically.
>
> as I understand correctly (maybe not), this is equivalent how InterBase's
> "online dump"
> feature works.
Not really so. Let me explain again (after original letter by Nickolay). The
patch adds
a) for backup: ability to set "database backup GUID" as previous (starting)
point for
increment backup.
Note, "database backup GUID" is changed every time when database backup is
made. All that
backup GUID's are stored in RDB$BACKUP_HISTORY table, therefore one can set
desired backup
level as a "starting point" for new backup or use backup GUID for the same
goal. Current
backup GUID is stored at database header page.
b) for restore: new INPLACE option allows to apply increment backup to the
existing database.
Target database automatically set into read-only mode after such restore.
Let me show how it works. It is very simplified example, of course.
Create database source.fdb.
Create level-0 backup, as usual:
nbackup -B 0 source.fdb source-0.nbk
Restore level-0 backup, as usual:
nbackup -R target.fdb source-0.nbk
Every N minutes:
{
obtain backup GUID of target database:
gstat -h target.fdb | findstr /C:"Database backup GUID:"
create new incremental backup using GUID above:
nbackup -B {93070E3C-E63F-4FB3-B89A-10C732BDEAC3} source.fdb source-inc.nbk
apply new increment to the target database:
nbackup -INPLACE -R target.fdb source-inc.nbk
}
This is all you need to have read-only copy of source database refreshed
every N minutes.
> InterBase cannot produce "level increments", like Firebird, but it can
> write changes since -b 0 to the -b 0 file.
>
> If I'm right, I think using GUIDs in the command line is totally
> useless.
Hope you have another opinion now :)
> How InterBase do this
> gbak -d db.ib db.dump
>
> if db.dump does not exist, it will be created, and the result will be
> equivalent of
> nbackup -b 0 db.fdb db.nb0
>
> except InterBase after dump makes db.dump read-only,
as Firebird does, see above
> and another
> instance can work with this file without any problem.
This is not fully true, sorry, see below
> Next command
> gbak -d db.ib db.dump
> will only write changes from db.ib since this command was run last
> time. After that db.dump have the same state - read-only.
> If IB needs to overwrite dump, like -b 0 again, -ov switch is used
> gbak -d -ov ...
>
> Since Firebird always overwrite files during nbackup -b 0
> I suggest to add nbackup switch that will APPEND changes to nbackup
> file level 0.
> Example
> nbackup -b 0 db.fdb db.nb0
>
> this will always overwrite db.nb0
>
> nbackup -b 0 -ap db.fdb db.nb0
> this will append changes, accumulated in db.fdb from the last -b 0.
>
> But, in this case nbackup must understand that none "increments"
> were missing between
> nbackup -b 0 db.fdb db.nb0
> and
> nbackup -b 0 -ap db.fdb db.nb0
> nbackup -b 0 -ap db.fdb db.nb0
> ...
>
> If I'm not understood what Nikolay have done, consider this message as
> a feature request.
> This feature is very good for scalability - to allow split load of one
> database between two servers. read-only "copy" of the database can be used
> to run reports, etc.
Such read-only copy could be used for read-only queries, no doubt. But it is
safe between two restore (apply increment) moments only. Else one have a big
chance to create non-consistent report: if report started before new increment
arrives and continue to work after new increment applied - it could be that
report's transaction snapshot is not exists anymore and even "snapshot"
transaction will not see a consistent view of database. It could be even worce -
if metadata on source database was changed.
Therefore i don't think Interbase have really working hot-standby solution,
unless i know not all details. So, working with target database is possible,
but all user connections should gone before applying of new increment - else
metadata cache on the target database could be not correct. Even if there is
guarantee of stable metadata, all user queries and transactions should be
finished
before applying of new increment.
> And it can be updated from the main database each 30-10 minutes, if
> there any need of this. Especially with Firebird 3.0 SCN feature, wich
> allow nbackup to scan db very fast.
You may try snapshot build of FB 4 with this feature, btw ;)
Regards,
Vlad
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
