Hi all,
I'm running a two-way replication system with EDB with great satisfaction.

I was wondering which is the best practice procedure to update EDB to a new version while replication is running with a strict interval, say 10 minutes. I think that having a short, simple stepped procedure could be of benefit to my peace of mind, even more when I upgrade this simple structure to a more complex star-shaped one.

The same procedure could also be useful when needing to apply DDL statements to both ends of a replicated system.

TIA

Alex

alexza


Upgrading means shutting down. You don't have an option so if there are no breaking changes, and no change in your use of the functionality it should be a matter of as and when you can shut each node down. Replication may move out of its strict 10 minute sync for a cycle for each node affected. Alternatively schedule a general shutdown & update followed by a restart. You'll probably still get the out of sync problem though.

SQL DLL will be similar depending on what access is needed to.

Roy Lambert

Alexza,

I run a few EDB replication-based systems. Updates and changes are complex to manage. There is no other way to put it.

Even if you are just talking about updating to a new version of EDB Server (no changes to the database structure). I would still recommend that you set up a test replication system mirroring the way your real-world system works, and do all the changes there first to ensure there are no complicated consequences. Once you have a stepped process you are happy with on your test system you can duplicate this on the real-world system.

It may be that this can be done cleanly and swiftly enough not to interrupt your work-flow.

As a minimum I would expect you would need to pause update-jobs that pass replication-data around your system.

Once any update includes real changes to your database structure, you have to be much more careful. I now always insist on a pause in operations during an update, allowing all users to be synchronized completely and logged off prior to making changes. I know this may not be possible for certain 24/7 applications, but I don't have to deal with that problem.

I have written a word document which I use to guide me through the process, as there are a lot of steps and I always miss one or two if I don't follow it. I am happy to share this document if you are interested, although it contains a lot of stuff which is only relevant to my own application.

Alex,

<< I was wondering which is the best practice procedure to update EDB to a new version while replication is running with a strict interval, say 10 minutes. I think that having a short, simple stepped procedure could be of benefit to my peace of mind, even more when I upgrade this simple structure to a more complex star-shaped one. >>

Are you just adding columns (or indexes, constraints, etc.), or are you possibly *dropping* columns and other types of objects ?  Adding objects is, obviously, easier than dealing with removing objects for the simple fact that removing objects can cause the loading of the updates to fail on the target system.

In general, you'll need to come up with a system whereby you keep track of any DDL SQL statements that are executed on the originating system, and then be sure to also put them in the same local store as where the update files are being retrieved from.  Then you can retrieve these SQL files *first* before any update files, and apply them before the updates.  Of course, you'll also need to make sure to execute a SAVE UPDATES statement *before* executing any DDL SQL statements to ensure that any pending updates are saved with the *existing* table structures before you begin altering them.

As others have pointed out, it can be tricky, but it's something that EDB needs you to manage.  EDB *could* manage this type of operation, but the chances of it succeeding on an operational system are slim due to other users using the same tables, etc.  In other words, it's a process that is better left up to the developer to manage in a way that fits their workflow and database availability.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks a lot Roy, Adam and Tim.

And Adam, yes, I'd be very interested in reading that doc, to use it as a trace in writing my own.

Thank you all for your time

Alex

Alex,

One more thing: ElevateDB only logs the row values for each update for columns that have been modified.  It also logs the column's data type, and will issue an error if the data type doesn't match on the target system when the target system tries to load the updates into its database table(s).

Tim Young
Elevate Software
www.elevatesoft.com