Replication Questions

RaphaelFrei

New Member
Hi!

My company started implementing OE Replication for the first time, so for our first attempt, we got a small database and started working from there to, in the next couple months, go with more databases.

The Replication process is working normally, we are not using Transition.

My issues was:

One of the local IT needed to update the replication server Windows - Did the shutdown of the server (without stopping the database) and after updating and rebooting, did not started the database with the correct replication flag (There is a script where the user select if it's replserver or agent - With a work instruction explaining how to properly shutdown databases and server in case of OS Update).

After a couple of minutes, we started receiving some emails regarding the agent not being updated with production database and I started digging some information.

For our luck, the production was not working that day so we could dig a little further into the issue - Again, our first time on a Replication environment.

Since both databases where running and the IT told us about what he did in the update process, my team first action was to stop both databases and recreate all the replication environment.

But, after trying to make the PROD backup with the REPLTargetCreation, I got into this error:

1758797216113.png
Translation:
Changing to a new ai extent failed. (3669).
!!! ERROR - Backup utilitary failed (8563)

So, I runned the command:
rfutil [db] -C aimage list

And noticed that all AI files where locked, except for the last one that had the BUSY flag.

So I followed this guide and manage to re-enable the migration without re-creating it.
(All After Image extents are LOCKED by OpenEdge Replication and can't continue processing)

Basically, started target with correct flag, started prod with correct flag and replication process resumed and loaded all the previous extents.

The question:

1. If the production environment was running normally would the database crash after all the extents being used - Or just soft-lock from creating/updating any record?
2. Or if doesn't stop the source from running, I believe the replication process would break - Because in this case will be some data that it could not process, for this, executing this command dsrutil <sourcedb> -C restart server and rfutil <sourcedb> -C aimage empty while redoing the backup would "fix" the replication process work?
 
If the production environment was running normally would the database crash after all the extents being used - Or just soft-lock from creating/updating any record?
If you have no empty AI extents (current extents are busy and others are full or locked), the database will continue writing to the busy extent as long as it can. If it is a variable-length extent, it will continue to grow. If it is a fixed-length extent, it will write until the extent fills. At that point the database will shut down or stall, depending on how you have configured the database.

If you are using the AI File Management Daemon (AIMD), it archives and empties the extents once their notes are synchronized with the target (or targets). So if the replserv loses connection with the replagent, you can restart the target database, restart the replserv if necessary, and the databases should synchronize and the AIMD will empty the AI locked extents.
 
If you have no empty AI extents (current extents are busy and others are full or locked), the database will continue writing to the busy extent as long as it can. If it is a variable-length extent, it will continue to grow. If it is a fixed-length extent, it will write until the extent fills. At that point the database will shut down or stall, depending on how you have configured the database.

If you are using the AI File Management Daemon (AIMD), it archives and empties the extents once their notes are synchronized with the target (or targets). So if the replserv loses connection with the replagent, you can restart the target database, restart the replserv if necessary, and the databases should synchronize and the AIMD will empty the AI locked extents.
Thanks Rob!

We’re not using AIMD…

I was running some tests here, to see things working and I got into another question.

I saw it was possible to disable replication (disablesitereplication source/target) while the databases are running.

This means, in case of an disaster where we can’t get the target back to working before filling the AI, can we just disable the replication and it will get back into the older AI files? We’re managing by time and size on each extent. Are there any risk by doing so? We want to minimize source downtime in case of an issue on target.

(Never happened, but it’s a contingency plan)
 
Back
Top