This command changes the role of the local peer from master to slave or from slave to master when the coupling is non-operational. It is assumed that the command will be issued on both peers of the coupling before the coupling becomes operational again, so that upon reconnection there will still be one master and one slave.

When the command is applied to the master:

• The command can be issued only if the activation state is Standby.
• The command can't be issued during the Initialization phase.

Changing the roles in synchronous mirroring:

• When applied on the master:
  • All changes made to the master since the last time the peers were synchronized will be reverted to their original value. The master ceases serving host requests, and is set to accept replication from the other peer as a slave. If the command was issued during link unavailability, a most_updated snapshot of the peer will be taken to capture the most recent changed that haven't yet been replicated to the other peer.
  • A warning is displayed: ″Are you sure to change master to slave″
  • An event is generated
  • The Master will cease accepting host requests
  • Unsynchronized data at the demoted Master is recorded in most updated snapshot
  • The demoted Master reverts to last_replicated snapshot
  • Completion of process is recorded in log o Mirroring state is standby
• When applied on the slave:
  • The slave will become a master, start accepting requests from hosts, and upon explicit activation will start replicating to the other peer (the original master).
  • If the slave volume has a last_consistent snapshot, it means that the mirroring was broken in the middle of the synchronization process and the slave could be inconsistent.
    • In this case, the administrator must choose whether to use the most_updated version, which might be inconsistent, or the last_consistent snapshot.
    • Reverting the volume to the last_consistent snapshot can only be performed by deleting the mirroring, reverting the volume and creating a new mirroring definition.
    • Either way, if a last_consistent snapshot exists, a most-updated snapshot is created, keeping a copy of the information at the time of the role change.

Changing the roles in asynchronous mirroring:

• When applied on the master:
  • Upon successful issuance of the command on the master, the master will be reverted to the image recorded on the last_replicated snapshot of the mirror, will cease accepting host requests, and will be set to accept replication from the other peer as a slave.
• When applied on the slave:
  • A warning is presented: ″Are you sure to change slave to master″
  • An event is generated
  • The new Master will cease accepting replication requests from the previous Master, and will revert to the last_replicated snapshot
  • The new Master starts accepting host requests
  • The new Master establishes asynchronous interval-based Sync Job process, based on schedule
  • Completion of process is recorded in log
  • Mirroring state is standby
  • Explicit activation of mirroring is required

Requirements for a successful command completion:

• The command can't be issued on the master during the Initialization phase
• The command can't be issued in Change Tracking state
• The activation state is Standby
• The command can be applied on a volume only if the volume is not part of a mirrored CG; if the CG is mirrored - the command will return an error and fail
• The command can be issued on the Slave, not during initialization