Subscriber DB changes

Answered Question
Mar 10th, 2009
User Badges:

Prior to 6.x its always been understood you never make DB changes on a Subscriber, only the Publisher. From 6.x onwards there is this statement in the SRND:

"Unified CM 6.x and later releases, subscriber servers in the cluster read their local database. Database modifications can occur in both the local database as well as the publisher database, depending on the type of changes."

Does anyone know what is meant by "type" of changes. Unless there is any detail about what can/can't be done I'm inclined to play safe and continue to advise all changes must be done on the Publisher. I'm trying to understand what would be safe to change under Publisher failure scenarios.

Correct Answer by Rob Huffman about 8 years 3 months ago

Hi Billy,


Pre - 6.x


The configuration database is stored on a publisher server, and a read-only copy is replicated to the subscriber members of the cluster. Changes made on the publisher are communicated to the subscriber databases, ensuring that the configuration is consistent across the members of the cluster, as well as facilitating spatial redundancy of the database.


The publisher server is the only server that has read and write access to the configuration database. When configuration changes are made, other members of the cluster have a read-only copy of the database.


From this CCM SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42clproc.html



This changes with the release of CCM 6.x;


In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached. With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster. When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.

Database modifications for CallProcessing


User Facing features can be made on subscribers. These include updates for:


Call Forward All (CFA)

Message Waiting Indication (MWI)

Privacy Enable/Disable

Do Not Disturb Enable/Disable (DND)

Extension Mobility Login (EM)

Monitor (for future use, currently no updates at the user level)

Hunt Group Logout

Device Mobility

CTI CAPF status for end users and application users

Credential hacking and authentication


From this 6.x SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/callpros.pdf


This capability only applies to the "User Facing" features listed above. For example, in all previous versions of CCM if the Publisher was down no CFWDALL changes could be made on the user phones. Now these phones can set or unset CFWDALL due this new Subscriber ability to do these type of Database Modifications. Same with EM and the others that were listed. It's not like having two Publisher servers but is a Huge improvement in the overall cluster redundancy :)


With Unified CM 6.x, database modifications for user-facing call processing features are made on the subscriber servers to which the IP phones are registered. The subscriber servers then replicate these database modifications to all the other servers in the cluster, thus providing redundancy for the user-facing features.


(See “Call processing user-facing feature replication” in Figure 8-2.)


From this 6.x SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/callpros.pdf



Hope this helps and makes sense!

Rob

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Rob Huffman Tue, 03/10/2009 - 06:59
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi Billy,


Pre - 6.x


The configuration database is stored on a publisher server, and a read-only copy is replicated to the subscriber members of the cluster. Changes made on the publisher are communicated to the subscriber databases, ensuring that the configuration is consistent across the members of the cluster, as well as facilitating spatial redundancy of the database.


The publisher server is the only server that has read and write access to the configuration database. When configuration changes are made, other members of the cluster have a read-only copy of the database.


From this CCM SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42clproc.html



This changes with the release of CCM 6.x;


In prior versions of Cisco Unified Communications Manager, subscriber servers in the cluster use the publisher database for READ/WRITE access, and only use the local database for READ access when the publisher database cannot be reached. With Cisco Unified Communications Manager Release 6.0, subscriber servers in the cluster READ the local database. DB WRITES happens in both the local database as well as the publisher database, depending on the type of data. DBMS (IDS) replication is used to synchronize the databases on the nodes of the cluster. When recovering from a failover conditions such as loss of WAN connectivity for extended period of time, the Cisco Unified Communications Manager databases need to be synchronized with any changes that may have been made during the outage. This process happens automatically when database connectivity gets restored. This process may take longer over low bandwidth and/or higher delay links.

Database modifications for CallProcessing


User Facing features can be made on subscribers. These include updates for:


Call Forward All (CFA)

Message Waiting Indication (MWI)

Privacy Enable/Disable

Do Not Disturb Enable/Disable (DND)

Extension Mobility Login (EM)

Monitor (for future use, currently no updates at the user level)

Hunt Group Logout

Device Mobility

CTI CAPF status for end users and application users

Credential hacking and authentication


From this 6.x SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/callpros.pdf


This capability only applies to the "User Facing" features listed above. For example, in all previous versions of CCM if the Publisher was down no CFWDALL changes could be made on the user phones. Now these phones can set or unset CFWDALL due this new Subscriber ability to do these type of Database Modifications. Same with EM and the others that were listed. It's not like having two Publisher servers but is a Huge improvement in the overall cluster redundancy :)


With Unified CM 6.x, database modifications for user-facing call processing features are made on the subscriber servers to which the IP phones are registered. The subscriber servers then replicate these database modifications to all the other servers in the cluster, thus providing redundancy for the user-facing features.


(See “Call processing user-facing feature replication” in Figure 8-2.)


From this 6.x SRND;


http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/callpros.pdf



Hope this helps and makes sense!

Rob

billybjo1 Tue, 03/10/2009 - 07:14
User Badges:

Excellent reply, many thanks. So it seems from a phone perspective, there is definately some improvement. But from an admin perspective, we still shouldn't be making any changes to the ccmadmin on a subscriber?

Rob Huffman Tue, 03/10/2009 - 07:35
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi Billy,


You are most welcome my friend!


You know, that is an excellent question! We have always made changes via the Publisher as well, this does seem like a fairly natural "best Practice". This is in fact, not a hard and fast rule though. Changes to phones etc. can be made via the Subscribers and will replicate across to the Pub who will then "write" them into the dB.


I still prefer making changes from the Pub itself :)


FWIW,


Cheers!

Rob

M.Kemal YENIGUN Thu, 03/23/2017 - 08:00
User Badges:

I have a question about  CUCM 10.5.2. I can able to add /remove  sip trunk, phone and end user on the subscriber i can not do it on version 11.x why ?


Can I always write user facing feature all  6.x later version ?

sip trunk, phone and end user which category  for user facing feature ?


Thanks


Ayodeji Okanlawon Thu, 03/23/2017 - 13:54
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

You can add phones and SIP trunk on subscriber in version 11. I just did now

M.Kemal YENIGUN Thu, 03/23/2017 - 23:14
User Badges:

But I did try id I not succeeded. I can able to add with version 10.5.2 using with subscirber. I  noticed that İ When I trying it publisher is up and running during this time.


On the following link Rob Homan mentioned that is  normal Behaviour if publisher goes down i could not    do it on subscriber because sub and pub  communicate then pub write it db. If I have mistake please correct me ?

https://supportforums.cisco.com/discussion/10314291/database-read-and-wr...

Ayodeji Okanlawon Fri, 03/24/2017 - 00:39
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

Yes you can't make some changes like adding devices, when the publisher is down. But your publisher is up so you should be able to add on Subscriber. I generally don't recommend that though. Always make changes on your Pub. 

What error are you getting. You may have database replication issue. Use RTMT to check the status of your database 

Actions

This Discussion