Answered Establish Fathom site replication using incremental backups

[pinne65]

We are in the process of establishing Fathom site replication between two remote sites.

The way this has been done in the past is to create one full offline Progress backup and one incremental backup of the source database. And while the source database is down transport the backups to the target server and restore the backups there. Then configure replication and start both databases in the right order. I don't have all the details since this is all done by our application provider.

The problem we are facing is the time it takes to backup and restore. We are using a USB 2 drive to transport the data. So it takes 10-12 hours. (NO - we don't have anything else at the moment)

My question is: Could we create a full offline backup of the database, start it up again, use it in production, (meanwhile we would transfer the full backup to the target site and restore.). And then, when the longer maintenance window arrives, shut the databases down again, make a final incremental backup, apply it, and establish the Fathom / site replication?

Another question, can you mix incremental offline and online backups?
(I was hoping we could make daily incrementals after the initial full backup. So that when crunch time comes, we would only have a small final incremental to apply).

We already have the databases replicating by means of copying/applying AI files every 15 minutes, doing weekly full online backups and daily incrementals.

RHEL 5.4 / Progress 10.2B03

TIA!

/Pinne

 

[Bren]

Hello,

Have you (or your application provider) considered using deferred agent startup? It will allow you to start up and use your source production databases, even before you start the target ones and establish synchronization. Using deferred agent startup, the startup and synchronization of the target databases and their respective replication agents can be deferred by up to 24 hours, which sounds like it would be sufficient for your requirements.

With defer-agent-startup, at a high level, you can accomplish something like this:

1. Enable AI, Replication on the source databases
2. Start the source databases
3. Create (full) online backups of the source databases
4. Transfer these full backups to your target server (this is the part that takes 10 ~ 12 hours, right? and in the meantime, production is already up and running)
5. Restore the backups on the target server, enable target replication
6. Start the target databases
7. Synchronization is established between source and target

(And--I feel it's important to mention this, since you have a relatively large window of ~12 hours between Step 3 and Step 7--make sure you DON'T make any backups of the source databases in between Step 3 and Step 7 above.... I learned the hard way, synchronization will fail with errors (11703 if you were wondering) )

The section "Using the deferred agent startup implementation" that starts on page 3-4 of the OpenEdge Replication: User Guide would be a good starting point.

Sorry this doesn't directly answer your questions, but I've used the deferred agent startup method for OE Replication and it sounds like it fits your bill (and without all the hassle of additional incremental backups and offline maintenance windows!)


-Bren

 

[Rob Fitzpatrick]

It would be a good idea to check the 10.2B release notes, as you're on SP03 and there have been a lot of Replication-related fixes in later 10.2B SPs. If you're going to remain on 10.2B you should be fully patched.

communities.progress.com/pcom/docs/DOC-16074

 

[pinne65]

Thanks a bunch for the info! I think this could solve our problem.

Unless I'm missing something it seems like you can defer startup for 7 days (10080 minutes) which was something I hoped for. 24 hours would've made it. But longer is more convenient. I just need to figure out all the implications of deferring it longer.

 

[Bren]

Good catch! Yes, you can set it to 10080 minutes (7 days)

Apparently there is a discrepancy between the documentation and the sample source.repl.properties, for reference, this article clarifies:
knowledgebase.progress.com/articles/Article/P117455/p


I did a couple of quick tests and confirmed this too:

My source repl.properties file specifies:

defer-agent-startup=1440  #default 0; 1440 mins = 1 day

I started the source database at Thursday April 18 13:28.

The following messages are logged to the source database log on startup:

[2013/04/18@13:28:34.3819052690168611756-0400] P-11006      T--1793341696 I RPLS    5: (11717) Defer Agent Startup (defer-agent-startup): 1440.
.
.
[2013/04/18@13:29:39.987-0400] P-11006      T--1793341696 I RPLS    5: (10397) The connection attempt to the Fathom Replication Agent agent1 failed.
[2013/04/18@13:29:39.987-0400] P-11006      T--1793341696 I RPLS    5: (11241) The Replication Server will continue to attempt Agent connections until Fri Apr 19 13:28:35 2013

I changed it to specify 10080, and I get the following instead in the log:

[2013/04/18@13:49:07.3819052690168610890-0400] P-11082      T--67655936 I RPLS    5: (11717) Defer Agent Startup (defer-agent-startup): 10080.
.
.
[2013/04/18@13:50:12.087-0400] P-11082      T--67655936 I RPLS    5: (10397) The connection attempt to the Fathom Replication Agent agent1 failed.
[2013/04/18@13:50:12.087-0400] P-11082      T--67655936 I RPLS    5: (11241) The Replication Server will continue to attempt Agent connections until Thu Apr 25 13:49:08 2013.

 

[pinne65]

Thanks for testing!
(I've been out on vacation for a couple of days)
I hope we can try this once our infrastructure settles down. (We are in the middle of a major overhaul right now).