Reduce risk by implementing node switching best practices
It is critically important to conduct periodic failover planning and testing, and execute node switching as part of your DevOps practices. There's a lot of risk associated with not doing both, whether it comes in the form of lost revenue, clients or employee productivity. I've created this step-by-step guide to switching to help you adopt this best practice. In future videos I'll cover how you troubleshoot and resolve issues you may encounter in putting this practice in place. Let me know what specific questions or challenges you may face in the comments below, and I'll do my best to respond. Thanks!
------------------------------ Don Broadbridge Rocket Software ------------------------------
Page 1 / 1
It is critically important to conduct periodic failover planning and testing, and execute node switching as part of your DevOps practices. There's a lot of risk associated with not doing both, whether it comes in the form of lost revenue, clients or employee productivity. I've created this step-by-step guide to switching to help you adopt this best practice. In future videos I'll cover how you troubleshoot and resolve issues you may encounter in putting this practice in place. Let me know what specific questions or challenges you may face in the comments below, and I'll do my best to respond. Thanks!
------------------------------ Don Broadbridge Rocket Software ------------------------------
Hi Don,
thanks for sharing your knowedge! During your webinar, (Part 2, after the RSS presentation) after the first switchover, you did not start any groups, right?
So if i just want to test my switching routine and want to switch back after testing i simply do not start any groups, and i'm back on the right marks on production after the switchback? Right? In my understanding, this must lead at least to a "lot" of OOS objects after the switchback - if objects were modfied on the new production during swicthover -
So here comes the questions: 1. I can switch back and forth without starting the groups in between and let them resync. This is fine as long as no data is changed. 2. If i change data in between, i'm forced to resync the groups in between, or deal wih the resulting OSS objects.
Thanks in advance Stefan
------------------------------ Stefan Breuer VEDA GmbH ------------------------------
Hi Don,
thanks for sharing your knowedge! During your webinar, (Part 2, after the RSS presentation) after the first switchover, you did not start any groups, right?
So if i just want to test my switching routine and want to switch back after testing i simply do not start any groups, and i'm back on the right marks on production after the switchback? Right? In my understanding, this must lead at least to a "lot" of OOS objects after the switchback - if objects were modfied on the new production during swicthover -
So here comes the questions: 1. I can switch back and forth without starting the groups in between and let them resync. This is fine as long as no data is changed. 2. If i change data in between, i'm forced to resync the groups in between, or deal wih the resulting OSS objects.
Thanks in advance Stefan
------------------------------ Stefan Breuer VEDA GmbH ------------------------------
Hi Stefan,
From my experience, customers usually switch for a weekend (for example, to do PTF updates, O/S upgrades etc.) or switch and stay, e.g. every 6 - 12 months run a regular switch, start up applications and replication then get all users over.
Point 1 – correct, as long as nothing has changed
Point 2 – correct again, you would run SCs to see if and where there were differences and activate/fix accordingly (as we say, Sync Check is our friend!)
Many thanks and stay safe!
------------------------------ d broadbridge Rocket Software ------------------------------
Hi Stefan,
From my experience, customers usually switch for a weekend (for example, to do PTF updates, O/S upgrades etc.) or switch and stay, e.g. every 6 - 12 months run a regular switch, start up applications and replication then get all users over.
Point 1 – correct, as long as nothing has changed
Point 2 – correct again, you would run SCs to see if and where there were differences and activate/fix accordingly (as we say, Sync Check is our friend!)
Many thanks and stay safe!
------------------------------ d broadbridge Rocket Software ------------------------------
Hi Don,
thanks for the quick response!
Stefan
------------------------------ Stefan Breuer VEDA GmbH ------------------------------
