Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
4 replies
Subscribers
6 subscribers
Views
2239 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
Administration
Replicating to DR from PRD
andrewl657
over 8 years ago
We have a distributed environment set up for our Production instance. F5 load balanced to 2 web servers, 2 app servers (active-passive), & clustered db. Our DR, on the other hand, is F5 to 1 web server, 1 app server, & 1 db server. Looking through the documentation on backup/replication, it mentions that it is necessary to have the exact same setup/configurations between DR and PRD.
We are not able to do that because our domain name and url for the DR will be different so we are not able to replicate the whole <APPIAN_HOME> directory. We have all engines & app data on a SAN that we plan to backup and replicate to our DR including RDBMS. Does anyone see any problems with this since the application setup will be different? Also I will be running the checkpointing script before every backup. Should we only be replicating the top 2 highest kdb files over to DR along with all app data and RDBMS?
Th...
OriginalPostID-244571
Discussion posts and replies are publicly visible
Parents
0
Mike Cichy
Appian Employee
over 8 years ago
Checkpointing does prevent writes to kdbs so I would pick times of low usage to do the checkpoint. I am not sure what your data load projections are, but the size of the kdbs can become a concern but likely can be deferred for a while.
The proposed approach seems sound. You do have an option of replicating "live" kdb files but that will increase your RTO, since the transaction log would have to be replayed on DR site startup and I would not get into it unless your checkpointing times are really long.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
Mike Cichy
Appian Employee
over 8 years ago
Checkpointing does prevent writes to kdbs so I would pick times of low usage to do the checkpoint. I am not sure what your data load projections are, but the size of the kdbs can become a concern but likely can be deferred for a while.
The proposed approach seems sound. You do have an option of replicating "live" kdb files but that will increase your RTO, since the transaction log would have to be replayed on DR site startup and I would not get into it unless your checkpointing times are really long.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data