Eu atualizei todo o nosso mysql db de backend de 5.0 para 5.6, incluindo a alteração de algumas tabelas few para innodb, e não temos mais nada além de problemas com transações intermináveis desde então. Eu ainda tenho um servidor de teste que usa o 5.0 e posso confirmar que só obtemos transações interrompidas no novo servidor de banco de dados. Ambos os servidores estão sendo executados no modo tx_isolation = REPEATABLE-READ ( link
). Tenho certeza que todas as tabelas envolvidas são InnoDB para ambos os servidores.
Portanto, um exemplo simples do problema que estamos tendo é algum processo que envia e-mails de boas-vindas, que são executados como um filho de supervisord (não muito importante). No estágio env com o mysql 5.0, a conexão dura alguns minutos e não tem transações abertas:
From show full processlist:
1639945 dbuser <app-stage>:54536 db Sleep 246 NULL
InnoDB transaction logs:
<nothing>
O mesmo programa em nosso ambiente de produção com o mysql 5.6 e de repente o filho demoníaco que bloqueia tabelas realmente importantes e nunca as libera.
From show full processlist:
28674638 dbuser <app-prod>:54836 db Sleep 67131 NULL
Innodb transaction:
---TRANSACTION 90461789, ACTIVE 67062 sec
MySQL thread id 28674638, OS thread handle 0x7f8ab934f700, query id 758722407 <app-prod> dbuser cleaning up
Trx read view will not see trx with id >= 90461790, sees < 89033402
Quando não está causando problemas horríveis, a transação parece:
---TRANSACTION 111578756, not started
MySQL thread id 42149496, OS thread handle 0x7f8ac29b4700, query id 975441865 <app-prod> dbuser cleaning up
Alguém tem alguma sugestão? Eu meio que estou pensando em ativar o modo de transação de não-descomprometido, mas ... parece um patch para um problema diferente, e eu realmente preciso saber qual é o problema original!