Dell DX6004S DX Cluster Services Node Installation and Configuration Guide - Page 22

Failover Without DX Storage, the Secondary. In this scenario

Page 22 highlights

a backup set from the restored manifest list. The primary's backup manifest must have at least 2 backups in it prior to being used for failover. To assist with this transition, the secondary CSN periodically pulls the primary's Backup Manifest UUID via the privileged SSH channel and stores it in the following location on the secondary: /etc/caringo/csn/primary-manifest.txt. A timestamp on this file will notate the last time it was updated. To restore a manifest, click the 'Change Manifest' button at the top of the backup interface. This will bring up a entry box where the UUID you would like to restore can be entered. The entered UUID must be for a valid backup manifest created by the backup utility. If restoring a manifest on a machine that has an existing manifest and associated backups, admins must be aware that the backup list will be completely overwritten when the entered manifest is restored. Administrators should be aware that the secondary will effectively take on the identify of the primary when the manifest and a selected backup within it are restored. Note Demotion of a Secondary CSN's backup set onto a Primary CSN is not supported. Failover should only be done when the Primary is not expected to return to service soon enough for the environment's needs. A complete software rebuild of the original Primary to reconfigure it as a Secondary will be necessary before returning it to service after a Secondary has taken over its role. 3.5.5.1. Failover Without DX Storage If the failure or demotion of the Primary CSN coincides with an outage of the DX Storage cluster, you will be unable to pull the Primary's Backup Manifest UUID from the cluster to restore it onto the Secondary. In this scenario, an administrator can manually restore the Primary CSN's last recorded backup set, which is updated hourly on the Secondary CSN if it has changed. The following command will restore the Primary's backup set onto the Secondary, effectively making the Secondary assume the role of the Primary CSN. The script should only be performed from the Secondary CSN with both the Primary CSN and the DX Storage cluster offline: /opt/caringo/csn/bin/failover_without_castor The script will restart the Secondary CSN after the Primary's configuration has been restored. Copyright © 2010 Caringo, Inc. All rights reserved 19 Version 2.0 December 2010

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35

Copyright © 2010 Caringo, Inc.
All rights reserved
19
Version 2.0
December 2010
a backup set from the restored manifest list. The primary's backup manifest must have at least
2 backups in it prior to being used for failover. To assist with this transition, the secondary CSN
periodically pulls the primary's Backup Manifest UUID via the privileged SSH channel and stores
it in the following location on the secondary:
/etc/caringo/csn/primary-manifest.txt
. A
timestamp on this file will notate the last time it was updated.
To restore a manifest, click the 'Change Manifest' button at the top of the backup interface. This
will bring up a entry box where the UUID you would like to restore can be entered. The entered
UUID must be for a valid backup manifest created by the backup utility. If restoring a manifest on
a machine that has an existing manifest and associated backups, admins must be aware that the
backup list will be completely overwritten when the entered manifest is restored.
Administrators should be aware that the secondary will effectively take on the identify of the primary
when the manifest and a selected backup within it are restored.
Note
Demotion of a Secondary CSN's backup set onto a Primary CSN is not supported.
Failover should only be done when the Primary is not expected to return to service soon
enough for the environment's needs. A complete software rebuild of the original Primary
to reconfigure it as a Secondary will be necessary before returning it to service after a
Secondary has taken over its role.
3.5.5.1. Failover Without DX Storage
If the failure or demotion of the Primary CSN coincides with an outage of the DX Storage cluster,
you will be unable to pull the Primary's Backup Manifest UUID from the cluster to restore it onto
the Secondary. In this scenario, an administrator can manually restore the Primary CSN's last
recorded backup set, which is updated hourly on the Secondary CSN if it has changed. The
following command will restore the Primary's backup set onto the Secondary, effectively making
the Secondary assume the role of the Primary CSN. The script should only be performed from the
Secondary CSN with both the Primary CSN and the DX Storage cluster offline:
/opt/caringo/csn/bin/failover_without_castor
The script will restart the Secondary CSN after the Primary's configuration has been restored.