Guest

Cisco Unified MeetingPlace

Field Notice: Cisco Unified MeetingPlace Application Server Can Go Down Due to Replication Issues

  • Viewing Options

  • PDF (27.9 KB)
  • Feedback
Field Notice: Cisco Unified MeetingPlace Application Server Can Go Down Due to Replication Issues

Table Of Contents

Field Notice: Cisco Unified MeetingPlace Application Server Can Go Down Due to Replication Issues

Problem

Workaround/Solution


Field Notice: Cisco Unified MeetingPlace Application Server Can Go Down Due to Replication Issues


Published: June 21, 2010

This field notice is for customers who have not already encountered a replication issue. We recommend that all such customers apply the noted hotfix as a preventative measure.

CDET
Product Affected
Conditions

CSCtg85474

Cisco Unified MeetingPlace Application Server

Two Application Servers (node 1 and node 2) are configured in a failover deployment.

Servers have Release 7.x or 8.0 (all versions) installed.


Problem

Due to an issue with the IBM Informix database management system, the sblob_dbspace may get full during the replication process and cause the Cisco Unified MeetingPlace Application Server to fail. The failure will see the Application Server reboot multiple times when attempting to start MeetingPlace services, and the services will fail to start when attempting to use the CLI command mpx_sys restart. Additionally, output from the CLI command mp_replication status on either node 1 or node 2 may show that the connected (remote) server has a very large value in the Queue column.

Workaround/Solution

Cisco has made a hotfix available called sblob_dbspace-fix.sh. The hotfix creates a second database chunk (sblob_dbspace2), which is approximately 1GB in size or 20x larger than sblob_dbspace. Once applied, the system will automatically start filling sblob_dbspace2 once sblob_dbspace is full.

To apply the hotfix, contact your Cisco TAC representative.


Note Without the hotfix, the system raises an alarm when sblob_dbspace is 90% full. Under heavy load, this gives you approximately three minutes to create additional space for the database replication queue. If the additional space is not created within this time, the system will fail.