Subject | Re: [ib-support] Firebird and Network Attached Storage? |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2002-01-16T08:59:23Z |
All,
The trouble with constant backups are the amount of traffic & speed,
backing up to a GDB seems a cool feature, as long as you can backup delta's
to be able to do either incremental or differencial backup. The DB's we are
using are > 10GB and a backup / restore cycle takes 10 hours with no users
when the backup is taking place.
Proposed syntax: gbak ........ from_transaction 1234567890
Also an option in gbak so that when it backs up it can return the lowest
commited transaction or whatever.
We currently use home grown replication - it costs more in terms of having
to have duplicate hardware, but it does mean that:
1) IB engine failures that could corrupt the GDB do not get transmitted -
this would be the case for the switched drive array
2) Reduces single point of failure (drive array burns out, cable fails...)
3) We have our backup server at the other end of BT's LES service (100Mb/s
dedicate MAN), 2 miles away, so we are covered for lots of eventualities.
The service is relatively cheap, bt broad enough that in an complete server
failure we could run the server from there with the clients here.
Things that would hugely help replication are:
1) triggers bound to multiple events and multiple tables.
2) an equality operator that negates the need for
if (new.a <> old.a) or (new.a is null and old.a is not null) or (new.a is
not null and old.a is null) then ....
3) being able to iterate fields in a loop DML
4) select * from table where lastCommitedTransaction > 1234567890
5) Blob equality without having to shell out to UDF's
Am I too late for Christmas Sean - this is just my wish list - I still
haven't got a build environment for FB Windows & it scares the living
daylights out of me when I look at the code in checkins. If I could
regularly build the Windows version and got off my backside and got the
correct development environment I would love to contribute to the
development of these. I need to have a look on the IBPhoenix CD to see if
there are all of the components I need there, it would be useful.
Back to the plot - I think replication wins out, we also replicate to tiny
servers, i.e. Beefy Compaq 1GB, 340GB -> WS 128MB 40GB (DB > 10GB), and one
of the joys of FB is that if all else failed we could run the core company
components off of the laptop I am currently typing on.
Just my 2c (my words are cheap).
JAC.
""Leyne, Sean"" <sleyne@...> wrote in message
news:66187D861C1747499BE1365B74E0369102A83B@......
The trouble with constant backups are the amount of traffic & speed,
backing up to a GDB seems a cool feature, as long as you can backup delta's
to be able to do either incremental or differencial backup. The DB's we are
using are > 10GB and a backup / restore cycle takes 10 hours with no users
when the backup is taking place.
Proposed syntax: gbak ........ from_transaction 1234567890
Also an option in gbak so that when it backs up it can return the lowest
commited transaction or whatever.
We currently use home grown replication - it costs more in terms of having
to have duplicate hardware, but it does mean that:
1) IB engine failures that could corrupt the GDB do not get transmitted -
this would be the case for the switched drive array
2) Reduces single point of failure (drive array burns out, cable fails...)
3) We have our backup server at the other end of BT's LES service (100Mb/s
dedicate MAN), 2 miles away, so we are covered for lots of eventualities.
The service is relatively cheap, bt broad enough that in an complete server
failure we could run the server from there with the clients here.
Things that would hugely help replication are:
1) triggers bound to multiple events and multiple tables.
2) an equality operator that negates the need for
if (new.a <> old.a) or (new.a is null and old.a is not null) or (new.a is
not null and old.a is null) then ....
3) being able to iterate fields in a loop DML
4) select * from table where lastCommitedTransaction > 1234567890
5) Blob equality without having to shell out to UDF's
Am I too late for Christmas Sean - this is just my wish list - I still
haven't got a build environment for FB Windows & it scares the living
daylights out of me when I look at the code in checkins. If I could
regularly build the Windows version and got off my backside and got the
correct development environment I would love to contribute to the
development of these. I need to have a look on the IBPhoenix CD to see if
there are all of the components I need there, it would be useful.
Back to the plot - I think replication wins out, we also replicate to tiny
servers, i.e. Beefy Compaq 1GB, 340GB -> WS 128MB 40GB (DB > 10GB), and one
of the joys of FB is that if all else failed we could run the core company
components off of the laptop I am currently typing on.
Just my 2c (my words are cheap).
JAC.
""Leyne, Sean"" <sleyne@...> wrote in message
news:66187D861C1747499BE1365B74E0369102A83B@......
> Artur,
>
> > Another good thing it's gbak to produce a 'ready to work'
> > file. I think this is already on 'things to do list' on
> > Firebird Project. A backup that generates a file that
> > can be used rigth away, without restore.
>
> This was my original idea. I couldn't see someone using GBAK to backup
> and/or restore a large database -- it takes way too long.
>
> I had started working out the details of the implementation but got
> side-tracked with a lot of other things.
>
> Are you interested in working on this?
>
> How are you at C++ programming? (This will be a FB2 task/project)
>
>
> Sean
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>