MySql: Daily crashs pour les 3 dernières semaines sur le server robuste

Mon server MySQL qui exécute la dernière version de MySql sur Ubuntu 16.x continue de s'écraser une ou deux fois par jour. Parfois, il se répare assez rapidement (10 minutes). Parfois, je dois redémarrer et faire une fsck pour faire fonctionner les choses à nouveau.

Qu'est-ce qui causerait cela?

Les choses que j'ai essayé jusqu'à présent:

  • RAM accrue de 1,5 Go à 5 Go.
  • Mise à jour matérielle: MotherBoard, processeur, RAM (DDR4), mais cela n'a pas aidé (il fonctionnait avec un processeur de 7 ans, maintenant en cours d'exécution du 7ème Gén Core I5).
  • Configurer le pare-feu UFW pour s'assurer qu'il ne soit pas causé par des robots attaquant MySQL ou d'autres services.
  • Dans my.cnf, j'ai changé innodb_buffer_pool_size de 128 Mo à 500 Mo. n'a pas aidé mais toujours en place
  • J'ai exécuté: mysqlcheck -u root -p –auto-repair –optimize – toutes les bases de données plusieurs fois. n'a pas aidé
  • Dans my.cnf, Discreased mysql max_connections de 151 à 80 et redémarré mysql. n'a pas aidé
  • Diminué les MaxRequestWorkers d'apaches de 150 à 100. N'a pas aidé. Toujours en panne.
  • J'avais déjà un file Swap de 1 Go. Je l'ai laissé.
  • Scoured à travers les journaux Apache2, SysLog, tout autre journal qui semblait approprié, mais n'a trouvé rien qui a attiré mon attention.
  • Arrêtez le server et essayez de déplacer la machine virtuelle sur un autre lecteur mais échoue avec l'erreur de file.
  • Ma dernière suspicion est que cela est causé par un mauvais bloc, mais l'exécution de badblocks semble triggersr un crash à 25%. Au cours de la fsck, je vois ceci: fsck critical medium error, dev sda, secteur 147306432

Voici un journal d'erreur mysql typique:

2017-04-20T18: 43: 46.958430Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 11791 ms. Les parameters peuvent ne pas être optimale. (abri de la grippe = 92 et expulsé = 0, pendant le time).
2017-04-20T18: 44: 11.989905Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 6822 msnm. Les parameters peuvent ne pas être optimale. (rincé = 8 et expulsé = 0, pendant le time).
2017-04-20T18: 44: 49.145162Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 5021 ms. Les parameters peuvent ne pas être optimale. (flus hed = 0 et expulsé = 0, pendant le time).
2017-04-20T18: 45: 22.322429Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 26338ms. Les parameters peuvent ne pas être optimale. (abri de la grippe = 10 et expulsé = 0, pendant le time).
2017-04-20T18: 45: 53.926808Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 4510 ms. Les parameters peuvent ne pas être optimale. (flus hed = 0 et expulsé = 0, pendant le time).
2017-04-20T18: 46: 03.097400Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 5384 ms. Les parameters peuvent ne pas être optimale. (flus hed = 13 et expulsé = 0, pendant le time).
2017-04-20T18: 46: 39.247467Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 14848 msms. Les parameters peuvent ne pas être optimale. (abri de la grippe = 8 et expulsé = 0, pendant le time).
2017-04-20T18: 47: 16.271672Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 29107 ms. Les parameters peuvent ne pas être optimale. (abri de la grippe = 8 et expulsé = 0, pendant le time).
2017-04-20T18: 47: 53.669557Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 5969 ms. Les parameters peuvent ne pas être optimale. (flus hed = 37 et expulsé = 0, pendant le time).
2017-04-20T18: 50: 23.879411Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 37671 ms. Les parameters peuvent ne pas être optimale. (réservoir de grippe = 6 et expulsé = 0, pendant le time).
2017-04-20T18: 55: 07.190725Z 0 [Avertissement] Limites modifiées: max_open_files: 1024 (demandé 5000) 2017-04-20T18: 55: 07.235759Z 0 [Avertissement] Limites modifiées: table_open_cache: 431 (demandé 2000)
2017-04-20T18: 55: 10.486670Z 0 [Avertissement] TIMESTAMP avec valeur implicite de DEFAULT est obsolète. Utilisez l'option –explicit_defaults_for_times tam server (voir la documentation pour plus de détails).
2017-04-20T18: 55: 11.563578Z 0 [Note] / usr / sbin / mysqld (mysqld 5.7.17-0ubuntu0.16.04.2) commençant comme process 24701 …
2017-04-20T18: 55: 21.979225Z 0 [Note] InnoDB: support PUNCH HOLE disponible
2017-04-20T18: 55: 21.979250Z 0 [Note] InnoDB: Mutexes et rw_locks utilisent des installations atomiques GCC
2017-04-20T18: 55: 21.979253Z 0 [Note] InnoDB: utilise les mutex des events 2017-04-20T18: 55: 21.979256Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence () est utilisé pour la barrière de la memory
2017-04-20T18: 55: 21.979259Z 0 [Note] InnoDB: tables compressées utilisent zlib 1.2.8
2017-04-20T18: 55: 21.979262Z 0 [Note] InnoDB: Utilisation de Linux native AIO 2017-04-20T18: 55: 22.004800Z 0 [Note] InnoDB: Nombre de piscines: 1
2017-04-20T18: 55: 22.060762Z 0 [Note] InnoDB: Utilisation des instructions CPU crc32
2017-04-20T18: 55: 22.104584Z 0 [Note] InnoDB: Initialisation du pool de tampons, taille totale = 128M, instances = 1, taille du morceau = 128M
2017-04-20T18: 55: 24.184701Z 0 [Note] InnoDB: initialisation terminée du pool tampon
2017-04-20T18: 55: 24.210160Z 0 [Note] InnoDB: Si l'user d'exécution mysqld est autorisé, la priorité du thread de nettoyage des pages peut être modifiée. Voir la page man de setpriority ().
2017-04-20T18: 55: 26.405242Z 0 [Note] InnoDB: Le format de file le plus élevé est Barracuda.
2017-04-20T18: 55: 27.508456Z 0 [Note] InnoDB: L'parsing de journal a progressé après le sharepoint contrôle lsn 35288448161
2017-04-20T18: 55: 27.508478Z 0 [Note] InnoDB: Rétablissement: numérisé pour save le numéro de séquence 35288448170
2017-04-20T18: 55: 27.508630Z 0 [Note] InnoDB: Rétablissement: numérisé vers le numéro de séquence de journal 35288448170
2017-04-20T18: 55: 27.508634Z 0 [Note] InnoDB: La database n'a pas été désactivée normalement.
2017-04-20T18: 55: 27.508637Z 0 [Note] InnoDB: Démarrage de la récupération des pannes.
2017-04-20T18: 56: 16.516761Z 0 [Note] InnoDB: file de données de tablespace temporaire supprimé: "ibtmp1"
2017-04-20T18: 56: 16.516785Z 0 [Note] InnoDB: création d'espace de tables partagé pour les arrays temporaires
2017-04-20T18: 56: 16.516817Z 0 [Note] InnoDB: Définition de la taille du file './ibtmp1' à 12 Mo. Écrivant physiquement le file complet; S'il vous plaît, attendez …
2017-04-20T18: 56: 16.621736Z 0 [Note] InnoDB: La taille du file './ibtmp1' est maintenant de 12 Mo.
2017-04-20T18: 56: 16.622203Z 0 [Note] InnoDB: 96 segments de retrait redo ont été trouvés. 96 segments de retrait d'effacement sont actifs.
2017-04-20T18: 56: 16.622211Z 0 [Note] InnoDB: 32 segment (s) de retrait sans refaire sont actifs.
2017-04-20T18: 56: 16.622565Z 0 [Note] InnoDB: en attente de purge pour commencer
2017-04-20T18: 56: 16.672708Z 0 [Note] InnoDB: 5.7.17 commencé; Numéro de séquence journal 35288448170
2017-04-20T18: 56: 16.672708Z 0 [Note] InnoDB: page_cleaner: la boucle intentionnelle de 1000 ms a pris 52462 msm. Les parameters peuvent ne pas être optimale. (rejeté = 0 et expulsé = 0, pendant le time).
2017-04-20T18: 56: 16.673192Z 0 [Note] InnoDB: Chargement du (s) groupe (s) de tampon de / var / lib / mysql / ib_buffer_pool
2017-04-20T18: 56: 16.702959Z 0 [Note] Le plugin 'FEDERATED' est désactivé.
2017-04-20T18: 56: 16.851553Z 0 [ERREUR] La fonction 'archive' existe déjà
2017-04-20T18: 56: 16.851568Z 0 [Avertissement] Impossible de charger le plugin nommé 'archive' avec soname 'ha_archive.so'.
2017-04-20T18: 56: 16.851574Z 0 [ERROR] La fonction 'blackhole' existe déjà
2017-04-20T18: 56: 16.851575Z 0 [Avertissement] Impossible de charger le plugin appelé 'blackhole' avec soname 'ha_blackhole.so'.
2017-04-20T18: 56: 16.851578Z 0 [ERREUR] La fonction 'fédérée' sort déjà 2017-04-20T18: 56: 16.851579Z 0 [Avertissement] Impossible de charger le plugin nommé 'fédéré' avec soname 'ha_federated.so' .
2017-04-20T18: 56: 16.851582Z 0 [ERREUR] Fonction 'innodb' existe déjà 2017-04-20T18: 56: 16.851583Z 0 [Avertissement] Impossible de charger le plugin nommé 'innodb' avec soname 'ha_innodb.so' .
2017-04-20T18: 56: 17.044733Z 0 [Avertissement] Impossible de configurer SSL en raison de l'erreur suivante de la bibliothèque SSL: le context SSL n'est pas utilisable sans certificate et key privée
2017-04-20T18: 56: 17.044754Z 0 [Remarque] Nom d'hôte du server (binding-adresse): '0.0.0.0'; port: 3306
2017-04-20T18: 56: 17.044761Z 0 [Note] – '0.0.0.0' décide de '0.0.0.0';
2017-04-20T18: 56: 17.044779Z 0 [Remarque] Prise de server créée sur IP: '0.0.0.0'. 2017-04-20T18: 56: 18.483575Z 0 [Note] Event Scheduler: Loaded 0 events
2017-04-20T18: 56: 18.483706Z 0 [Note] Exécutant 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' pour get une list de tables utilisant le moteur de partition obsolète. Vous pouvez utiliser l'option de démarrage '–disable-partition-engine-check' pour ignorer cette vérification.
2017-04-20T18: 56: 18.483716Z 0 [Note] Début de la list des tables partiellement non partitionnées
2017-04-20T18: 56: 25.478293Z 0 [Note] InnoDB: Réservoir (s) chargé (s) charge terminé à 170420 13:56:25
2017-04-20T18: 56: 26.091240Z 0 [Note] Fin de la list des tables partiellement non partitionnées
2017-04-20T18: 56: 26.091423Z 0 [Note] / usr / sbin / mysqld: prêt pour les connections. Version: '5.7.17-0ubuntu0.16.04.2' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
2017-04-20T18: 56: 26.155810Z 4 [ERREUR] / usr / sbin / mysqld: La table './example/wp_options' est marquée comme écrasée et devrait être réparée
2017-04-20T18: 56: 26.155889Z 5 [ERREUR] / usr / sbin / mysqld: La table './example/wp_options' est marquée comme écrasée et devrait être réparée
2017-04-20T18: 56: 26.156037Z 4 [Avertissement] Tableau de vérification: './ example / wp_options'
2017-04-20T18: 56: 35.816730Z 4 [ERREUR] / usr / sbin / mysqld: la table './example/wp_usermeta' est marquée comme écrasée et doit être réparée
2017-04-20T18: 56: 35.816875Z 4 [Avertissement] Tableau de vérification: './example/wp_usermeta'

Les deux derniers points indiquent le problème. Vos méchants blocs semblent bien fondés.

  • Erreur de file lors de la tentative de déplacement de la VM
  • Les badblocks s'écrasent à peu près au même endroit à chaque fois.

Pendant que le server fonctionne, vidagez les bases de données sur un file sur le operating system hôte. Étant donné que le server se bloque et que vous ne savez pas exactement quel table, database ou enregistrez qu'il accède quand il descend, prenez le time de décharger chaque database, peut-être même chaque table, séparément. J'espère que les mauvais blocs ne se produisent pas dans vos données, mais dans certains files, le système essaie d'utiliser. Dans tous les cas, si l'une des décharges triggers un accident, deux fois si vous voulez vérifier, alors considérez que le tableau ou la database est suspect et révisez-le à la main autant que vous le pouvez.

Ensuite, créez une nouvelle VM, sur un disque physique différent , avec toutes les installations nécessaires. Importez datatables déchargées, y compris la version inspectée de toute donnée suspectée. Sur toutes les tables, des vérifications de santé mentale au hasard avec datatables, en particulier pour les tables construites à partir de décharges suspectes. Ensuite, faites le niveau de test que vous jugez approprié pour s'assurer que la nouvelle VM et la database fonctionnent correctement et qu'elles ont des données valides.

Faites de la nouvelle VM le server "en direct", retirez l'ancienne machine virtuelle et commencez la sauvegarde / récupération pour le rest du lecteur physique qui détenait la VM du server qui s'écroule. Une fois que vous avez récupéré toutes datatables de ce disque, ou toutes datatables disponibles, vous pouvez déterminer sa santé (suspect) et si vous souhaitez ou non faire confiance à cette utilisation pour des données importantes. Peut-être que cela peut être utilisé comme un lieu pour placer votre /tmp , ou d'autres structures transitoires, ou comme espace de swap, libérant de l'espace sur un autre, vraisemblablement bon, pour des données importantes.