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.
About this task
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:
Procedure
- 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.