it-swarm.com.de

Amazon EC2, Abbruch von MySQL, da InnoDB: mmap (x Byte) fehlgeschlagen ist; Errno 12

Ich habe einen micro -Instanzserver auf EC2 eingerichtet, basierend auf dem, was ich hier gelesen habe hier

mySQL-Server fällt häufig aus und zum dritten Mal ist MySQL-Server nicht mehr vorhanden. Die Protokolle werden nur angezeigt 

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

Was ist wirklich failed; errno 12? Und wie könnte ich mehr Speicherplatz/Speicher geben oder was auch immer nötig ist, um das Problem zu beheben? 

Ich behebe dies jedes Mal, indem ich das gesamte System neu starte und alle Protokolle lösche und den Mysql-Server neu starte. Aber ich weiß, dass mit meiner Konfiguration etwas nicht stimmt.

Auch meine `my.cnf 'ist wie folgt: 

[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
88
PMoubed

Das gleiche Problem traf ich, als ich versuchte, WordPress auf meiner Mikroinstanz ohne RDS auszuführen. 

Das Hinzufügen einer Swap-Seite löste das Problem für mich. 

Sie können diesem Schritt folgen, um die Auslagerungsseite einzurichten: 

http://www.prowebdev.us/2012/05/Amazon-ec2-linux-micro-swap-space.html

Wenn es für Sie immer noch nicht funktioniert, sollten Sie den RDS-Dienst verwenden.

===============================================

Der Link zum Blog schlägt manchmal fehl. Ich habe den folgenden Inhalt für die Aufzeichnung kopiert. Dank geht an den Blog-Autor Pedram Moubed :

Amazon EC2 Micro Instance Swap Space - Linux

Ich habe eine Amazon EC2 Linux Micro-Instanz. Da Micro-Instanzen nur 613 MB Arbeitsspeicher haben, stürzte MySQL hin und wieder ab. Nach einer langen Suche nach MySQL, Micro Instance und Memory Managment stellte ich fest, dass es keinen Standard-SWAP-Bereich für die Micro-Instanz gibt. Wenn Sie den Absturz vermeiden möchten, müssen Sie möglicherweise einen Auslagerungsbereich für Ihre Mikroinstanz einrichten. Tatsächlich ist es aus Performancegründen besser, Swap zu aktivieren.

Die folgenden Schritte zeigen, wie Sie einen Auslagerungsbereich für Ihre Micro-Instanz erstellen. Ich gehe davon aus, dass Sie über ein AWS-Konto mit einer Micro-Instanz verfügen.

  1. dd if=/dev/zero of=/swapfile bs=1M count=1024 ausführen
  2. mkswap /swapfile ausführen
  3. swapon /swapfile ausführen
  4. Fügen Sie diese Zeile /swapfile swap swap defaults 0 0 zu /etc/fstab hinzu.

Schritt 4 ist erforderlich, wenn Sie die Auslagerungsdatei nach jedem Neustart automatisch aktivieren möchten. 

Einige nützliche Befehle im Zusammenhang mit dem SWAP-Bereich:

$ swapon -s   
$ free -k

$ swapoff -a
$ swapon  -a

Verweise:

  1. http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
  2. http://cloudstory.in/2012/02/getting-the-best-out-of-Amazon-ec2-micro-instances/
  3. http://cloudstory.in/2012/02/adding-swap-space-nach-Amazon-ec2-linux-micro-instance-auf-aufstiegsleistung/
  4. http://aws.Amazon.com/ec2/instance-types/
158
Bohr

Ich hatte dieses Problem auch auf einer Amazon EC2-Mikroinstanz. Ich habe versucht, den Speicherbedarf von inno_db zu verringern, indem ich Folgendes zu /etc/my.cnf hinzufügte:

 innodb_buffer_pool_size = 64M 

Das hat nicht funktioniert, ich habe es auf 16M heruntergefahren und es hat immer noch nicht funktioniert. Dann wurde mir klar, dass die Instanz praktisch keinen freien Speicher hatte. Also habe ich versucht, Apache neu zu starten

 Sudo-System httpd restart 
 Sudo-System mysqld restart 

Und alles hat gut funktioniert. Eine andere Lösung besteht darin, Apache so zu konfigurieren, dass nicht so viel Speicher verbraucht wird.

23
wfbarksdale

Es sieht so aus, als würden Sie 128M des Speichers für die innodb_buffer_pool_size in der my.cfg-Datei anfordern, die Sie im Beitrag anzeigen, aber MySQL meint, Sie fragen nach 512M des Speichers:

Pufferpool wird initialisiert, Größe = 512.0M

Ein paar Zeilen weiter gibt die Fehlermeldung an, dass MySQL nicht startet, da nicht genügend Speicherplatz (512 MB) für den InnoDB-Pufferpool reserviert werden kann:

Schwerwiegender Fehler: Es kann kein Speicher für den Pufferpool zugewiesen werden

Das wirft drei Fragen auf:

  1. Wie viel Speicher ist in Ihrer Instanz? Sollte genügend Speicherplatz für 512 MB zur Verfügung stehen, den InnoDB für den Pufferpool und alles andere, was MySQL zuweist, plus Ihre Anwendungen und das Betriebssystem ergreift?
  2. Warum versucht InnoDB mehr zu nehmen, als Sie denken?
  3. Warum startet MySQL trotzdem neu? 

Sie können 1 beantworten. 

In Punkt 2. gibt es einige verschiedene Orte, an denen sich MySQL-Optionsdateien befinden können. Anschließend werden die in den zuvor gefundenen Dateien angegebenen Optionen überschrieben. Sehen 

http://dev.mysql.com/doc/refman/5.5/de/option-files.html

Problem 3 könnte auf einen Speicherplatz zurückzuführen sein, der irgendwann nach dem Start auftritt. In den Protokollen sollten Sie einen Hinweis darauf finden, falls dies der Fall ist.

Schließlich, wenn auch ohne Zusammenhang, verwenden Sie EBS-gestützte Instanzen? Dies wird generell für Datenbankserver empfohlen (eigentlich für alle Fälle, in denen besondere Umstände ausgeschlossen sind). Für mehr darüber

https://stackoverflow.com/a/3630707/141172

4
Eric J.

Dieses Problem wurde für mich durch Hinzufügen eines Swap-Volumes zu meiner EC2-Instanz behoben. Meine Dienste verbrauchten einfach den gesamten Speicher der Box und würden abstürzen. Ich war es nicht gewohnt, seit Jahren RedHat/CentOS-Administrator zu sein - Anaconda hat eine Menge Arbeit zu leisten, die die kostenlose Ubuntu EC2-Instanz nicht tut.

Ich habe einfach ein 2-GB-Volume über die Webkonsole erstellt, an meine Instanz angehängt und "mkswap/dev/[what]]" bearbeitet,/etc/fstab bearbeitet, und der Absturz wurde gestoppt.

Diese Instanzen werden NICHT wie eine medienbasierte Betriebssysteminstallation installiert, die die meisten von uns gewohnt sind. Sie wird ohne Pakete, kein ordnungsgemäßes Dateisystem und Dinge wie AppArmor, die alle möglichen Probleme verursachen, wenn sie sich dessen nicht bewusst sind und/oder weiß nicht, wie man es konfiguriert.

2
Joel

EINFACHE ANTWORT:

* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld

DETAILLIERTE ANTWORT:

Dies ist eine wichtige Frage, insbesondere für Personen, die einen sehr kleinen VPS verwenden, z. B. 1 GB RAM oder weniger. Wenn MySQL ausfällt, liegt möglicherweise ein Problem mit Ihrer Serverkonfiguration (Apache | nginx) oder der MySQL-Konfiguration vor. DOS-Angriffe können zu einer erhöhten Auslastung der Systemressourcen führen (siehe Abbildung). Das Endergebnis ist, dass der MySQL-Prozess vom Kernel heruntergefahren wird. Für eine langfristige Lösung sollten Sie Ihre Apache- oder MySQL-Konfigurationen optimieren.

System resources spike causing RAM spike (just before 6pm) and system resources spike causing only a CPU spike Midnight on Tue 18

Es gibt mehrere andere Diskussionen über Stack Overflow zu diesen Themen sowie das MySQL-Handbuch und den Percona-Blog:

MySQL-Handbuch - Wie MySQL Speicher verwendet:

https://dev.mysql.com/doc/refman/8.0/en/memory-use.html

Percona - Best Practices für die Konfiguration einer optimalen MySQL-Speichernutzung:

https://www.percona.com/blog/2016/05/03/best-practices-for-configuring-optimal-mysql-memory-usage/

So optimieren Sie die MySQL-Leistung mit MySQLTuner:

https://www.linode.com/docs/databases/mysql/how-to-optimize-mysql-performance-using-mysqltuner/

Konfiguration der Apache-Speichernutzung:

https://serverfault.com/questions/254436/Apache-memory-usage-optimization

Apache-Handbuch zur Leistungsoptimierung:

https://httpd.Apache.org/docs/2.4/misc/perf-tuning.html

Apache Server optimieren:

https://www.linode.com/docs/web-servers/Apache-tips-and-tricks/tuning-your-Apache-server/

In Bezug auf Ihre ursprüngliche Frage können Sie jedoch eine temporäre Lösung erstellen, die prüft, ob der MySQL-Dienst geladen und aktiv ist, und MySQL neu startet, wenn er nicht geladen und aktiv ist.

Sie haben nicht erwähnt, welches Betriebssystem Sie verwenden. Das würde Ihnen helfen, einen bestimmten Befehl zu erteilen. Ich werde Ihnen ein Beispiel für CentOS Linux geben.
Sehen Sie sich die folgende Ausgabe des Befehls systemctl status mysql an. Sie können oben sehen, dass der Dienst geladen und aktiv ist.

[[email protected] ~]# 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.

Wenn der Dienst nicht geladen ist, dann ein Befehl wie:

systemctl status mysqld || systemctl restart mysqld 

wird den Trick tun, den Prozess neu zu starten. Sie könnten schreiben, dass:

* * * * * systemctl status mysqld || systemctl restart mysqld

In dem Fall, dass mysql geladen ist , der Dienst jedoch nicht aktiv ist , dein cron wird nichts machen. Daher sollten Sie einen detaillierteren Befehl verwenden, z.

* * * * * systemctl is-active --quiet mysqld || systemctl restart mysqld

In diesem Fall, wenn der Dienst geladen , aber inaktiv ist, wie z Wenn Sie feststellen, dass ein DOS-Angriff Ihren MySQL-Dienst verlassen kann, startet der Befehl auch MySQL neu. Die Verwendung des Flags --quiet gibt nur den Befehl an, nur einen Statuscode zurückzugeben und nichts auf dem Bildschirm auszugeben. Wenn Sie das Flag --quiet auslassen, wird eine Statusausgabe von active oder inactive angezeigt.

Sie können auch einen Auslagerungsbereich erstellen, um Ihrem Server mehr verfügbare RAM Ressourcen hinzuzufügen, z.

Sudo dd if=/dev/zero of=/swapfile count=2096 bs=1MiB
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon --show
swapon --summary
free -h
0
jonnyjandles

Verwenden Sie eine der folgenden Lösungen:

  1. Erhöhen Sie den physischen Arbeitsspeicher. Durch Hinzufügen von zusätzlichen 1 GB RAM wird das Problem gelöst.

  2. Weisen Sie den SWAP-Bereich mithilfe der folgenden Konfigurationsänderungen zu:

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
0
Ajinkya_Joshi

Das Problem ist, dass der Server nicht über genügend Speicher verfügt, um ihn für den MySQL-Prozess zu reservieren. Es gibt einige Lösungen für dieses Problem.

(1) Erhöhen Sie den physischen RAM. Durch Hinzufügen von zusätzlichen 1 GB RAM wird das Problem gelöst. (2) SWAP-Speicherplatz zuweisen. Die Digital Ocean VPS-Instanz ist standardmäßig nicht für die Verwendung von Auslagerungsbereichen konfiguriert. Durch die Zuweisung von 512 MB Swap Space konnten wir dieses Problem lösen. Führen Sie die folgenden Schritte aus, um Ihrem Server Auslagerungsspeicher hinzuzufügen:

## 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 

Reduzieren Sie die Größe des MySQL-Pufferpools

## Edit /etc/my.cnf, and add the following line under the [mysqld] heading.
[mysqld]
innodb_buffer_pool_size=64M

Bitte überprüfen Sie auch Ihren Speicherplatz. Stellen Sie sicher, dass Sie genügend Platz haben. 

df-h

0
Ranjeet Ranjan