<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="color: rgb(0, 0, 0); font-family: Calibri,Arial,Helvetica,sans-serif,"EmojiFont","Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size: 12pt;" dir="ltr">
<div>In what way are you classifying a "fail"? </div>
<div><br>
</div>
<div>Once a subscriber node goes offline, replication to that node will stop/fail at the next replication attempt with that node (and be marked down even sooner than that). If database replication for the ENTIRE cluster has failed, it isn't because of a subscriber
that has gone offline (if you're talking about an OLD cluster version (6.x<) still using hub/spoke replication and the Publisher went down, different story).
</div>
<div><br>
</div>
<div>The amount of time it takes from the time the subscriber goes on vacation to the time a replication attempt is made with that node and subsequently fails can vary, driven primarily, I believe, by the replication timeout set (latency issues aside if the
subject replication traverses a WAN). </div>
<div><br>
</div>
<div>From the CLI, a "show tech repltimeout" should show you the current timeout value set in the cluster. You can, cautiously and with purpose I would advise, set the replication values to something different using, "utils dbreplication setrepltimeout". As
an example; for a 3-4 node cluster over WAN (using reasonable WAN latency 17Ms-20Ms<), I'd be comfortable with about 300 seconds (figuring each server taking a full minute to replicate).
</div>
<div><br>
</div>
<div>The "Steps to Troubleshoot Database Replication" guide has a good read on this topic:
<a class="OWAAutoLink" href="http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200396-Steps-to-Troubleshoot-Database-Replicati.html#anc7">
http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200396-Steps-to-Troubleshoot-Database-Replicati.html#anc7</a></div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Ryan</div>
<div><br>
</div>
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
</div>
<div></div>
<div style="color: rgb(0, 0, 0);">
<div>
<div id="x_divRplyFwdMsg" dir="ltr"><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><b>From:</b> cisco-voip <cisco-voip-bounces@puck.nether.net> on behalf of Glenn, Scott <Scott.Glenn@wwt.com><br>
<b>Sent:</b> Monday, May 15, 2017 12:18 PM<br>
<b>To:</b> cisco-voip@puck.nether.net<br>
<b>Subject:</b> [cisco-voip] SME or Leaf Subscriber Offline Timer</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">I am trying to find any document that stats a timeframe for which database replication fails or begins to fail if a subscriber is offline for X amount of time(number of hours or days).<br>
<br>
Thanks,<br>
<br>
Scott Glenn | Sr UC Engineer <br>
CCIE Collaboration #54407<br>
World Wide Technology, Inc.<br>
402-305-0585<br>
Scott.glenn@wwt.com<br>
<br>
Sent from my iPhone<br>
_______________________________________________<br>
cisco-voip mailing list<br>
cisco-voip@puck.nether.net<br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
</span></font></div>
</div>
</body>
</html>