Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 17:31, Dmitry Yemanov wrote: > 23.03.2016 18:14, Vlad Khorsun wrote: >> >> Original patch contains just "-I" switch :) For me both "inplace" and "merge" >> are ok, let decide what to use. > > My point was to replace two switches (-inplace -restore) with one > (-merge or whatever).

Re: [Firebird-devel] Physical replication using NBACKUP

24.03.2016 10:56, Dmitry Yemanov wrote: > 24.03.2016 11:33, Vlad Khorsun wrote: > >>> May I suggest to add isc_info_* code to query the backup GUID via >>> isc_database_info()? Parsing gstat output for it is very awful. >> >> I have same idea. I suppose it is better to return GUID in text >>

Re: [Firebird-devel] Physical replication using NBACKUP

24.03.2016 9:56, Dmitry Yemanov wrote: > I'm not that sure. API is for programmers and it's intended to work with > binary data. Whoever able to call isc_database_info() may easily call > (or implement) a function to format it into text. +1. Especially if nbackup service will accept binary

Re: [Firebird-devel] Physical replication using NBACKUP

Vlad Khorsun wrote Wed, 23 Mar 2016 17:43:23 +0300: > >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,

Re: [Firebird-devel] Physical replication using NBACKUP

24.03.2016 11:33, Vlad Khorsun wrote: >> May I suggest to add isc_info_* code to query the backup GUID via >> isc_database_info()? Parsing gstat output for it is very awful. > > I have same idea. I suppose it is better to return GUID in text > representation, not binary, agree ? I'm not that

Re: [Firebird-devel] Physical replication using NBACKUP

24.03.2016 9:42, Pavel Cisar wrote: > Hi, > > May I suggest to add isc_info_* code to query the backup GUID via > isc_database_info()? Parsing gstat output for it is very awful. I have same idea. I suppose it is better to return GUID in text representation, not binary, agree ? > New nbackup

Re: [Firebird-devel] Physical replication using NBACKUP

Hi, May I suggest to add isc_info_* code to query the backup GUID via isc_database_info()? Parsing gstat output for it is very awful. New nbackup switches and options should be also handled by services API. best regards Pavel Cisar IBPhoenix

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 18:14, Vlad Khorsun wrote: > > Original patch contains just "-I" switch :) For me both "inplace" and "merge" > are ok, let decide what to use. My point was to replace two switches (-inplace -restore) with one (-merge or whatever). Dmitry

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 17:01, Dmitry Yemanov wrote: > 23.03.2016 17:43, Vlad Khorsun wrote: >> >> apply new increment to the target database: >>nbackup -INPLACE -R target.fdb source-inc.nbk > > Wouldn't something like "nbackup -merge" be more user-friendly? Original patch contains just "-I"

Re: [Firebird-devel] Physical replication using NBACKUP

23.03.2016 17:43, Vlad Khorsun wrote: > > apply new increment to the target database: > nbackup -INPLACE -R target.fdb source-inc.nbk Wouldn't something like "nbackup -merge" be more user-friendly? Dmitry --

Re: [Firebird-devel] Physical replication using NBACKUP

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

Re: [Firebird-devel] Physical replication using NBACKUP

Здравствуйте! 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

Re: [Firebird-devel] Physical replication using NBACKUP

20.04.2013 21:24, Nikolay Samofatov wrote: > Hello, All! > > We use NBACKUP for physical replication of the databases. For that we added 2 > features: > > 1) We only read one sector (with header) of each page when scanning for > changes. This is helpful for > SSD media and might provide 4x-32x

Re: [Firebird-devel] Physical replication using NBACKUP

Hello. Thanks for review. Thanks. After quick review i want to point to a trivial bug in NBackup::backup_database() short null_flag = 0; - in_sqlda-sqlvar[0].sqldata = (char*) level; - in_sqlda-sqlvar[0].sqlind = null_flag; + if (level = 0) + { +

Re: [Firebird-devel] Physical replication using NBACKUP

Hello, all. Ok, I ask Dmitry Starodubov to create a patch for FB3.0 and publish it for review. Nikolay Patch against FB HEAD in attach. Dmitry Index: lang_helpers/gds_codes.ftn === --- lang_helpers/gds_codes.ftn (revision

Re: [Firebird-devel] Physical replication using NBACKUP

Patch against FB HEAD in attach. Thanks. After quick review i want to point to a trivial bug in NBackup::backup_database() short null_flag = 0; - in_sqlda-sqlvar[0].sqldata = (char*) level; - in_sqlda-sqlvar[0].sqlind = null_flag; + if (level = 0) + { +

Re: [Firebird-devel] Physical replication using NBACKUP

Hello, Vlad! To update offline copy of the database over WAN we use the following procedure in a shall script: - obtain baseline GUID of the database using GSTAT -h - pull changes using SSH+NBACKUP using baseline GUID What is the file format where changes are stored ? The same NBK file

[Firebird-devel] Physical replication using NBACKUP

Hello, All! We use NBACKUP for physical replication of the databases. For that we added 2 features: 1) We only read one sector (with header) of each page when scanning for changes. This is helpful for SSD media and might provide 4x-32x speed up. This is probably not important for FB3, as it

Re: [Firebird-devel] Physical replication using NBACKUP

20.04.2013 21:24, Nikolay Samofatov wrote: Hello, All! We use NBACKUP for physical replication of the databases. For that we added 2 features: 1) We only read one sector (with header) of each page when scanning for changes. This is helpful for SSD media and might provide 4x-32x speed up.