[cisco-voip] cucm 6.1 replication problem
l brahmam
lbrahmam at gmail.com
Mon Feb 9 02:03:00 EST 2009
Thanks Ryan
Kindly find the attachment, and help me to change time setting on both to
sync.
-Brahmam
On Fri, Feb 6, 2009 at 9:44 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> 'utils ntp status' on both servers will give you the current time and
> timezone. The sub should be using the pub as an NTP server and if for some
> reason the times are not sync'd replication will fail.
>
> -Ryan
>
> On Feb 6, 2009, at 4:22 AM, l brahmam wrote:
>
> Hi
>
> Kindly find the attachment for timezones configured on both. Let me know
> the command different to check and change the timezone.
>
> Thanks
> Brahmam
>
> On Fri, Feb 6, 2009 at 7:24 AM, Samuel Womack <womacksamuel at gmail.com>wrote:
>
>> And be extremely PATIENT....Seriously, Be PATIENT...
>>
>>
>> On Feb 5, 2009, at 7:50 PM, Jason Burns wrote:
>>
>> Sorry for the confusion. Here is what step 3 should read:
>>
>> 3. In the SSH Admin CLI of the Publisher server run the following command
>>
>> utils dbreplication reset <name of the problem subscriber>
>>
>>
>>
>> On Wed, Feb 4, 2009 at 6:03 AM, James Buchanan <jbuchanan at ctiusa.com>wrote:
>>
>>> I had this same issue recently. NTP had failed on the Publisher and the
>>> Publisher had the wrong time. The Subscriber had close to the right time.
>>> The servers were an hour apart from each other. Once we got the time the
>>> same on the two servers synchronization would work.
>>>
>>>
>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *l brahmam
>>> *Sent:* Wednesday, February 04, 2009 1:29 AM
>>> *To:* Scott Voll
>>> *Cc:* cisco-voip at puck.nether.net
>>> *Subject:* Re: [cisco-voip] cucm 6.1 replication problem
>>>
>>>
>>> Hi
>>>
>>> I have executed
>>>
>>> 1. Run "utils dbreplication stop" on the subscriber - wait for this to
>>> finish
>>> 2. Run "utils dbreplication stop" on the publisher - wait for this to
>>> finish
>>> 3. Run "utils dbreplication reset" on the subscriber as its not allowing
>>> me to run on publisher.
>>>
>>> Kindly find below for output of commands and suggest me how can i make
>>> replication works fine.
>>>
>>> [root at lurtz ~]# ssh admin at 192.168.101.21
>>> admin at 192.168.101.21's password:
>>> Last login: Mon Jan 5 00:57:32 2009 from 10.1.2.80
>>>
>>> Welcome to the Platform Command Line Interface
>>>
>>> Uptime : 05:14:07 up 201 days, 6 min, 1 user,
>>> Load average : 0.13, 0.10, 0.09
>>> Platform OS version : UCOS 3.0.0.0-56
>>> HW model : 7825H3
>>>
>>> admin:exit
>>>
>>>
>>>
>>> Copyright Cisco Systems 2006
>>> Connection to 192.168.101.21 closed.
>>> [root at lurtz ~]# ssh admin at 192.168.101.20
>>> admin at 192.168.101.20's password:
>>> Last login: Mon Dec 22 01:56:05 2008 from 10.1.2.80
>>>
>>> Welcome to the Platform Command Line Interface
>>>
>>> Uptime : 06:15:18 up 19 days, 18:12, 1 user,
>>> Load average : 1.15, 0.66, 0.59
>>> Platform OS version : UCOS 3.0.0.0-56
>>> HW model : 7825H3
>>>
>>> admin:utils dbreplication stop
>>>
>>> ********************************************************************************************
>>> This command will delete the marker file(s) so that automatic replication
>>> setup is stopped
>>> It will also stop any replication setup currently executing
>>>
>>> ********************************************************************************************
>>>
>>> Deleted the marker file, auto replication setup is stopped
>>>
>>> Service Manager is running
>>> A Cisco DB Replicator[STOPPING]
>>> A Cisco DB Replicator[STOPPING]
>>> Commanded Out of Service
>>> A Cisco DB Replicator[NOTRUNNIG]
>>> Service Manager is running
>>> A Cisco DB Replicator[STARTED]
>>> Completed replication process cleanup
>>> admin:exit
>>>
>>>
>>>
>>> Copyright Cisco Systems 2006
>>> Connection to 192.168.101.20 closed.
>>> You have new mail in /var/spool/mail/root
>>> [root at lurtz ~]# ssh admin at 192.168.101.21
>>> admin at 192.168.101.21's password:
>>> Last login: Tue Feb 3 05:14:07 2009 from 10.1.2.1
>>>
>>> Welcome to the Platform Command Line Interface
>>>
>>> Uptime : 05:31:36 up 201 days, 23 min, 1 user,
>>> Load average : 0.06, 0.10, 0.09
>>> Platform OS version : UCOS 3.0.0.0-56
>>> HW model : 7825H3
>>>
>>> admin:utils dbreplication stop
>>>
>>> ********************************************************************************************
>>> This command will delete the marker file(s) so that automatic replication
>>> setup is stopped
>>> It will also stop any replication setup currently executing
>>>
>>> ********************************************************************************************
>>>
>>> Deleted the marker file, auto replication setup is stopped
>>>
>>> Service Manager is running
>>> A Cisco DB Replicator[STOPPING]
>>> A Cisco DB Replicator[STOPPING]
>>> Commanded Out of Service
>>> A Cisco DB Replicator[NOTRUNNIG]
>>> Service Manager is running
>>> A Cisco DB Replicator[STARTED]
>>> Completed replication process cleanup
>>> admin:utils dbreplication reset IndiaCCM61-Prim
>>> You have entered nodename as publisher node. You must enter subscriber
>>> node name.
>>>
>>> Executed command unsuccessfully
>>>
>>> admin:utils dbreplication reset IndiaCCM61-Sec
>>> Repairing of replication is in progress.
>>> Background repair of replication will continue after that for 30
>>> minutes..
>>>
>>> admin:
>>>
>>> Thanks
>>> Brahmam.
>>>
>>> i could be see the status on both servers as 2. currently i have
>>> hostnames seperately on server. Kindly let me know does it cause any issue.
>>>
>>> On Fri, Sep 26, 2008 at 9:25 PM, Scott Voll <svoll.voip at gmail.com>
>>> wrote:
>>>
>>> I believe Jason is correct that your replication is in deed broke.
>>>
>>>
>>> but as an FYI you might not see these with both server with a 2. I had
>>> the same problem and host names (even though they could ping each) it didn't
>>> fix until I changed the host names to IP addresses.
>>>
>>>
>>> Scott
>>>
>>> On Wed, Sep 24, 2008 at 2:56 PM, Jason Burns <burns.jason at gmail.com>
>>> wrote:
>>>
>>> Your replication is indeed broken.
>>>
>>> 1. Run "utils dbreplication stop" on the subscriber - wait for this to
>>> finish
>>> 2. Run "utils dbreplication stop" on the publisher - wait for this to
>>> finish
>>> 3. Run "utils dbreplication reset" on the publisher
>>>
>>> After that churns for a while you should see your replication status go
>>> back to 2 (as long as you don't have any network connectivity problems
>>> between the servers).
>>>
>>> -Jason
>>>
>>>
>>> On Wed, Sep 24, 2008 at 4:09 AM, l brahmam <lbrahmam at gmail.com> wrote:
>>>
>>> Kindly find the attachment for the current status of my CUCM and suggest
>>> me if i can run dbreplication reset command on both publisher and
>>> subscriber.
>>>
>>> Thanks
>>> Brahmam
>>>
>>>
>>> On Tue, Sep 23, 2008 at 5:34 PM, Jason Burns <burns.jason at gmail.com>
>>> wrote:
>>>
>>> Brahmam,
>>>
>>> You can run
>>>
>>> utils dbreplication status
>>>
>>> on the publisher, or view the Unified Reporting Tool pages, or RTMT to
>>> check your replication status.
>>>
>>> Here is an article with the procedure for resetting replication:
>>>
>>>
>>> http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00809643e8.shtml
>>>
>>> This was the first article that came up when I ran a Google search for
>>>
>>> cisco callmanager 6.1 database replication
>>>
>>> -Jason
>>>
>>> On Tue, Sep 23, 2008 at 5:24 AM, l brahmam <lbrahmam at gmail.com> wrote:
>>>
>>> Hi
>>>
>>>
>>> We have CUCM 6.1 publisher and subscriber, if i add a device to publisher
>>> its not reflecting at subscriber. I hope problem with db replication. Kindly
>>> help me and provide the information to fix the same.
>>>
>>>
>>> Thanks
>>>
>>> Brahmam
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.0.233 / Virus Database: 270.10.17/1932 - Release Date:
>>> 02/03/09 07:57:00
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>>
>
>
> --
> --
> \\\||///
> \\ - - //
> ( @ @ )
> -oOo--( )--oOo-------------------------------------------------------
> <publishertime.jpg><subscribertime.jpg>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
--
--
\\\||///
\\ - - //
( @ @ )
-oOo--( )--oOo-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090209/3d34ecf6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ntpstatus.jpg
Type: image/jpeg
Size: 95352 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090209/3d34ecf6/attachment.jpg>
More information about the cisco-voip
mailing list