Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 4 of 4 total |
Replication, RAMDisk and Altering |
Thu, Mar 19 2009 5:08 PM | Permanent Link |
Heiko Knuettel | 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 |
Fri, Mar 20 2009 2:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Sat, Mar 28 2009 7:11 AM | Permanent Link |
Heiko Knuettel | 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 |
Mon, Mar 30 2009 4:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |