Subject Re: [firebird-support] Re: FB database in RAM
Author Kjell Rilbe
Den 2011-08-05 09:04 skrev Lester Caine såhär:
> Large sections of a database are only going to be read, so is there any
> way that
> the heavy read/write pages could be maintained in 'RAM' while pulling
> the bulk
> of the data from an SSD array? Yes there is potential for corrupt
> database, but
> if the data is stable even that should be manageable? It's only the
> actively
> changing data that needs to be protected?

This is actually along the lines I was thinking, except that I wouldn't
even use SSD:s.

I'd like to setup the main database on a RAM disk. With powerful and
reliable UPS, like the one our hosting company has, will make sure that
power loss is not very likely. ECC RAM modules will also protect pretty
well against RAM failures. So, in all, the RAM disk should be rather
well protected against data loss.

This will be used by the app for "everything", so both reads and writes
will be lightning fast.

But, we also need something on persistent storage. So, I'd like to setup
a replicator to replicate from the RAM database to one that resides on a
regular disk, e.g. a RAID1 volume with 15 krpm SCSI disks, or even
something cheaper than that.

I'm not really up to date on replication on FB, but I assume there are
free or cheap replicators that can handle our simple schema and DB
usage, where we have no SP:s and no triggers or generators. (It's
maintained by ECO which contains a fairly DB agnostic OO mapper). All
DML is simple select, insert and update. I assume a replicator would
copy replicate on transaction commit and at that stage copy everything
that happened during that transaction to the target database inside a
single target transaction.

In case of crash or powerloss in the middle of such a copy operation,
the secondary persistent copy of the database should be intact and up to
date up to but not including the transaction that was being copied at
the time of crash. Data loss would be negligable for our purposes.

I'd also use other means to backup the secondary database to a backup
volume every night.

Can anyone see any problems with such a setup?

Kjell Rilbe
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64