mysql - pages - plugin federated is disabled

Amazon EC2, mysql abortar el inicio porque InnoDB: mmap(x bytes) falló; errno 12 (6)

Configuré un servidor de microinstancia en EC2 basado en lo que leo here

El servidor mysql falla frecuentemente y por tercera vez el servidor mysql se ha ido. Los registros solo muestran

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

Lo que realmente failed; errno 12 failed; errno 12 ? ¿Y cómo podría dar más espacio / memoria o lo que sea necesario para arreglarlo?

Lo soluciono cada vez reiniciando todo el sistema y eliminando todos los registros y reiniciando el servidor mysql. Pero sé que algo está mal con mi configuración.

También mi `my.cnf ''es como a continuación:

[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

El problema es que el servidor no tiene suficiente memoria para asignar para el proceso MySQL. Hay algunas soluciones a este problema.

(1) Aumente la RAM física. Agregar 1GB de RAM adicional resolverá el problema. (2) Asignar espacio SWAP. La instancia de Digital Ocean VPS no está configurada para usar el espacio de intercambio de forma predeterminada. Al asignar 512 MB de espacio de intercambio, pudimos resolver este problema. Para agregar espacio de intercambio a su servidor, siga los siguientes pasos:

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

Reducir el tamaño del tamaño de la agrupación de almacenamiento intermedio de MySQL

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

También revise su espacio en disco. Asegúrate de tener suficiente espacio.

df-h

Encontré el mismo problema cuando traté de ejecutar un wordpress en mi microinstancia sin RDS.

Agregar una página de intercambio resolvió el problema para mí.

Puede seguir esto para configurar la página de intercambio:

prowebdev.us/2012/05/amazon-ec2-linux-micro-swap-space.html

Si aún así no funciona, considere usar el servicio RDS.

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

El enlace al blog a veces falla. Copié el contenido a continuación para el registro. El crédito va al autor del blog Pedram Moubed :

Espacio de intercambio de instancias micro de Amazon EC2 - Linux

Tengo una instancia de Amazon EC2 Linux Micro. Como las instancias Micro solo tienen 613 MB de memoria, MySQL se cuelga de vez en cuando. Después de una larga búsqueda sobre MySQL, Micro Instance y Memory Managment descubrí que no hay un espacio SWAP predeterminado para la instancia de Micro. Por lo tanto, si desea evitar el bloqueo, es posible que deba configurar un espacio de intercambio para su microinstancia. En realidad, en cuanto al rendimiento, es mejor habilitar el intercambio.

Los pasos a continuación muestran cómo crear un espacio de intercambio para su instancia de Micro. Supongo que tiene una cuenta de AWS con una instancia de Micro ejecutándose.

Ejecute dd if=/dev/zero of=/swapfile bs=1M count=1024
Ejecute mkswap /swapfile
Ejecute swapon /swapfile
Agregue esta línea /swapfile swap swap defaults 0 0 a /etc/fstab

El paso 4 es necesario si desea habilitar automáticamente el archivo de intercambio después de cada reinicio.

Algunos comandos útiles relacionados con el espacio SWAP:

$ swapon -s $ free -k $ swapoff -a $ swapon -a

Referencias

Para mí, este problema exacto se rectificó agregando un volumen de intercambio a mi instancia de EC2. Mis servicios simplemente consumían toda la memoria de la caja y se bloqueaban. No es algo a lo que yo estaba acostumbrado, ya que soy administrador de RedHat / CentOS durante años. Anaconda hace MUCHO trabajo que la instancia gratuita de Ubuntu EC2 no.

Simplemente creé un volumen de 2Gb a través de la consola web, lo adjunté a mi instancia e hice "mkswap / dev / [whatever]", edité / etc / fstab y se detuvo el bloqueo.

Estas instancias NO se instalan como una instalación de sistema operativo basada en medios a la que la mayoría de nosotros estamos acostumbrados: está desprovisto de paquetes, sin un sistema de archivos adecuado y cosas como AppArmor, que causan todo tipo de problemas si no lo sabes. y / o no sé cómo configurarlo.

Parece que está solicitando 128M de memoria para el innodb_buffer_pool_size en el archivo my.cfg que muestra en la publicación, pero MySQL cree que está solicitando 512M de memoria:

Inicializar grupo de búferes, tamaño = 512.0M

Unas líneas más abajo, el mensaje de error le dice que MySQL no se iniciará porque no puede reservar suficiente memoria (512M) para el grupo de búferes InnoDB:

Error fatal: no se puede asignar memoria para el grupo de búferes

Eso plantea tres preguntas:

¿Cuánta memoria hay en tu instancia? ¿Debería haber suficiente memoria para acomodar el 512M InnoDB está tratando de obtener el grupo de búferes, además de todo lo demás que MySQL asigna, además de su (s) aplicación (es), más el sistema operativo?
¿Por qué InnoDB está tratando de tomar más de lo que crees que debería?
¿Por qué MySQL se está reiniciando de todos modos?

Puedes responder 1.

En cuanto a 2., hay algunos lugares diferentes donde se pueden ubicar los archivos de opciones de MySQL. Los archivos encontrados posteriormente anulan las opciones especificadas en los archivos encontrados previamente. Ver

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

El problema 3. podría deberse a una condición de falta de memoria que ocurre en algún momento después del inicio. Debería ver una indicación de eso más atrás en los registros si ese es el caso.

Finalmente, pero sin relación alguna, ¿está usando instancias respaldadas por EBS? En general, es muy recomendable para los servidores de bases de datos (en realidad, para cualquier instancia que impida circunstancias especiales). Para más sobre eso, ver

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

También tuve este problema en una microinstancia de Amazon EC2. Intenté disminuir el uso de la memoria de inno_db agregando lo siguiente a /etc/my.cnf

innodb_buffer_pool_size = 64M

Eso no funcionó, traté de dejarlo en 16M y aún no funcionó. Entonces me di cuenta de que la instancia tenía básicamente cero memoria libre. Así que intenté reiniciar Apache

sudo system httpd restart sudo system mysqld restart

Y todo funcionó bien. Quizás otra solución sea configurar apache para no comer tanta memoria de alguna manera.

Use cualquiera de las siguientes soluciones:

Aumenta la RAM física. Agregar 1GB de RAM adicional resolverá el problema.
Asigne el espacio SWAP utilizando los cambios de configuración a continuación:

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