Higher Education

last person joined: 10 days ago 

Got questions on how to enable mobility in education? Submit them here!
Expand all | Collapse all

Ok to drop Subscriber when it's not reachable

This thread has been viewed 10 times
  • 1.  Ok to drop Subscriber when it's not reachable

    Posted Aug 27, 2020 11:04 AM

    Hi,

     

    Last night we had a subscriber suddenly go out sync (battery and sync errors in Event Viewer). CPPM cluster sees it as down. It's pingable but that's it (can't collect logs, no ssh, https, etc.). Is it ok to issue a Drop Subscriber from the publisher even though it's unreachable? Is it better to just leave it until it comes back up? In the process of opening TAC ticket. These are 25k appliances running 6.7.12. One publisher and eight subscribers.

     

    Thanks,

    Mike

     



  • 2.  RE: Ok to drop Subscriber when it's not reachable

    MVP
    Posted Aug 27, 2020 11:11 AM

    On 6.7 it it OK to drop the subscriber & re-add. I have had to do that on several occasions after updates or upgrades. You will lose some of your server configuration & SNMP community string on the subscriber.

     

    In 6.8 adding a subscriber can get a little more complex due to certificates.

     

    I have one 25K publisher & 4 25K subscribers on my main hardware appliance cluster.



  • 3.  RE: Ok to drop Subscriber when it's not reachable

    Posted Sep 03, 2020 01:26 PM

    Thanks Bruce.

    Update: The publisher still had the subscriber marked as "Node Down" in the cluster. TAC advised leaving it this way while we manually shut down the subscriber (long press on power button) and restarted. It came up cleanly in subscriber mode but not part of the cluster, responsive to KVM, ssh and https. Logs were collected.The subscriber was then dropped from the cluster. The subscriber's db and config was "reset" (a little sketchy on this part) then configured to rejoin to the cluster. It pulled its config and licensing. The only thing I saw I had left to do was reconfigure the SNMP settings and access restrictions. Log dump (1.5GB!) is being posted to the TAC case for root cause analysis.