Cisco Cisco Unified IP Interactive Voice Response (IVR) 8.0(1) 管理员指南
Chapter 12 Managing Unified CCX Datastores
About Unified CCX Datastore
12-2
Cisco Unified CCX Administration Guide, Release 7.0(1)
About Unified CCX Datastore
The Unified CCX Cluster uses the publisher/subscriber database model for data
replication across the system. Under normal circumstances, the publisher acts as
the source of data and the subscriber acts as the target for the data.
replication across the system. Under normal circumstances, the publisher acts as
the source of data and the subscriber acts as the target for the data.
Note
It is recommended not to install SQL Server with Unified CCX to store your
custom data. You cannot alter SQL Server configuration settings and this might
impact the functioning of the contact center.
custom data. You cannot alter SQL Server configuration settings and this might
impact the functioning of the contact center.
The publisher/subscriber database model enables Unified CCX to provide
high-availability and failover support. To support this on the database level, the
data must be available on multiple nodes of the cluster. To have such data
availability, replication is used for the Agent, Historical, and Repository
datastore. (The Configuration datastore does not use replication; instead, it uses
atomic transaction to commit data changes to all active Configuration datastore in
the cluster.)
high-availability and failover support. To support this on the database level, the
data must be available on multiple nodes of the cluster. To have such data
availability, replication is used for the Agent, Historical, and Repository
datastore. (The Configuration datastore does not use replication; instead, it uses
atomic transaction to commit data changes to all active Configuration datastore in
the cluster.)
The publisher is the main database. All data is written to this database, with the
other databases (subscribers) synchronizing with the publisher. If the publisher
fails, then data can be written to the subscriber(s). When the publisher is back
online, it returns to accepting writes. It also synchronizes with the subscriber(s)
by performing the following functions:
other databases (subscribers) synchronizing with the publisher. If the publisher
fails, then data can be written to the subscriber(s). When the publisher is back
online, it returns to accepting writes. It also synchronizes with the subscriber(s)
by performing the following functions:
•
Adding any files or records that are new.
•
Deleting any files or records that have been removed.
•
Updating any files or records that have a later modification time stamp on the
subscriber database.
subscriber database.
When the publisher is fully synchronized, then all subscribers return to
synchronizing with the publisher.
synchronizing with the publisher.
Note
You cannot deactivate publisher datastore components. To deactivate a publisher
datastore component, first change the component to be a subscriber and then
activate the component (see
datastore component, first change the component to be a subscriber and then
activate the component (see
).