Basic rundown:
If all RSA servers are operational and replicating normally
and
If all RSA agent can reach any RSA server on the network at all times
Then: the sdconf.rec tells an agent where the primary and replicas are located, and when the agent needs to do an auth, it will contact one or the other RSA server and do that auth. Then it records how fast that RSA server responded. Next time it needs to do an auth, it will randomly choose an RSA server, and record the time. Over time, the agent will begin to prefer a faster responding RSA sevrer, but will still try them all on occasion. If one does not respond, it just goes and tries another one in the list, until all RSA servers do not respond, then it will fail.
So, dropping a replica should not cause a web agent to fail completely, maybe one auth might fail, but if things are set up correctly, it will just try the primary and do auths. You do not need new sdconf.rec, the agent might try the stale replica once in a while, but it will prefer to try the primary most of the time. When it tries the missing replica once in a while it will wait for a few ms for an answer, then just go try the primary, and the user will get authenticated. But none of this should be an authentication outage.
So, in this state, you can do network checks or look in auth activity logs to see if that web agent ever did an authentication to the primary, or was it only able to authenticate to the replica for some reason...in other words something not quite right with the 'can reach any RSA server at all times' idea.
But if you want to straighten it all out: yes, replace sdconf.rec with a current one that has the current RSA servers in it, and find and delete any file named sdstatus.* on the agent. The sdstatus file, is the file which does the load balancing and knows which RSA server responds faster or slower, so when you have issues like this, deleting the sdstatus cleans up any knowledge of 'stale rsa servers' and forces the agent to look at the sdconf.rec again, and when it contacts the primary, the primary will tell the agent 'this is my current list of replicas'.
Summary: Normally you can add and delete replicas, and the agents figure it out automatically, nothing needs to be done on the agent side..... But when problems occur, you can deploy new sdconf.rec and delete sdstatus.* files to force the agent to only use newest information.
