[cisco-voip] Constantly having db replication issues
Brian Meade
bmeade90 at vt.edu
Wed Apr 20 18:49:59 EDT 2016
You can also do "file tail activelog cm/trace/dbl/sdi recent" which will
tail the most recent log file in the directory. Saves you a few seconds.
On Wed, Apr 20, 2016 at 6:00 PM, Daniel Ohnesorge via cisco-voip <
cisco-voip at puck.nether.net> wrote:
> Hi Nick,
>
> At the time of failure, I like to tail the dbl logs to see whats
> happening. First, run the command to see which log is the latest; file list
> activelog cm/trace/dbl/sdi date detail. That output will list the last
> written log file at the bottom for example log16.log. Then you can tail
> file using the command; file tail activelog cm/trace/dbl/sdi/log16.log.
> This will give you some idea of what is happening at that time.
>
> On 2016-04-21 07:20, Nick Barnett wrote:
>
> Thanks James
>
> Ok, yes, there's a lot in rhosts. They are all identical, and each of them
> has forward and reverse lookups.
>
>
>
> On Wed, Apr 20, 2016 at 12:39 PM, James Buchanan <
> james.buchanan2 at gmail.com> wrote:
>
>> Hello,
>>
>> Even though you are not using DNS, do you have DNS servers and a domain
>> name configured? If so, you should have forward and reverse entries
>> configured for all servers. When you look in Unified Reporting, do you see
>> anything about the rhosts under Database Status?
>>
>> Thanks,
>>
>> James
>>
>> On Wed, Apr 20, 2016 at 1:07 PM, Nick Barnett <nicksbarnett at gmail.com>
>> wrote:
>>
>>> Thanks Ryan.
>>>
>>> We have 3 CCM and 1 TFTP node in each of our two data centers. The main
>>> data center is here, and that is where our DRS sftp server (and publisher)
>>> is located. Nothing is using DNS right now, all of the servers are entered
>>> into CUCM as IP addresses... this cluster has been around for years. It was
>>> upgraded from 7.BeforeMyTime to 8.6 to 10.0.
>>>
>>>
>>>
>>> On Wed, Apr 20, 2016 at 11:54 AM, Ryan Huff <ryanhuff at outlook.com>
>>> wrote:
>>>
>>>> Hi Nick.
>>>>
>>>> Let me ask you a few things;
>>>>
>>>> - How is the cluster laid out (how many nodes in the cluster and what
>>>> nodes are in which DC)?
>>>>
>>>> - Are you using DNS and if so, where is the DNS server located and do
>>>> you have redundant DNS in both DCs?
>>>>
>>>> - Where is your DRS server in relation to the cluster publisher (same
>>>> DC or no)?
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>
>>>> On Apr 20, 2016, at 11:09 AM, Nick Barnett <nicksbarnett at gmail.com>
>>>> wrote:
>>>>
>>>> I'm wondering how many others have had as many issues with db
>>>> replication? It seems that any time we lose a connection to our 2nd data
>>>> center (even a 2 minute MPLS planned maintenance outage causes the issue),
>>>> our database synchronization has errors. After a WAN blip, within an hour
>>>> or so, I get a message from RTMT about a subscriber being in "blocked"
>>>> state:
>>>>
>>>>
>>>> %[AppID=Cisco Database Layer
>>>> Monitor][ClusterID=ProdVoiceCluster][NodeID=XXXXXXX1]: A change
>>>> notification client is busy (blocked). If the change notification client
>>>> continues to be blocked for 10 minutes, the system automatically clears the
>>>> block and change notification should resume successfully."
>>>>
>>>>
>>>>
>>>> After that, if I run utils dbreplication status, it will have errors...
>>>> so then I run the "repair all" option and it fixes it. Then I'm good for a
>>>> few weeks until something else happens that starts the whole cycle over.
>>>>
>>>> Something else that happens after a WAN blip is that DRS begins to
>>>> fail, so we have to restart the master DRS and the subsequent DRS services
>>>> on the subs. Am I doing something wrong? Is this normal?
>>>>
>>>> I'm on CUCM 10.0.1.12900-2.
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160420/9d63f4f8/attachment.html>
More information about the cisco-voip
mailing list