cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
342
Views
0
Helpful
9
Replies

CM Publisher

asapun
Level 1
Level 1

Is this statement made by Cisco TAC correct?

All subscribers, as long as they have connectivity to the publisher, will always use the publisher database for every database transaction. The only time the local database is used is when the publisher is unavailable.

Does this mean, that the only reason we have Subscribers is for redundancy?

This statement is very confusing.

Anybody?!

Thanks in advance

9 Replies 9

mimckee
Level 1
Level 1

For the ccmadmin this is true. As long as the publisher is up whether you are running ccmadmin from the pub or any sub is it always reading and writing to the publisher database. If the pub is down then the subs will look at there local database. They can only read from that not write.

One thing I will add from my experience that seems to be true. I am not sure if it is 100% but here goes. It seems to me if a phone is going to register with a sub then the sub will look in his local database to see if the device is there and can register. Like I said this is what I have noticed personally.

Keep in mind there are 2 forms of redundancy in callmanager clusters. The database redundancy and the callprocessing redundancy.

Hope this helps,

-Mckee

Thanks for your reply.

Are you saying that if the Pub is down you cannot MAC (move, add and change)?

Can't one MAC on a SUB? One would think yes, being that their databases are being constantly replicated!

And what other information but MAC and other Call Manager changes are stored in the CM SQL server. Are MACs considered to be the 'database'?

Thanks again.

Nope, you can't do database changes if the Pub is down, the subs retain the database only for the purpose of allowing the system to continue in its current state.

Thank You Mckee for your input.

Refering to your experience on the second paragraph, about the phone that registers with a local Sub will look in the local Sub's database, how did you check that? Is there a way to determine that that is indeed true?

and second,

if there was a system in place with 7500 IP phones, with four Call Managers,

would still all 7500 phones read the database from the Pub?,

(isn't there a limitation to how many IP phones can each CM handle? as far as I know each CM can handle up to 2500 IP phones!)

Looking at it from this prospective, makes me think that a local phone allways referes to it's local CM's database.

Thanks again for your true professional input.

As far as I know the phones always use the Sub they are registered to for database transactions, so if a user puts a CallForwardAll on their phone it updates its Sub, which in turn updates the Pub.

As for the amount of phones, in 3.1 its 2500 per CM, thats the max, it can be less than that if you have other devices that have a high weight.

From 3.2 and above the system has changed and the amount of phones you can register is based on "busy hour call completion" (something like that anyway), Ive yet to read any info on CCO about how you actually calculate this though, has anyone got any useful links on this?

Thanks Gary,

but they claim that a Sub has a read only database, and you're saying that by using CallForwardAll it updates the SUB!?

Thank You for your help Gary.

Ok... :)

In that case (not many options left), the phone always reads the publisher database on boot up, if its not there it uses the subscribers database that its registered to.

I know it does that as Ive had a subscribers db out of sync with the pub and it always used to sub's until they were sync'ed.

Gary

mimckee
Level 1
Level 1

When the pub is down you can not make any changes in the ccmadmin. You will get a funky error I think something with dbl. It has been a while since I have seen it.

Thank you,

-Mckee

Yeah, it says something about the database being locked or something.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: