Nous gérons un grand forum avec beaucoup de lectures et d'écritures, en particulier dans la section posts y topics qui sont toutes deux innodb.
La semaine dernière, j'ai commencé à faire des sauvegardes 12 fois par heure avec innobackupex parce que mysqldump prend une éternité (7+ millions de lignes dans posts table). Il semble que quelque chose n'aime pas ces sauvegardes car j'ai un problème récurrent tous les deux jours.
Les symptômes ;
La page d'accueil du site commence à afficher des erreurs.
Les journaux commencent à montrer des erreurs comme Error: 126 - Incorrect key file for table '/tmp/mysql/#sql_4e87_14.MYI'; try to repair it
Le répertoire /tmp/ se remplit et nous commençons à avoir Error: 1030 - Got error 28 from storage engine dans les journaux.
La seule façon de réparer est de optimize table sur chacun des tableaux des postes et des sujets.
Je fais tout ce que je peux pour empêcher MySQL d'utiliser les disques pour les tables temporaires, mais j'aurais plus de problèmes que cela s'il utilisait aussi toute ma mémoire.
Mon my.cnf est ici ; https://gist.github.com/cbiggins/0aa26f6defb7a14541d7
La boîte a 32 Go de mémoire et je ne m'en approche pas habituellement. Actuellement, j'utilise 15 Go.
Merci d'avance.
Mise à jour 1 : Malgré le fait que la conf ressemble à une réplication, il n'y en a pas. Il s'agit d'une instance autonome.
Mise à jour 2 : N'ayant pas effectué de sauvegardes depuis plus de 24 heures, le problème vient de se reproduire. Ce n'est donc pas le résultat des sauvegardes.
Mise à jour 3 : J'ai donné à MySQL 20 Go d'espace temporaire en utilisant tmpfs. Instructions ici . Je vais regarder pendant un petit moment et voir comment ça se passe.
Mise à jour 4 : J'ai trouvé une requête qui tue ! 13 secondes et 2,3 millions de lignes examinées. Faites-le 20 fois simultanément et je remplissais mon nouveau répertoire temporaire de 20 Go assez rapidement. J'ai désactivé le bloc qui utilisait cette requête et a fourni quelques informations au mainteneur.
J'ai décidé d'avoir un serveur dédié super bon marché pour répliquer et faire des sauvegardes. J'espère voir mon temps de fonctionnement grimper à nouveau :)
2 votes
Vous ne devez pas effectuer vos sauvegardes sur le serveur primaire. Créez un esclave. Vous pourrez ainsi interrompre périodiquement la réplication pour effectuer une sauvegarde. Ainsi, les performances et/ou l'intégrité de vos données de base ne seront jamais affectées par votre routine de sauvegarde.
0 votes
Je comprends cela, mais il n'y a pas de réplication. J'ai mis à jour la question.
0 votes
Je comprends cela. Avec un site de cette taille, no Avoir un esclave est une folie, pour de nombreuses raisons autres que la possibilité de sauvegarder les choses correctement.
0 votes
Je vois, je suis d'accord avec cela. J'ai toujours été préoccupé par l'intégrité d'une sauvegarde à partir d'un esclave en raison de la réplication MySQL qui est parfois délicate.
0 votes
La réplication MySQL, lorsqu'elle est configurée correctement et qu'une surveillance est en place, n'est pas moins délicate que les autres SGBD. De nombreux outils sont disponibles pour aider à gérer et à assurer une réplication correcte. Mais ce n'est pas le sujet de cette question.
0 votes
Ok, c'est logique. Pouvez-vous m'éclairer sur ce qui se passe pendant mes sauvegardes et qui est à l'origine de ce problème ?
1 votes
L'exécution de sous-requêtes peut générer des index pour un traitement plus rapide et ceux-ci sont susceptibles de se retrouver dans /tmp/. La sauvegarde peut remplir /tmp/, ce qui entraîne la corruption de ces index ou leur génération incomplète.