我有一些现在已经运行了一个月左右的群集，并且发现Service Fabric日志文件完全吞噬了临时存储。在一个只有16GB本地存储的F1虚拟机上我只是空间不足，其中一些现在已经下降到30MB，是大字节的存储空间（我的应用程序消耗的空间不到1GB）所有版本）。
在查看群集VM上的磁盘使用情况时，我可以清楚地看到SvcFab \ Log和SvcFab \ ReplicatorLog文件夹消耗了超过90％的可用空间。当然SF可以更好地处理这个问题。有什么我可以切换或配置，以使其刷新一些数据？或者更好的是将其移动到blob或table存储？
这对其他人来说一定是个问题。别人在做什么？而Service Fabric团队，最佳做法是什么？
答案 0 :(得分：0)
如果复制器日志已满，则表示您正在使用F1进行数据存储......对于您的数据存储而言，16GB并不是很多，您最好将应用程序分解为具有不同集的处理/存储服务。
不是关于SF如何存储事物的专家（我将离开并修剪给其他人，但没有很多信息）但是如果它类似于复制器日志的类似解决方案有部分数据并且它会减少安全..而不是F1你可能更好地使用F2和F4，因为他们有* 2或* 4的IO和核心你不会失去任何东西，但获得额外的存储..这意味着更少的复制（除非你做了很多分区）。
答案 1 :(得分：0)
因此没有有用的帮助。我试图拆掉那个集群并重建它。幸运的是，对于我来说，集群是一对中的一个，我能够简单地将所有流量通过TrafficMgr重定向到另一个集群，同时我销毁了故障并创建了一个新集群。
让我非常不安。如果我没有这种冗余，那将是一个相当大的问题。 ： - （
答案 2 :(得分：0)
我不确定以下是否会被视为拆除群集！我在虚拟服务结构应用程序上的无状态服务上测试了这个
我们在standard_DS1_V2上部署的服务结构遭受了法定人数损失，并且由于磁盘空间不足，健康分析服务也失败了。我没有拆除群集，而是使用ARM power shell
停止了vm规模集stop-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"
然后转到Azure门户＆gt;资源组＆gt; <虚拟机规模集>缩放以将SKU压缩到Standard_D1_V2并启动VM Scale Set
start-azurermvmss -ResourceGroupName "RG" -VMScaleSetName "VMSS"
并重新部署了服务结构应用程序，它按预期工作！