UCM - How to setup synchronize between DR and Primary site

Question

Hi all.
As mentioned on title, we have a primary UCM site and a clean DR site. I want to ensure that end-users have ability to work with DR site for a short time when the Primary site is unavailable. To make DR site available to serves when the primary is down, we can do:
- setup auto-export archive on primary site
- target to destination archive on DR site
- auto-transfer from primary to DR site
- with data in Database, we can use Golden Gate to sync Primary and DR site
So, with these settings, I can ensure that the DR is ready to run when the Primary is down. But, if the primary takes a long time to recovered, the DR site has many new contents. How to transfer it back to primary site when the primary is came back ? In other words, how to synchronize contents (vault and native files) between new Primary (old DR) and new DR (old Primary) site ?
Thank for your attention.
Sorry for my bad English.
Cuong Pham

Answer 1

Hi Cuong (and guys),
I'm afraid the issue is not that simple. In fact, I think that the Archiver could be used for DR only by customers who have little data and few changes. Why do I think so?
a) (Understanding System Migration and Archiving - 11g Release 1 (11.1.1)) "Archiver: A Java applet for transferring and reorganizing Content Server files and information." This means that you will use a Java applet to Export and Import your data. With a lot of items (you will need to transfer all the new and updated items!), or large items it will take time (your DR site will always be "few minutes late"). Besides, the Archiver transfers are based on batches - I don't think you can do continuous archiving - and will have impacts on the performance.
b) Furthermore, (Exporting Data in Archives - 11g Release 1 (11.1.1)) "You can export revisions that are in the following status: RELEASED, DONE, EXPIRED, and GENWWW. You cannot export revisions that are in an active workflow (REVIEW, EDIT, or PENDING status) or that are DELETED." This means that the Archiver cannot be used for all your items.
Therefore, together with FMW DR Guide (Recommendations for Fusion Middleware Components) I think other techniques should be considered:
- Real Application Clusters (RAC), Weblogic Clustering, cluster-ware file system: the first, almost error-free, and relatively cheap option is having your DR site as other nodes in DB and MW clusters. If any of your node goes down, the other(s) will still serve your customers (no extra work needed), plus, you can benefit from "united power" of multiple nodes. RAC is available also in Oracle DB Standard Edition (for max. 2-nodes db cluster). The only disadvantage of this configuration is that it is not available for geo-clustering (distance between RAC nodes must be max. some hundreds meters), so it does not cover DR scenarios like "location goes down" (e.g. due to networking issues)
- Data Guard and distributed file system: the option mentioned in the guide is actually this one. It is based on Data Guard, a free option of the Oracle Database Enterprise Edition, which can run in both asynchronous (a committed transaction on the primary site is immediately transferred to the DR site) and synchronous (a transaction is not committed on the primary until processed by the DR site - if sites are far, or a lot of data is being sent, this can take quite long) modes. So, if you store your content in the database the Data Guard can resolve a lot. Unfortunately, not everything - the guide also mentions that some artifacts (that change!) are also stored on the file system (again, workflow updates, etc), so you have to use file system sync techniques to send those updates. In theory, you could use file system to send also updates in the database, which is nothing but a file(s) (in this case you will need the Partitioning option to split your database into smaller files), but db guys hate this way since it transfers also inconsistencies, so you could end up with an inconsistent database in the DR site, too.
This option will require some administrative tasks - you will have to resolve inconsistencies resulting from DG/file system sync, you will need to redirect your users to the DR site, and re-configure the DG to make primary site from your DR one. Note that once your original primary site is up again, you can use DG to transfer (again, immediately) changes done in the meantime.
As you can see, there is no absolute solution, so you need to evaluate your options, esp. with regards to your needs.
Jiri