tswddd的博客

snode2存储不足有两种可能的后果：如果出错的实例是primary，则会处于持续尝试重启的状态，kubernetes的failover机制无法将primary转交到其它实例。本来应该用sql查看WAL，但发现WAL的容量远小于分配值，之前对WAL过大的假设不成立。同时，通过PVC的zfs编号确认数据库的PVC之占据很小的空间，不是存储不足的原因。另外，节点snode1和snode3并没有存储不足。开始以为是存放WAL的PVC资源分配不足，在CRD的cluster设置里改成更大容量的PVC，但没有效果。

包，且包含了大量没使用过的图标。进一步查询后发现其他人也有类似问题，按照推荐解法，将package版本回退到3.17.0后解决。解决：查询后得知这种请求是vite在加载package。但正常项目只会有少量加载，而这次情况绝大多数请求都来自。调试时，每次加载网页都要用超过半分钟的时间，另外用F12工具查看请求记录时，发现几百个chunk开头的请求。

表现：直接查询后端api可以正常出结果，但经前端服务器查询则之后403响应。在后端没能找到相应的错误log，且403响应无错误信息。推测是router问题，最后发现是router的AllowOrigins设置的url和前端url不匹配，修改后解决。