This topic describes the Desktone_DatabaseReplicationService CIM provider.
Provides information about database instances that are replicated. This provider runs on all Fabric database servers. In the DaaS 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)
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 master or slave instance.
SyncStatus: Synchronization status applies to the slave instance only. This property does not have any significance in case of master instance. For a slave 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.
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 &