Service Fabric应用升级遇副本卡住告警，如何安全强制重启？

我之前处理过好几起Service Fabric升级时副本ChangeRole卡住的情况，结合你遇到的IStatefulServiceReplica.ChangeRole(S)Duration警告（节点_gtmsf1_0上的副本从UTC 2018-03-21 15:49:54开始卡住），给你梳理几个安全的重启方法，顺便提下后续排查的关键点：

一、用Service Fabric CLI（sfctl）操作 #

这是最常用的集群管理工具，步骤清晰：

1. 定位卡住的副本
   先找到目标应用下的服务ID：

   sfctl service list --application-id <你的应用ID>
   

   再列出该服务的所有副本，找到节点_gtmsf1_0对应的ReplicaId和PartitionId：

   sfctl service replicas list --service-id <刚才查到的服务ID>
   

2. 强制重启副本
   执行重启命令，这里推荐用RemoveData模式（彻底清除本地状态后从健康副本同步，适合卡住且状态可能损坏的场景）：

   sfctl partition restart-replica --partition-id <分区ID> --replica-id <副本ID> --restart-kind RemoveData
   

   如果只是想尝试不清除状态的重启，把--restart-kind改成RestartReplica就行，但这种情况大概率RemoveData能彻底解决问题。

二、用PowerShell操作（适合Windows环境） #

如果你习惯用PowerShell，步骤也很简单：

1. 准备连接集群
   先导入Service Fabric模块并连接到集群：

   Import-Module ServiceFabric
   Connect-ServiceFabricCluster -ConnectionEndpoint <你的集群端点>
   

2. 定位目标副本
   过滤出节点_gtmsf1_0上的副本：

   Get-ServiceFabricService -ApplicationName <你的应用名> | Get-ServiceFabricReplica | Where-Object { $_.NodeName -eq "_gtmsf1_0" }
   

3. 执行重启
   同样推荐清除数据的重启方式：

   Restart-ServiceFabricReplica -PartitionId <分区ID> -ReplicaId <副本ID> -RemoveReplicaData $true
   

三、后续排查与优化 #

既然你怀疑是取消令牌没处理好，重启后一定要重点检查ChangeRoleAsync方法的代码：

• 确保方法内全程监听传入的cancellationToken，一旦触发取消，要立刻释放资源并终止方法执行
• 所有异步操作都要传递这个取消令牌，比如await SomeLongRunningAsyncOp(cancellationToken)，别把它当成摆设
• 可以在取消触发时添加日志，方便后续快速定位问题

小提示：如果重启单个副本后问题依旧，可以尝试重启整个分区，但优先单个副本重启，这样影响面更小。

内容的提问来源于stack exchange，提问作者Sam Schneider