Hi !

Before I begin, this is a "no problem = no Tim required"-Thread

I have absolutely no experience with replication, but maybe someone has, and and can save
me some time trying out ridiculuos things.

I thought about placing the database files into a RAMDisk - blazing fast DB, but what
about power loss. Is EDBs replication feature capable of doing something like a mirroring
of the database to a physical disk, in, let's say snapshots every five minutes ?

Will the performance hit of the server saving updates from the RAMDisk and loading updates
to the physical disk be so hard, that I have no speed difference to the status quo at all ?

And what about alterations of the database ? DML statements are replicated, but what about
DDL statements ? Would be very nice if I wouldn't have to care about the physical DB at all.

Maybe someone who already worked with EDB replication can enlighten me a bit...

TIA,

Heiko

Heiko,

<< Before I begin, this is a "no problem = no Tim required"-Thread >>

Wow, kicked out before I've even said anything impolite.

<< I thought about placing the database files into a RAMDisk - blazing fast
DB, but what about power loss. Is EDBs replication feature capable of doing
something like a mirroring of the database to a physical disk, in, let's say
snapshots every five minutes ? >>

Sure, this is certainly possible.  The issue is with the job scheduling - at
the moment we only allow an interval granularity of one hour.  I can see
about adding a minute interval, however.

<< Will the performance hit of the server saving updates from the RAMDisk
and loading updates to the physical disk be so hard, that I have no speed
difference to the status quo at all ? >>

Well, what you would be doing is the equivalent of "checkpointing", and the
key with such a technique is balancing the frequency of the checkpoints with
the possible loss of data if the machine were to go down.  The more frequent
the checkpointing, the more the performance will resemble normal operation.

<< And what about alterations of the database ? DML statements are
replicated, but what about DDL statements ? Would be very nice if I wouldn't
have to care about the physical DB at all. >>

DDL statements are a bit of an issue - they are not replicated and would
need to be applied to both copies of the database.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Wow, kicked out before I've even said anything impolite.

Hey, just wanted you to concentrate on more important things Thanks for your reply.

>>The issue is with the job scheduling - at the moment we only allow an interval
granularity of one hour.  I can see about adding a minute interval, however.

Would be very nice, but not an absolute must-have, since I can do that myself...BTW, is it
possible to create/connect a session to the server in the same exe with an engine set to
etServer ? Or will I need a second exe with an etClient engine doing the timer stuff ?

>>DDL statements are a bit of an issue - they are not replicated and would need to be
applied to both copies of the database.

Will I have to unpublish the RAM DB before altering, and re-publish it after the
alteration is finished ?

Heiko

Heiko,

<< Would be very nice, but not an absolute must-have, since I can do that
myself...BTW, is it possible to create/connect a session to the server in
the same exe with an engine set to etServer ? Or will I need a second exe
with an etClient engine doing the timer stuff ? >>

With the use of remote stores, you don't need to have a remote session to
connect to the other EDB Server.  Just have one EDB Server do a periodic
SAVE UPDATES to a local store, and then copy the updates to a remote store
on the other EDB Server(s).   Then, on the other EDB Server(s), just
periodically execute a LOAD UPDATES using any of the available update files
in their local stores.  The hot backup is asynchronous, but there isn't any
chance of data loss as long as the update files exist in either the local
store of the main EDB Server, or in the local stores of the backup EDB
Server(s).  The logic for copying the update files from the main to the
backups should be:

1) Copy the update file to the backup servers.
2) If everything went okay (no exceptions), then delete the update file.

I'm going to try and do a technical article on this soon, because it's a
pretty neat thing to see in action and is very useful since spare machines
to serve as EDB Server backup machines are fairly easy to come up.  They
don't even need to be particularly fast since they can just load the updates
in their own time.

<< Will I have to unpublish the RAM DB before altering, and re-publish it
after the alteration is finished ? >>

No, no need for that.

--
Tim Young
Elevate Software
www.elevatesoft.com