I am just thinking of a particular scenario, where the primary is unavailable and user request gets directed to secondary site and performs password check out and after 5 minutes he check's-in. Assuming that the Password View Policy is set to change the password immediately after every check-in and secondary site being only read only,it is the primary which can push password changes.
1. How will the password change be handled in this scenario?
2. What happens when Primary Site is back online? How will the Check-out/Check-in information propagation take place between secondary and primary or even there will be any propagation?
4. Will the password change once Primary is back?
3. What would be the status of the secondary site while the primary site goes down? Operationally safe mode?
Questions are asked based on assumptions that we have not yet promoted a secondary into primary.
Many thanks for your reply. I have one more question.
Say I am running the Secondary in Operational Safe Mode and Primary went down and somebody did a Password view between the time frame while I was promoting one of the secondary to primary. Since the Password View Policy is set to Change Password on View, there's no write operation performed in this case and according to you there will be no change.
Now when the Primary comes online(be it the actual one or Promoting one Secondary to Primary):
1. Will there be any inconsistency(Considering the Odds)?
2. Will the password remain same as it was before the checkout? / If the user does a checkout again after sometime will he get the same password?
Hi Avijit, I don't understand your use case. A node will not change a password if it's not a primary site node. So until a node is restarted in a primary site role, there will be no password change and no chance of an inconsistency. Any node that completes a password update task has to be active in the primary site, implying that the cluster is up and running at the time, and the change will be promoted to all other primary site nodes right away, and to secondary site nodes on their next pull. The only inconsistency would come from password changes that were completed in the original primary site, but then the site went down before the changes were pulled by the secondary site that is being promoted to be new primary. This is a 10 second window at worst, the default poll interval for secondary site nodes.
Hi Prigl, you answered all my queries. The use case might be little stumbled but I have my answers.
I appreciate your time and response.