Error from Topaz fullBackupTo:

I'm not clear, excuse !

Ciao, 

very thanks....

     And if i right understand i can switch from master to slave in real time ( some minutes? ).

When you need to activate your slave, you

1. stop the logreceiver

2. SystemRepository commitRestore

This is really quick (a few seconds)

3. Switch over your web server to talk to the slave. Here you may have

to think a bit how you want to do it. If your web server is on master,

you may have to do a DNS change (if the master machine is dead). If it

is alive, you can route traffic to the slave using the firewall or

some other way.

Very well.

     But it required some hardware and .... configuration.....

     I think to use it to very 24x7 maximum guarantee system and continuity of service.

Yes, I think it is a decent solution. There is no absolute guarantee

though. You have to be sure that the logsender / receiver have caught

up all the log entries and you may have switched over on a point where

you lost a last transaction.

     Restore the system to the last tranlog backup is not sufficient.

     As the customer can realign the system if the last backup tranlog is 30 minutes old?

I don't really get what you're saying here.

Ok, excuse.

I'm thinking about system without any standby system.

 I have only the server where the cron execute a script for create a new tranlogs every delta time ( 30 minutes? )

But a system where i create a new tranlogs every 30 minutes and i save the old tranlogs on the backup system every 30 minutes.

Where for backup system i think at one PC or disk in the LAN with only the copy of the files:

1) the last repository  backup
2)  old tranlogs ( create every delta minutes )
3)  the " online copy" of the current tranlogs


If the server go down i can setup a new machine and restore the repository from the data save on this backup system.

Fail to follow my reasoning?

With this configurations i can ensure restoration of data without losing any transaction.

It's correct ?

In this case on the backup system i have the last repository backup ( do every night ) and the relative old tranlogs  ( create in sequence every 30 minutes )

but i don't have any "copy" of the current tranlogs.

In this case if the master system go down i lose the last online tranlogs ( with the transactions relative to the current 30 minutes )

If you have the tranlogs on master, then you can replay until the last

transaction, when your system comes back up.

If your tranlogs are lost on master but you restart with the existing

extent(s), you may have lost transactions.

If you have a hot standby in place, you are as up to date as you can

be if you lose tranlogs on master.

If not losing tranlogs on master is really critical, I'll consider

RAID and what other "safe" disk options you can get to store your

tranlogs on. Gemstone also has a replicate tranlog directory which you

can mount on a remote machine or something else.

I don't know this options.

It's a possible solutions ! ?

The Gemstone replicate the online tranlogs in this directory on 'external' system ?

If yes, i have a "copy" of the online tranlogs and i can restore from backup system to the last transaction.

I don't find reference to this options  in the System Administration Guide 3.1.

This options i very interesting if works as i think.

Reference about it?

Thanks,

Dario

     Where i found the last 30 minutes transaction if the server is dead?

On the hot standby

I write these considerations, thinking to a system without standby.

     I think having an intermediate solution could resolve many situations.

     Having the ability to have a online copy of the active tranlog on the backup system it's a very good solution.

     Is possible use the logsender / logreceiver only to replicate the current logs on the backup system ?

I need only to have the "copy" of the online tranlogs.

If I did run a hot standby, I do not worry about replicating tranlogs

because this is what the logsender / receiver does

     With this support and the last  production backup  it's possible restore the system without losing any transactions.

     But these are my considerations.....

Thanks,  CIAO,

Dario

_______________________________________________

Glass mailing list

[hidden email]

http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I think Dale's concerns are related to disk / hardware failures. I do
not think that these possible concerns are a GemStone specific thing.
If you throw quality hardware at it, with RAID 5 and UPS (as you've
mentioned) and what not (quality server components, disks, RAM, etc),
then you're doing well to protect your transactions from being lost
(regardless of what software system you are running). You can even go
further with fancier hardware that replicates disks across a SAN disk
solution, etc.

If you do the hot standby thing you protect yourself more by doing a
GemStone transaction log replication as and when transactions are
written (no realtime guarantees though).

If you copy your tranlogs to another server before rebooting, then
you're more safe from losing the files if the disk does not come back
after the reboot.

In the 20 years that I've worked with GemStone, in 4 different
installations, we've not lost data because of malfunction of GemStone
software.

Now that deserves some kudos.
-----------------------------------------

We run our extent files in RAM, write tranlogs to disk (no RAID or
anything) and run hot standbys in a different data centre. On hot
standby we write the extent and tranlogs to disk. I believe that
running a production extent in RAM reduces probability of failure
because our databases do a load of random reads, which will wear a
mechanical disk more easily than RAM.

We have not had a failure in 8 years (and currently 8 live systems).

I hope this gives you some comfort.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Ciao Behrens,

        thanks for your considerations.

Of course, i think at disk, hardware failures or a restart problematic ( after a shutdown the system don't start )

In any case i need to have the backups data:

                1) the last repository backup ( do every night )
       
                2) the relative old tranlogs  ( create after the last repository backup  )

                3) the "copy" of the current tranlogs ( the last tranlogs updated to the latest transactions )

        for restart ( in each case ) a new system with data update at the latest transactions.

        For point 1 - 2 i think a disk,  where regularly save their related files.

        For point 3 i think a 'online copy' of the last tranlogs, but i  do not know how to handle such a solution.

> If you throw quality hardware at it, with RAID 5 and UPS (as you've
> mentioned) and what not (quality server components, disks, RAM, etc),
> then you're doing well to protect your transactions from being lost
> (regardless of what software system you are running). You can even go
> further with fancier hardware that replicates disks across a SAN disk
> solution, etc.

I don't know about SAN disk solutions, the only know is the limited budget.

> If you do the hot standby thing you protect yourself more by doing a
> GemStone transaction log replication as and when transactions are
> written (no realtime guarantees though).

In some my solutions the hot standby is not required ( i can't have another PC for do it )

I need only to replicate somewhere the online tranlog.

>
> If you copy your tranlogs to another server before rebooting, then
> you're more safe from losing the files if the disk does not come back
> after the reboot.

OK, i can do it if i'm linked to the server.

But if the system go down in the night after a power cut ?

>
> In the 20 years that I've worked with GemStone, in 4 different
> installations, we've not lost data because of malfunction of GemStone
> software.
>
> Now that deserves some kudos.

        +10

I am sure and confident.

I just have to focus on the issues, and understand the best solutions.

Thanks,

        Dario

P.S. You can found some my points of view in my last emails: Re: [Glass] Backup procedure
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass