Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 5 of 5 total |
Another Replication question |
Mon, Feb 13 2012 11:23 AM | Permanent Link |
Adam Brett Orixa Systems | Sorry to be a bore on replication ...
How would EDB cope with the following scenerio: I have 1 central database and many local "laptop" users. These users connect from time to time to load & save updates. This is all done with Unique keys & works. The central server might SAVE UPDATES hourly. A new user arrives. This user needs a "starting copy" of the database. I call "BACKUP DATABASE .... INCLUDE CATALOG" Install this backup on the new users computer. At the same time I create an "IN" and "OUT" store for this user to use for the "load" and "save" processes. -- Do I need to call "BACKUP DATABASE" hourly at the exact same time as the SAVE UPDATES in order to ensure I have a version of the DB which exactly matches? If I only call BACKUP DATABASE when the new user arrives, some update files might include updates which are already present. Could this cause a conflict? |
Fri, Feb 17 2012 12:54 AM | Permanent Link |
David Cornelius Cornelius Concepts | The new user should only get updates created after the database was backed
up. In my case, I had a unique store for each customer that connected to the server. That store was created when the user was created and the first thing that happened was the database was backed up and put in that store. All such stores had a unique name and the hourly script looked through all store names with that unique pattern to copy the updates. So a user never got any updates created before their database was created. You could also check the date-stamp of the "updates" files. David Cornelius Cornelius Concepts |
Tue, Feb 21 2012 7:33 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< Sorry to be a bore on replication ... >> Not at all - sorry I'm only popping in here occasionally. Hopefully this situation won't be much longer. << How would EDB cope with the following scenerio: I have 1 central database and many local "laptop" users. These users connect from time to time to load & save updates. This is all done with Unique keys & works. The central server might SAVE UPDATES hourly. A new user arrives. This user needs a "starting copy" of the database. I call "BACKUP DATABASE .... INCLUDE CATALOG" Install this backup on the new users computer. At the same time I create an "IN" and "OUT" store for this user to use for the "load" and "save" processes. Do I need to call "BACKUP DATABASE" hourly at the exact same time as the SAVE UPDATES in order to ensure I have a version of the DB which exactly matches? >> Yes, since you're mixing a complete backup with what amounts to incremental backups, you'll need to ensure that the timing of the two operations is done in a time-consistent way. The key here is to make sure that you do the SAVE UPDATES, then the BACKUP DATABASE. This will ensure that you've got a clean cut-off point that is consistent between the update files and the backup files. Please note that there's still the possibility, albeit remote, that an insert, update, or delete sneaks in to the database in-between the SAVE UPDATES and the BACKUP DATABASE execution. It really depends upon whether the database is actively being used at the time. This is why it's usually best to do the BACKUP DATABASE in off-hours, and then just keep all update files created since that point in the same store where the backup file is created. Then, any time a new user comes on board, just copy over the backup file and all of the subsequent update files to get the user started. After that, they can simply be included in the normal stream of update files. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Feb 24 2012 6:23 AM | Permanent Link |
AdamBrett Fullwell Mill | OK: Simple schema for creating new remote users in a "cloud-style" DB:
1. Backup Database, periodically (say daily in off hours) 2. <<General work of the database continues, with uploading and downloading of updates between server and all users>> 3. Save updates regularly the Backup Database store with the periodic backup file from step 1. Files from the Backup Database store should enable the creation of a new remote user, who can then join in the process going on in step 2. Each time we do step 1. we should delete all the files from step 3. and start again. -- I only have a dozen or so users at this stage, but I do need to be able to add new ones periodically without too much difficulty. If the schema works I will definitely be rolling it out to all my users, as it is faster, more responsive and doesn't require continuous connection to the db. ... does the above look OK? |
Mon, Feb 27 2012 4:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< .. does the above look OK? >> Almost. The only catch is that while the sequence works fine for new users, you'll still need a way to keep existing users from trying to download the same update files over and over again if you intend to keep all of the updates files in the same store as the snapshot backup file. There are a couple of ways of doing this, but the easiest way is to simply keep track of the timestamp (in a system table, etc.) from the last update file loaded at each remote location, and then simply have the remote location only copy/load the update files whose timestamp is greater than that timestamp. The other way is to use a "distribution" mechanism whereby each remote location has its own store on the main EDB Server for downloading updates, and each update file saved in the same store as the snapshot backup file is then also copied to each of the remote location stores. This second method is what is used in the sales quotation example of the replication technical article. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Tuesday, May 7, 2024 at 02:40 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |