Resynch Cluster after OLD Database restore on system

[12345kevin]

We have a scenario where there are 2 systems in a cluster (A&B) Due to a chassis issue the database on system B was restored onto anew chassis, however due to various issues the only one available was a few months old !! We now have a problem where System B is completely out of synch with system A. We know of at least 80 new extensions and continuous moves and changes that have been added to the network after the database was saved and therefore have a considerable mismatch. Looking through the help files a resynch using "data repair" appears to be the only option.

What would be the best approach to getting the 2 systems back into synch.

 

[Supernova99]

Perform a full sync should be the way to go do it from the system that has the newest up to date info and perform a full sync (select all the options)
This will then update the other controller with the changes.

Share what you know - Learn what you don't

 

[LoopyLou]

You will have to do a lot of manual fixing. A sync won't program up a set missing from the database.

The beatings will continue until morale improves.

 

[Supernova99]

True but if the changes are on the other controller a sync will at least update or add them as RDN, teldir, pickup etc.
If the changes were made to the system that failed then the only way to get them back is manually adding them.

Share what you know - Learn what you don't

 

[12345kevin]

Thanks, all missing phones on System B were reprogrammed, it is mainly all the sets and changes that were made at system A that are the problem. So hopefully a Synch will sort a lot of it out.

 

[augustD2]

From the help files:

SDS - Repairing Data

If the database of a controller is severely out of sync, you can restore the database from a backup. However, the backup database will not include the recent database changes that have been made to other systems in the cluster while the controller was down. After performing the data restore, you can bring the controller's database up to date, by performing a Data Repair operation from another controller in the system.

The Data Repair operation overwrites all the shared data, including the user and device data, on the slave controller with the shared data from the master controller.

Perform a data restore of the latest backup to the secondary controller.

Access the Network Elements form of a controller in the cluster that has up to date data.

Synchronize the data from the local, master controller to the slave controller. Before you confirm the synchronization operation:

Select the Data Repair option in the Confirm Sync to Element(s) window

Click the Advanced button

Set the Resilient User-Device Policy to "Synchronize data where <local element> is the PRIMARY and SECONDARY host for resilient devices".

Click Apply

Click OK