Desktone_DatabaseReplicationService

This topic describes the Desktone_DatabaseReplicationService CIM provider.

• Description

  Provides information about database instances that are replicated. This provider runs on all Fabric database servers. In the platform, appliances have one or more database instances running, as follows:

  • Service provider appliances – Fabric Database (FDB) only
  • Tenant appliances - Fabric Database (FDB), Element Database (EDB), and App Volumes Database (AVDB)
  • Desktop manager appliances - Element Database (EDB) and App Volumes Database (AVDB)
• Properties
  • SystemCreationClassName: Name of the class used to create the database instance.
  • SystemName: Name of the system on which the database instance is running. Set to host name in our case.
  • CreationClassName: Name of the class used to create the database instance.
  • Name: Unique identification of the service. Set to hostName_databaseInstanceName.
  • NodeID: Represents the UID of the node in the context of the replication system.
  • Role: Indication of whether the database instance is primary or secondary instance.
  • SyncStatus: Synchronization status applies to the secondary instance only. This property does not have any significance in case of primary instance. For a secondary instance, the SyncStatus value will be the number of milliseconds since the last synchronization. For example, SyncStatus = 1200 means that the last successful sync was 1.2 seconds before. Warn if the SyncStatus is more than 40 seconds old. Critical if SyncStatus is more than 2 minutes old.
  • Status: Indicates the current status of the replication service. OK indicates the replication service is running. STOPPED indicates that the replication service is stopped. The replication service should be running for all database instances in use.
• Mitigation
  If replication is stopped (or if the SyncStatus is out of date), you should check that the replication daemon (slony) is running properly on the database server:

  $ ps -ef | grep db.conf
  root 1062     1  0 Sep17 ? 00:00:00 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_edb.conf
  root 1121     1  0 Sep17 ? 00:00:00 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_fdb.conf
  root 1443  1062  0 Sep17 ? 00:07:39 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_edb.conf
  root 1446  1121  0 Sep17 ? 00:06:01 /usr/local/pgsql/bin/slon -f /usr/local/desktone/release/static/conf/slon_fdb.conf
  

  There should be 2 processes for each database instance. If replication is not running properly for any of the instances, you can restart replication:

  $ nohup /usr/local/pgsql/bin/slon -f 
  /usr/local/desktone/release/static/conf/slon_fdb.conf >/dev/null 2>&1 &
  $ nohup /usr/local/pgsql/bin/slon -f 
  /usr/local/desktone/release/static/conf/slon_edb.conf >/dev/null 2>&1 &