What is and how to avoid data contention coming with RTC HA?
I finally get RTC High Availability work on our production servers and one thing that has botherer me is the data contention mentioned by the RTC help:
To restore the Primary Server to its operational status, the timing of the server startup and the switching of the LoadBalanceWeight attributes is important to avoid any data contention with the Primary and Backup Server talking to the repository at the same time. The solution given to the scenario is to properly shut down the primary and standby servers and start them in proper order. But what to do with the following scenarios: 1. while server A is set as the primary server, whle most users use the new connection url pointing to the new IBM HTTP server, which will rout their request to the server A, there are also users using direct url pointing to the standby server B. This will cause data contention as the Primary A and Standby Server B is talking to the repository at the same time? 2. While the standby server B is set as primary from a failover, and server A is also up as temporary standby server undergoing maintenance, most connection request will be routed to the standby server B, but there are users using direct url pointing to server A. This will cause data contention as the Primary A and standby Server B is talking to the repository at the same time? How bad the data contention can be and what is the consequence? How to recover from it when data contension happens? How do I avoid the data contension? Probably need to raise a PMR for it but want to see if anyone has something to share? |
2 answers
I finally get RTC High Availability work on our production servers and one thing that has botherer me is the data contention mentioned by the RTC help: To restore the Primary Server to its operational status, the timing of the server startup and the switching of the LoadBalanceWeight attributes is important to avoid any data contention with the Primary and Backup Server talking to the repository at the same time. The solution given to the scenario is to properly shut down the primary and standby servers and start them in proper order. But what to do with the following scenarios: 1. while server A is set as the primary server, whle most users use the new connection url pointing to the new IBM HTTP server, which will rout their request to the server A, there are also users using direct url pointing to the standby server B. This will cause data contention as the Primary A and Standby Server B is talking to the repository at the same time? 2. While the standby server B is set as primary from a failover, and server A is also up as temporary standby server undergoing maintenance, most connection request will be routed to the standby server B, but there are users using direct url pointing to server A. This will cause data contention as the Primary A and standby Server B is talking to the repository at the same time? How bad the data contention can be and what is the consequence? How to recover from it when data contension happens? How do I avoid the data contension? Probably need to raise a PMR for it but want to see if anyone has something to share? Perhaps I have misunderstood the HA setup you are describing - but I think your URL's are using the HTTP proxy server - and so the repository does not contain references to server A or server B but only to the machine referenced by the proxy server. regards anthony |
|
Anthony,
You are right we use a front end HTTP sever for end user as https://webserver/jazz. And we have two RTC servers configured to use the same Public URL Root: https://primaryserver/jazz and point to the same DB2 database. My question is that while mostusers are using https://webserver/jazz and get routed to https://primaryserver/jazz, what if ther are a few users using https://standbyserver/jazz and run RTC jobs at the same time? |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.