Amazon EC2, démarrage de mysql annulé car InnoDB: mmap (x bytes) a échoué; errno 12
J'ai configuré un serveur d'instance micro sur EC2 en fonction de ce que j'ai lu ici
le serveur mysql échoue fréquemment et pour la troisième fois, le serveur mysql est parti. Les journaux montre seulement
120423 09:13:38 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120423 09:14:27 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120423 9:14:27 [Note] Plugin 'FEDERATED' is disabled.
120423 9:14:27 InnoDB: The InnoDB memory heap is disabled
120423 9:14:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120423 9:14:27 InnoDB: Compressed tables use zlib 1.2.3
120423 9:14:27 InnoDB: Using Linux native AIO
120423 9:14:27 InnoDB: Initializing buffer pool, size = 512.0M
InnoDB: mmap(549453824 bytes) failed; errno 12
120423 9:14:27 InnoDB: Completed initialization of buffer pool
120423 9:14:27 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120423 9:14:27 [ERROR] Plugin 'InnoDB' init function returned error.
120423 9:14:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120423 9:14:27 [ERROR] Unknown/unsupported storage engine: InnoDB
120423 9:14:27 [ERROR] Aborting
Qu'est-ce que c'est vraiment failed; errno 12? Et comment pourrais-je donner plus d’espace/mémoire ou quoi que ce soit nécessaire pour le réparer?
Je résous ce problème à chaque fois en redémarrant tout le système, en supprimant tous les journaux et en redémarrant le serveur mysql. Mais je sais que quelque chose ne va pas avec ma configuration.
Aussi mon `mon.cnf 'est comme ci-dessous:
[mysqld]
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
# max_allowed_packet=500M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
innodb_buffer_pool_size = 512M
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
J'ai rencontré le même problème lorsque j'ai essayé d'exécuter WordPress sur mon micro-instance sans RDS.
L'ajout d'une page d'échange a résolu le problème pour moi.
Vous pouvez suivre ceci pour configurer la page d'échange:
http://www.prowebdev.us/2012/05/Amazon-ec2-linux-micro-swap-space.html
Si cela ne fonctionne toujours pas, envisagez d'utiliser le service RDS.
=============================================
Le lien vers le blog échoue parfois. J'ai copié le contenu ci-dessous pour l'enregistrement. Le mérite en revient à l'auteur du blog Pedram Moubed :
Espace d'échange Amazon Micro EC2 - Linux
J'ai une instance Amazon EC2 Linux Micro. Comme les instances Micro ne disposent que de 613 Mo de mémoire, MySQL se bloquait de temps en temps. Après une longue recherche sur MySQL, Micro Instance et Memory Managment, j'ai découvert qu'il n'y avait pas d'espace SWAP par défaut pour Micro instance. Donc, si vous voulez éviter le crash, vous devrez peut-être configurer un espace d'échange pour votre micro instance. En termes de performances, il est préférable d'activer l'échange.
Les étapes ci-dessous montrent comment créer un espace de swap pour votre instance Micro. Je suppose que vous avez un compte AWS avec une instance Micro en cours d'exécution.
- Exécuter
dd if=/dev/zero of=/swapfile bs=1M count=1024 - Exécuter
mkswap /swapfile - Exécuter
swapon /swapfile - Ajouter cette ligne
/swapfile swap swap defaults 0 0à/etc/fstab
L'étape 4 est nécessaire si vous souhaitez activer automatiquement le fichier d'échange après chaque redémarrage.
Quelques commandes utiles liées à l’espace SWAP:
$ swapon -s
$ free -k
$ swapoff -a
$ swapon -a
Références:
J'ai également eu ce problème sur une micro-instance Amazon EC2. J'ai essayé de réduire l'utilisation de la mémoire de inno_db en ajoutant ce qui suit à /etc/my.cnf
innodb_buffer_pool_size = 64M
Cela n'a pas fonctionné, j'ai essayé de le réduire à 16M et cela n'a toujours pas fonctionné. Ensuite, j'ai réalisé que l'instance n'avait pratiquement plus de mémoire libre. J'ai donc essayé de redémarrer Apache
Sudo system httpd restart Sudo system mysqld restart
Et tout a bien fonctionné. Une autre solution consiste peut-être à configurer Apache de manière à ne pas consommer autant de mémoire.
Il semble que vous demandiez 128M de mémoire pour innodb_buffer_pool_size dans le fichier my.cfg que vous affichez dans le message, mais MySQL pense que vous demandez 512M de mémoire:
Initialisation du pool de mémoire tampon, taille = 512.0M
Quelques lignes plus bas, le message d'erreur vous indique que MySQL ne démarrera pas car il ne peut pas réserver assez de mémoire (512 Mo) pour le pool de mémoire tampon InnoDB:
Erreur fatale: impossible d'allouer de la mémoire pour le pool de mémoire tampon
Cela soulève trois questions:
- Combien de mémoire est sur votre instance? Devrait-il y avoir assez de mémoire pour accueillir le 512M que InnoDB essaie de récupérer pour le pool de mémoire tampon, plus tout le reste alloué par MySQL, plus vos applications, plus le système d’exploitation?
- Pourquoi InnoDB essaie-t-il de prendre plus que vous ne le pensez?
- Pourquoi MySQL redémarre-t-il de toute façon?
Vous pouvez répondre à 1.
En ce qui concerne 2., il existe plusieurs emplacements différents. Les fichiers d'options de MySQL peuvent être situés. Les fichiers ultérieurement trouvés remplacent les options spécifiées dans les fichiers précédemment trouvés. Voir
http://dev.mysql.com/doc/refman/5.5/en/option-files.html
Le problème 3. peut être dû à une insuffisance de mémoire qui se produit après le démarrage. Vous devriez voir une indication de cela plus loin dans les journaux si c'est le cas.
Enfin, mais sans aucun lien entre vous, utilisez-vous des instances basées sur EBS? C'est généralement hautement recommandé pour les serveurs de base de données (en fait, pour toute instance sauf circonstances exceptionnelles). Pour plus sur cela voir
Pour moi, ce problème a été corrigé en ajoutant un volume de swap à mon instance EC2. Mes services consommaient simplement toute la mémoire de la boîte et se bloquaient. Ce n’est pas quelque chose que j’étais habitué, étant administrateur RedHat/CentOS depuis des années - Anaconda fait BEAUCOUP de travail que l’instance gratuite Ubuntu EC2 ne fait pas.
J'ai simplement créé un volume de 2 Go via la console Web, je l'ai attaché à mon instance et j'ai "mkswap/dev/[quel que soit]", j'ai modifié/etc/fstab et le plantage s'est arrêté.
Ces instances ne s'installent PAS comme un système d'exploitation basé sur un média auquel la plupart d'entre nous sommes habitués - elle est dépouillée sans paquet, sans système de fichiers approprié, et des choses comme AppArmor, qui causent toutes sortes de problèmes si vous ne le savez pas. et/ou ne savent pas comment le configurer.
RÉPONSE FACILE:
* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld
RÉPONSE DÉTAILLÉE:
C'est une question importante, en particulier pour les personnes qui utilisent un très petit VPS, disons 1 Go de RAM ou moins. Si MySQL abandonne, il se peut que la configuration de votre serveur (Apache | nginx) ou la configuration de MySQL pose problème. Les attaques DOS peuvent provoquer une augmentation du pic d'utilisation des ressources système (voir image). Le résultat final est que le processus MySQL est arrêté par le noyau. Pour une solution à long terme devrait envisager d'optimiser vos configurations Apache ou MySQL.
Il y a plusieurs autres discussions Stack Overflow sur ces sujets, ainsi que le manuel MySQL et le blog Percona:
Manuel MySQL - Comment MySQL utilise la mémoire:
https://dev.mysql.com/doc/refman/8.0/en/memory-use.html
Percona - Meilleures pratiques pour la configuration d'une utilisation optimale de la mémoire MySQL:
https://www.percona.com/blog/2016/05/03/best-practices-for-configuring-optimal-mysql-memory-usage/
Comment optimiser les performances de MySQL avec MySQLTuner:
https://www.linode.com/docs/databases/mysql/how-to-optimize-mysql-performance-using-mysqltuner/
Configuration d'utilisation de la mémoire Apache:
https://serverfault.com/questions/254436/Apache-memory-usage-optimization
Manuel Apache sur le réglage des performances:
https://httpd.Apache.org/docs/2.4/misc/perf-tuning.html
Réglage du serveur Apache:
https://www.linode.com/docs/web-servers/Apache-tips-and-tricks/tuning-your-Apache-server/
Cependant, en ce qui concerne votre question initiale, vous pouvez créer une solution temporaire qui vérifie si le service MySQL est chargé et actif, et relancera MySQL s'il n'est pas chargé et actif.
Vous n'avez pas mentionné le système d'exploitation que vous utilisez. Cela aiderait à vous donner une commande spécifique. Je vais vous donner un exemple pour CentOS Linux.
Regardez le résultat suivant de la commande systemctl status mysql. Vous pouvez voir en haut que le service est chargé et actif .
[root@centos-mysql-demo ~]# systemctl status mysqld
● mysqld.service - MySQL Server
Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2019-06-18 18:28:18 UTC; 924ms ago
Docs: man:mysqld(8)
http://dev.mysql.com/doc/refman/en/using-systemd.html
Process: 3350 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=0/SUCCESS)
Process: 3273 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
Main PID: 3353 (mysqld)
CGroup: /system.slice/mysqld.service
└─3353 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
Jun 18 18:28:11 centos-mysql-demo systemd[1]: Starting MySQL Server...
Jun 18 18:28:18 centos-mysql-demo systemd[1]: Started MySQL Server.
Si le service n'est pas chargé, une commande telle que:
systemctl status mysqld || systemctl restart mysqld
fera le tour de redémarrer le processus. Vous pourriez cron que:
* * * * * systemctl status mysqld || systemctl restart mysqld
Cependant, dans le cas où mysql est chargé , mais le service n'est pas actif , votre cron ne fera rien. Donc, vous devriez utiliser une commande plus détaillée telle que:
* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld
Dans ce cas, si le service est chargé mais inactif tel que le indiquer qu'une attaque DOS peut quitter votre service mysql, la commande redémarrera également mysql. L'utilisation de l'indicateur --quiet spécifie simplement la commande pour renvoyer un code d'état, sans rien afficher à l'écran. Si vous désactivez le drapeau --quiet, vous verrez une sortie d'état active ou inactive.
Vous pouvez également créer un espace d'échange pour ajouter davantage de ressources RAM disponibles à votre serveur, telles que:
Sudo dd if=/dev/zero of=/swapfile count=2096 bs=1MiB
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon --show
swapon --summary
free -h
Utilisez n'importe qui de la solution suivante:
Augmentez la RAM physique. Ajouter 1 Go de RAM supplémentaire résoudra le problème.
Allouez de l'espace SWAP en utilisant les modifications de configuration ci-dessous:
config
dd if=/dev/zero of=/extraswap bs=1024 count=512M
mkswap /extraswap
swapon /extraswap
## Edit the /etc/fstab, and the following entry.
/extraswap none swap sw 0 0
Le problème est que le serveur ne dispose pas de suffisamment de mémoire pour allouer le processus MySQL. Il existe quelques solutions à ce problème.
(1) Augmentez la RAM physique. Ajouter 1 Go de RAM supplémentaire résoudra le problème . (2) Allouez l’espace SWAP. L'instance Digital Ocean VPS n'est pas configurée pour utiliser l'espace de permutation par défaut. En allouant 512 Mo d’espace de swap, nous avons pu résoudre ce problème. Pour ajouter de l'espace d'échange sur votre serveur, procédez comme suit:
## As a root user, perform the following:
# dd if=/dev/zero of=/swap.dat bs=1024 count=512M
# mkswap /swap.dat
# swapon /swap.dat
## Edit the /etc/fstab, and the following entry.
/swap.dat none swap sw 0 0 Réduire la taille du pool de mémoire tampon MySQL
## Edit /etc/my.cnf, and add the following line under the [mysqld] heading.
[mysqld]
innodb_buffer_pool_size=64MVeuillez également vérifier votre espace disque. Assurez-vous d'avoir suffisamment d'espace.
df-h