5 Replies Latest reply: May 7, 2012 8:04 AM by Patrick Geschwindner - CCIE R&S, CCSI RSS

    publisher and subscriber db issue


      People i need your advice.


      Hard disk failed on my publisher and have been running on subscriber.


      I installed a fresh cucm as first node and made it publisher with the intension of restoring from back up and also synchronise it with the subscriber database so that it will be current.


      To my surprise, after installation the subscriber do not have any device or gateways etc, am guessing it has synced with the new publisher and everything seems fresh.


      I need help in recovering the old data in the subscriber. The back up i have is 3 years old and i was just going to use it  for the publisher and get recent value from subcriber.



      My question now i scan i take the cluster to where it was before the subscriber synced with fresly installed publisher.

        • 1. Re: publisher and subscriber db issue

          It is my understanding that the subscriber has a read only copy of the DB. So you could not have recovered it even if it had not synced with the new publisher.

          • 2. Re: publisher and subscriber db issue
            Patrick Geschwindner - CCIE R&S, CCSI

            The callmanager is based on a single subscriber database model with real-time replication to the Subscribers. The Publisher is the owner of the database and can read/write in all fields. The subscribers are having a copy of the database so they can function without the publisher (so the publisher is not a single point of failure) but can only write into the fields for the user facing functions (e.g. MWI, DND, Call forward etc). In the case of a publisher failure please don't get the idea to reboot a subscriber, it will not get the updated copy of the publisher database if that one is down.


            It is not possible to replicate a Publisher database from a subscriber by any built-in function so you better have a decent backup of the publisher. There is a chance to do what you wanted to do with a third party tool called Uplinx. This allows you to do a report on the subscriber database during runtime and reconstruct most of the database in a publisher after a new install. This method is not supported by cisco in any means and also may leave some settings untouched. You need to do thorough testing to make sure if everything is back to the original state.




            • 3. Re: publisher and subscriber db issue

              Another twist to the situation.


              I installed a fresh publisher, it synced with the existing subscriber hence all my devices including gatways and phones vanished from cluster, but the phones and gateways are still fully functional.Since i cant see them from the cluster (new pub and existing sub) i cant control them.


              However when i shut down the fresh pub, all devices (including phones and gateways) showed up on the sub.At list i have a view of them and ofcourse cant edit or do anything.



              Why cant cisco build a sub that can be used to recover a pub!

              • 4. Re: publisher and subscriber db issue

                They can, but that is not the intention of the Publisher / Subscriber relationsip. 

                • 5. Re: publisher and subscriber db issue
                  Patrick Geschwindner - CCIE R&S, CCSI

                  If you look at the possibilities you have in IDS (IBM sql database) you see that there are structures to have redundant publishers and also the possibility to promote a subscriber to a publisher after the publishers death. Both of these structures are not possible in the UCM database and have never been possible since Selsius invented the original Callmanager. The reason is simple: Promoting a Subscriber would mean your publisher will be geographically in a different place after this move and possibly resides at a suboptimal place. A redundant publisher means a way more complex replicaton schedule in a real-time replication based sql database. Because of this Cisco had good reasons not to extend the structure (which also would mean a more complex DB-structure with these features). The publisher is not a single point of failure because the subscriber can continue without the publisher. You just need a current backup or you extract the database with 3rd party tools as long you did not reboot the subscriber after the publisher quit it's duty