Performing Disaster Recovery with an Active Shadow LSMS

In this configuration, an entire LSMS is active and has active associations with each NPAC from which the LSMS needs data. This disaster recovery backup strategy provides the least out-of-service time for the LSMS.

In addition to the assumptions listed in “Preparing for a Disaster Situation”, the following conditions are assumed:

Both the main LSMS and shadow LSMS are associated with each NPAC (up to eight) from which the LSMS needs data, and both the main LSMS and the shadow LSMS are receiving automatic updates. Each regional NPAC database at both LSMS sites is synchronized with the NPACs.
A network connection from each serviced network element to the shadow LSMS exists, but the network element is not associated with the shadow LSMS at the time the main LSMS fails.
Users, groups, and passwords are identically configured at the main LSMS and shadow LSMS.
Any data locally provisioned at the main LSMS is also locally provisioned at the shadow LSMS.

Perform the procedures shown in Table 7-2 on the shadow LSMS when a disaster occurs on the main LSMS.

Recovery Procedures When LSMS Shadow Is Active
Active	In the order shown, perform the following recovery procedures:
1	(Optional) Recovery acceptance test on active server of shadow LSMS: Verifying the State of the Servers Verifying the Processes Running on the Active Server (with primary server as active server) Verifying the GUI Operability on the Active Server (with primary server as active server) Note: Do not switch over to the shadow LSMS’s standby server until all EMSs have been resynchronized because all queued subscription data would be immediately flushed.
2	Add any locally provisioned data that may have been added to the main LSMS before it failed and has not yet been added to the active shadow.
3	Perform the procedures in “Reconnecting Network Elements” (start with 4 and use the main LSMS as the source and the shadow LSMS as the destination).
4	For each network element, perform a time-range audit (specify the start time to be one hour before the outage occurred) and a full-range audit of DGTT, OGTT, and NPA Splits. For information about performing audits, refer to “Audit and Optional Reconcile from the LSMS GUI” in the LNP Database Synchronization User's Guide.
5, 6, 7	If any query servers are installed: Stop the directly connected query servers. Configure each directly connected query server to use the shadow LSMS as its master host (refer to the procedure described in “MySQL Replication Configuration for Query Servers” in the Configuration Guide). For each directly connected query server, perform the procedure in “Reload a Query Server Database from the LSMS”.
8	Run on the shadow LSMS until the main LSMS is restored.
9	Returning Operation from Shadow LSMS to Main LSMS.