Recovering an SD cluster after the secondary server became the primary server

If a secondary server in an SD cluster became the primary server after the original primary server failed, you can use a script to reestablish the original primary and convert the current primary server back to a secondary server.

In this example, the primary server, named srv_pri, has failed over to an SD secondary server named srv_sds_sec. At this point, the primary server is srv_sds_sec, and any other secondary servers in the cluster are now pointing to srv_sds_sec. To restore the cluster to the way it was before srv_pri failed over, follow these steps:

If necessary, set the following parameters in the onconfig file of srv_pri:
```
SDS_ENABLE 1
SDS_PAGING <path 1>,<path 2>
SDS_TEMPDBS <dbsname>,<dbspath>,<pagesize>,<offset>,<size> 
```
The dbsname value must be unique. In addition, the dbsname must be unique among all existing dbspaces, blobspaces, and sbspaces, including those (possibly disabled) temporary spaces that are inherited from a primary server. If you have multiple SD secondary servers, the dbsname value must be unique for each server and not shared with any other SD secondary server or the primary server. See Setting up a shared disk secondary server for more information about setting these parameters.
Initialize srv_pri as an SD secondary server by running the oninit command on srv_pri.
Perform a manual failover of srv_pri to make it the primary server:
```
onmode –d make primary srv_pri
```
The previous command removes srv_sds_sec from the cluster and makes srv_pri the primary server.
Restore srv_sds_sec as an SD secondary server by running the oninit command on srv_sds_sec.