Alguém pode me aconselhar qual poderia ser a causa dessa condição?
Eu tenho um cluster Rook Ceph no qual o banco de dados MySQL com replicação 3x está armazenado. Esse banco de dados também é usado por mim para desenvolvimento, ou seja, muitos dados são excluídos, alterados e assim por diante.
BinaryLogs também estão habilitados.
No total, o banco de dados ocupa 27 GB, dos quais 22 a 24 são BinaryLogs. Posso desabilitar BinaryLogs, mas 20 gigabytes não desempenham um papel importante, eles são apagados a cada 3 dias.
Vejo o mesmo tamanho (27 GB) se observar o tamanho do contêiner/host (df -h).
Mas Rook Ceph define esta imagem de bloco como 241 GB.
E não consigo entender por que esse tamanho de Block Image é tão grande se deveria ser 9 vezes menor?
Idéias, dicas? O que posso tentar ou em que direção olhar para entender qual é o motivo.
Não estou familiarizado com o Ceph, mas acho que há confusão aqui sobre o que você está medindo. Você descreveu o tamanho de três perspectivas diferentes, mas não forneceu o método explícito (linha de comando) usado para obter o tamanho.
Embora o Ceph possa armazenar arquivos individuais, executar um banco de dados MySQL por meio dessa interface seria bastante estranho - acho que o armazenamento é provisionado em um dispositivo de bloco do Ceph. Neste cenário, há um limite superior fixo para o tamanho definido no momento do provisionamento e configurado no sistema de arquivos criado no volume. A maioria (todos?) dos provedores de armazenamento implementará o provisionamento dinâmico - a área ocupada pelo volume no armazenamento são apenas os blocos nos quais foram gravados no ciclo de vida dos volumes. O Ceph faz isso por padrão. ou seja, contanto que você adicione apenas dados, a área ocupada refletirá o tamanho dos arquivos armazenados no sistema de arquivos.
No entanto, o provedor de armazenamento não entende os sistemas de arquivos - ele não sabe quando um arquivo é removido do sistema de arquivos, portanto, os blocos de armazenamento subjacente permanecem alocados quando o arquivo é excluído. O host que usa o armazenamento precisa informar ao Ceph quando os blocos não estão mais em uso. Ele só faz isso se o sistema de arquivos estiver montado com a opção de descarte ou quando um comando fstrim explícito for executado.
Uma consideração adicional é que seu armazenamento deve ser configurado com redundância – ou seja, a capacidade de continuar a fornecer o serviço quando um nó falhar. Não é incomum que um cluster ceph tenha 3 (às vezes até mais) cópias de cada bloco de dados. Seu método pode estar relatando o espaço usado no armazenamento físico, em vez da área ocupada lógica.
Muito obrigado pela sua resposta.
Acho que você me deu exatamente o que eu procurava.
Sim, estamos falando do CephBlockStorage.
Presumi que, no meu caso, o Ceph adiciona de forma incremental, mas não exclui. Eu simplesmente não conseguia explicar essas diferenças de tamanho de outra maneira.
Eu simplesmente não sabia como e o que procurar.
Em relação às 3 cópias, indiquei corretamente. Já 3 cópias ocupam 720GB respectivamente e isso é mostrado no cluster.
Então, 2 palavras-chave que apontaram o caminho: “ descarte ” e “ fstrim ”
Sobre o descarte também está descrito na documentação do StorageClass https://kubernetes.io/docs/concepts/storage/storage-classes/#storageclass-objects https://docs.ceph.com/en/latest/rbd/rbd-kubernetes /#criar uma classe de armazenamento
Mas esta solução não é a ideal e pode haver problemas de desempenho.
Para este propósito, Rook Ceph sugere o uso de complementos especiais que farão esse trabalho regularmente.
Aqui está um problema idêntico: https://github.com/rook/rook/issues/10391
E aqui estão as soluções: https://rook.io/docs/rook/v1.14/Storage-Configuration/Ceph-CSI/ceph-csi-drivers/#csi-addons-operations
Acho que a questão está resolvida, pois já entendi o que preciso configurar e assim por diante. Se funcionará corretamente ou não, é outra questão. Mas deveria funcionar.
A discrepância entre o tamanho do banco de dados MySQL de 27 GB e o tamanho da imagem de bloco de 241 GB em seu cluster Rook Ceph provavelmente decorre de como o Ceph gerencia o armazenamento. O Ceph emprega provisionamento dinâmico, onde o armazenamento alocado pode parecer maior do que os dados reais armazenados. Além disso, fatores como redundância de dados, reservas de snapshots e sobrecarga de metadados contribuem para o tamanho da imagem do bloco. Para solucionar problemas, revise as definições de configuração do Ceph, monitore o uso do armazenamento com ferramentas como ceph df e entenda como o provisionamento dinâmico afeta a alocação de armazenamento. Ajustar as configurações e as práticas de monitoramento pode ajudar a otimizar a eficiência do armazenamento em sua configuração.