Comparez les prix des domaines et des services informatiques des vendeurs du monde entier

Problèmes de transaction infinis après la mise à jour mysql 5.0-> 5.6

J'ai mis à jour notre serveur entier mysql db de 5.0 avant que 5.6, y compris le changement

quelques

table dans innodb, Et depuis lors, nous n'avions que des problèmes de transactions sans fin. J'ai toujours un serveur intermédiaire en utilisant 5.0, Et je peux confirmer que nous ne recevons que des transactions sur un nouveau serveur de base de données. Les deux serveurs fonctionnent en mode tx_isolation = REPEATABLE-READ (
http://dev.mysql.com/doc/refma ... .html
). Je suis presque confiant que toutes les tables impliquées - c'est InnoDB Pour les deux serveurs.

Donc, un exemple simple du problème avec lequel nous avons rencontré, - Ceci est une sorte de processus qui envoie des lettres de bienvenue, qui se lancent comme un élément enfant du superviseur (Pas très important). À l'étape env de mysql 5.0 La connexion dure quelques minutes et n'a pas de transactions open:

From show full processlist:
1639945 dbuser <app-stage>:54536 db Sleep 246 NULL

InnoDB transaction logs:
<nothing>

Exactement le même programme dans notre environnement de production avec mysql 5.6 Et un descendant soudain-démon, qui bloque des tables vraiment importantes et ne les libère jamais.

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 &gt;= 90461790, sees &lt; 89033402

Quand cela ne cause pas de problèmes terribles, la transaction ressemble à ceci:

---TRANSACTION 111578756, not started
MySQL thread id 42149496, OS thread handle 0x7f8ac29b4700, query id 975441865 <app-prod> dbuser cleaning up

Est-ce que quelqu'un a des suggestions? Je pense en quelque sorte à l'inclusion du mode de transaction de lecture sans fixation, mais ... Cela ressemble à une correction pour un autre problème et j'ai vraiment besoin de savoir quel est le problème initial!
</app-prod></app-prod></app-prod></nothing></app-stage>
Invité:

Babette

Confirmation de:

Donc je n'ai pas compris comment appeler le problème, mais il est en quelque sorte relié à de très grandes tables innodb Dans l'une de nos bases de données. Dans l'un d'eux était plus 303 Millions de lignes. Lorsque j'ai installé plusieurs scripts pour éliminer les anciennes données tous les soirs, le problème a disparu pour toujours. En fait, ce n'étaient pas des tables très importantes et, pour la plupart, ils n'ont enregistré que, mais n'ont généralement pas lu. Aussi tout le monde avait trop d'indices.

Dans tous les cas, si vous avez ce problème, essayez de réduire toutes vos tables jusqu'à 10-15 des millions d'enregistrements.

Pour répondre aux questions, connectez-vous ou registre