Problema de reincidência com chaves em tabelas temporárias

1

Nós executamos um grande fórum com muitas leituras e escritas, particularmente para as tabelas posts e topics que são ambas innodb.

Na semana passada eu comecei a fazer 12 backups de hora em hora com o innobackupex porque o mysqldump leva uma eternidade (mais de 7 milhões de linhas em posts table). Parece que alguma coisa não gosta desses backups porque eu tenho um problema recorrente a cada dois dias.

Os sintomas;

A primeira página do site começa a gerar erros | Os logs começam a mostrar erros como Error: 126 - Incorrect key file for table '/tmp/mysql/#sql_4e87_14.MYI'; try to repair it
O diretório / tmp / dir é preenchido e começamos a receber Error: 1030 - Got error 28 from storage engine nos registros.

A única maneira de corrigir é optimize table em cada uma das postagens e tabelas de tópicos.

Estou tentando tudo o que posso para parar o MySQL usando discos para tabelas temporárias, mas eu teria mais problemas do que isso se ele usasse toda a minha memória também.

Meu my.cnf está aqui; link

A caixa tem 32GB de memória e não me aproximo disso normalmente. Atualmente com 15 GB de uso.

Obrigado antecipadamente.

Atualização 1: Apesar da conf parecer que há replicação, não existe. Esta é uma instância independente.

Atualização 2: Não tendo feito backups por mais de 24 horas, o problema acaba de ocorrer novamente. Portanto, este não é o resultado dos backups.

Atualização 3: Eu dei ao MySQL 20gb de espaço temporário agora usando tmpfs. Instruções aqui . Indo para assistir o próximo pequeno momento e ver como vai ser.

Atualização 4: encontrei uma consulta matadora! 13 segundos e 2,3 milhões de linhas examinadas. Faça isso 20 vezes ao mesmo tempo e eu estava preenchendo meu novo dir de 20GB rapidamente. Desativei o bloco que estava usando essa consulta e forneceu alguns comentários ao mantenedor.

Eu decidi obter um servidor dedicado super barato para replicar para executar backups de. Espero que possamos ver o meu uptime subir novamente. :)

    
por Christian 13.06.2014 / 03:21

1 resposta

2

O problema é o / tmp / filling e o MySQL colocando alguns arquivos lá.

Uma das escolhas que o MySQL pode fazer ao lidar com uma subconsulta:

Ref: MySQL 5.6 - Otimização da subconsulta

Materialize the subquery into a temporary table with an index and use the temporary table to perform a join. The index is used to remove duplicates. The index might also be used later for lookups when joining the temporary table with the outer tables; if not, the table is scanned.

Você pode desativar isso (subquery_materialization_cost_based) e usar uma estratégia diferente.

Ref: MySQL 5.6 - Controle de otimizações comutáveis

A outra opção é evitar que o / tmp / preencha adicionando mais espaço ou tendo o MySQL colocado seus arquivos temporários em outro lugar.

    
por 13.06.2014 / 04:24