Question Replication Db (using Oem)

We are currently using v9.1E (Sun Machine) and migrating to v11.6 (Linux). As part of our current approach we are using hot-swap (i.e., every 15 mins cron job will apply the AI to the backup db). We are in a dilemma if we should stick with the same approach or use OE Replication and get the replication setup to mimic the approach.

If in case we can leverage the use of OE Replication, let's consider we have production DB sitting on one server and replication sitting on another and how does the hand sake work in case of failure with our primary DB? Should we go with config files that would point to replication db in case of failure? Or what is the commonly used practice (how should the setup look like)? Please advise.

How would the use license work? say we have around 400 users using the production box and when a failure happens and re-point to replication db that sits on another server can we use the same user license?
 
Last edited:

Rob Fitzpatrick

ProgressTalk.com Sponsor
We are in a dilemma if we should stick with the same approach or use OE Replication and get the replication setup to mimic the approach.
That should be a business decision, based on RPO and RTO. If RPO is on the order of several minutes or more then you can accomplish that with AI log-shipping. If you need it to be lower then go with Replication Plus. Note that there are two different add-on products, Replication and Replication Plus. The latter allows you to connect read-only clients to a target database, e.g. to do reporting. Given the small difference in price it is my preference.

how does the hand sake work in case of failure with our primary DB? Should we go with config files that would point to replication db in case of failure? Or what is the commonly used practice (how should the setup look like)?
A process called the replication server connects to the source database, and a process called the replication agent connects to each target; you can have one or two targets. The server establishes a TCP connection to the agent and streams AI notes to it to keep it synchronized. If the agent loses connection to the server it goes into a pre-transition state. You can configure an agent to automatically fail over but I wouldn't recommend that. I think failover should be a manual process that someone does deliberately. I would say best practice is to use asynchronous mode for Replication and to do failover manually.

say we have around 400 users using the production box and when a failure happens and re-point to replication db that sits on another server can we use the same user license?
You can't re-use a production license for DR. If you buy a Replication product it include the DR license for the RDBMS; you would still need to buy DR licenses for the other products you use, e.g. App Server, Client Networking, compiler, etc.

If you're just doing AI log-shipping, you still need to buy DR licenses. DR licenses cost 50% of production licenses.
 
You can't re-use a production license for DR.
If this is the case with 400 user licenses this approach will double up the cost, right?

I understand this approach provides us with the real time replication and we can generate reports which will be helpful; but if the cost is going to be doubled we will need to rethink (i mean management's call). We don't use App Servers.
 
I would like to take a moment and thank you. You replies to all my threads (not just this one) are very detailed and easy to understand. If you get to write a book on Progress DB, I will be the first one to purchase. Thanks again @Rob Fitzpatrick!
 
Top