Re: Back up options

From: Bernard Peek <bap_at_shrdlu.com>
Date: Fri, 11 Apr 2003 15:46:21 +0100
Message-ID: <$CtcRnA9Utl+Ew+P_at_diamond9.demon.co.uk>


In message <b04c1374.0304110038.1bd51268_at_posting.google.com>, chris <xnuus_at_hotmail.com> writes
>Hi,
>
> Heres my problem which Im sure someone has experience of. I have a
>database that quite simply because of the importance of the data needs
>to be backed up after every transaction, how do I achieve this.
>
>options:
>
>1. maybe a little crude, I could email the records to an account after
>after every transaction using a simple script
>
>2. have two concurrent databases running in two separate machines
>writing to both rolling back on connection problems.
>
>3. Mirror the database, whats mirroring, I'm using Mysql, not
>microsoft SQl server but can make the leap to the darkside if deemed
>necessary.

Switching to SQL Server would solve the problem but it might not be necessary.

The way that SQL Server would handle it is by logging each transaction against the database. This is a standard feature of SQL Server. The log file is usually stored on a separate drive to the data file so that a single hardware failure doesn't take out both of them. You also have the option to have the transaction data shipped across a network to another machine where it can be used to synchronise another database.

Lastly, you have the option of using clustering. That would entail having multiple machines connected together so that if any of them fail the rest take up the load.

You don't mention whether high availability is a priority. Is the priority to avoid losing data or to keep the database system running? Those aren't necessarily the same thing.

-- 
Bernard Peek
bap_at_shrdlu.com
www.diversebooks.com: SF & Computing book reviews and more.....

In search of cognoscenti
Received on Fri Apr 11 2003 - 16:46:21 CEST

Original text of this message