meh's questions

Recentemente, tive uma falha no mariadb que deu início a um pesadelo. Quando restaurei dumps, às vezes o daemon travava durante inserções em massa. Isso aconteceu apenas nas poucas tabelas "grandes" do innodb (tenho muitos bancos de dados pequenos que realmente não contêm muitos dados e a maioria dos outros possui uma quantidade significativa apenas em algumas tabelas). O banco de dados geralmente se recuperava eventualmente (às vezes depois de horas), mas às vezes travava. Restaurei o banco de dados em uma máquina diferente sem problemas em questão de minutos e depois movi o diretório de dados na máquina de produção. A única diferença séria entre os dois é que a máquina de sucesso não é uma VM e sim um armazenamento SSD esportivo.

Desde então, os problemas descritos ainda acontecem, em momentos aleatórios, sempre ao acessar aquelas tabelas grandes. Geralmente terei várias consultas congeladas, mas apenas uma às vezes é suficiente para acionar o comportamento.

O que acho realmente difícil de acreditar é o fato de que o iotop relata um thread mariadb gravando gigabytes por segundo , de forma constante, durante todo o tempo em que a consulta trava. Isso é fisicamente impossível, já que o desempenho dos discos não chega nem perto desses números. Também vasculhei a internet para encontrar o que pude sobre como otimizar configurações que até alguns dias atrás pareciam perfeitamente adequadas para o meu ambiente, ajustei algumas variáveis, mas nada importante, também os padrões na máquina "importação bem-sucedida" não eram muito diferentes começar com.

O problema é semelhante a https://jira.mariadb.org/browse/MDEV-30884 , no entanto, isso foi supostamente corrigido porque estou usando o 10.6.14 (também testei o 10.6.15) no Gentoo.

Estou perplexo, o que poderia estar causando isso? O armazenamento mecânico do HDD pode de alguma forma justificar o que está acontecendo?

Um pouco de contexto: estou testando o flowable, no entanto, o tomcat engasga em um certo ponto ao preencher o banco de dados, a parede de exceção usual de texto se resume ao título deste post. A primeira vez que coloco minhas mãos no tomcat em muito tempo, posso estar perdendo o óbvio.

Atualização: esta consulta agora funciona.

CREATE TABLE flowable.FLW_EVENT_DEPLOYMENT (
ID_ VARCHAR(255) NOT NULL,
NAME_ VARCHAR(255) NULL,
CATEGORY_ VARCHAR(255) NULL,
DEPLOY_TIME_ datetime(3) NULL,
TENANT_ID_ VARCHAR(255) NULL,
PARENT_DEPLOYMENT_ID_ VARCHAR(255) NULL,
CONSTRAINT PK_FLW_EVENT_DEPLOYMENT PRIMARY KEY (ID_)
)

O que eu fiz: mudei de utf8mb4 para utf8 simples graças a este bit "Eu sei que UTF8mb4 só pode suportar até VARCHAR (191)" (obrigado @Lennart por me fazer pensar mais sobre isso). Portanto, há progresso, mas tenho o mesmo erro posteriormente em outra consulta:

CREATE UNIQUE INDEX ACT_IDX_EVENT_DEF_UNIQ ON flowable.FLW_EVENT_DEFINITION(KEY_, VERSION_, TENANT_ID_)

Essas três colunas são respectivamente varchar(255) utf8_general_ci, int(11), varchar(255) utf8_general_ci.

tomcat 8.5.61

mariadb 10.4.17

Encontrei várias soluções sugeridas, mas nenhuma parece se aplicar à minha versão do mariadb, innodb-large-prefix=ONem particular foi preterida, tentei alguns agrupamentos diferentes sem sucesso. Já gastei bastante tempo com isso, tentei trocar o conector mariadb pelo conector mysql também para descartar um bug na própria biblioteca.

Por exemplo, tentei a solução aceita aqui sem sucesso, provavelmente porque:

• innodb_file_format está obsoleto e não tem efeito. Ele pode ser removido em versões futuras.
• innodb_file_format_max surpreendentemente causa um erro na verificação de configuração, o Antelope está obsoleto de qualquer maneira e o mariadb não o usaria para uma nova tabela
• innodb_large_prefix foi removido em 10.3.1 e restaurado como uma variável obsoleta e não utilizada em 10.4.3 para fins de compatibilidade.