- Shipped
- 7 de agosto de 2026 às 07:48 UTC
- Author
- Kamo
- Commit
- e853649
A mesma falha que o modelo de incorporação, encontrado auditando cada volume hostPath no repo. A o hostPath é local do nó e nada o replica, de modo que pode ser agendado um pod os seus dados não são. Todos os quatro se moveram ou estavam em risco de se mover quando o k3m1 se juntou. pós-gres-analytics é o que importa: DirectoryOrCreate não falha em um caminho faltando, cria um vazio, e o postgres teria corrido initdb para ele. Uma remarcação não seria caiu -- teria servido análises um histórico de análise vazio enquanto o real 67MB ficou no k1m1. Verificado intacto após a fixação: 18 tabelas, 2655 eventos. qdrant é fixado ao k3m1 em vez de k1m1 porque é aí que estão os seus dados vivos. Mexeu-se. quando k3m1 se juntou, silenciosamente obteve uma loja fresca, e a coleção kb foi escrita lá uma vez que o & k1m1 ainda mantém um instantâneo de março, então enviar o pod "home" teria sido silenciosamente Serviu vetores de quatro meses de idade. Ele também muda para Recrear: qdrant detém uma WAL exclusiva lock, assim que um pod de pico que compartilha o diretório entra em pânico com `Não pode init WAL: WouldBlock` e o O lançamento nunca poderia terminar. Isso era latente. Qualquer inchaço de imagem teria atingido. bergamota e libretranslate apenas re-downloaded seus modelos no novo nó, por isso ninguém notou; o próprio comentário do libretranslate alegou que ambas as réplicas estavam no k1m1, e o pino torna isso verdadeiro novamente em vez de deixar 9.7GB duplicado no k3m1.