MySql no está recogiendo cambios en el archivo my.cnf en un Ubuntu AMI personalizado. ¿Cómo puedo solucionar esto?

0

Creé una AMI desde mi instancia de Ubuntu EC2 en ejecución. Luego lo mencioné y MySql no se ejecuta de la misma manera en esta instancia copiada.

1) Los cambios en mi archivo my.cnf no se están recogiendo.

2) No puedo consultar mi base de datos, ya que me da el siguiente error:

ERROR 1286 (42000): Unknown table engine 'InnoDB'

¿Supongo que MySql no está configurado correctamente? Soy nuevo en MySql, ¿me puede decir qué estoy haciendo mal, por favor?

Gracias por adelantado.

cono
fuente
¿Está reiniciando mysql después de cada cambio en my.cnf? ¿Qué hay en my.cnf?
rvs

Respuestas:

0

Verifique / var / log / syslog en busca de errores que ocurrieron durante el inicio de MySQL. Puede ser que su archivo /etc/mysql/my.cnf incluya una instrucción skip-innodb, que deshabilitaría las tablas InnoDB.

Daemon of Chaos
fuente
Desafortunadamente, no fue tan sencillo como eso.
cono
0

Aprendí (después de varias horas de resolución de problemas) que si algo sale mal en su configuración, ninguna de las configuraciones se actualiza.

Por ej. en mi caso, la replicación se rompió. Sin embargo, en lugar de

Slave_IO_Running: No
Slave_SQL_Running: No

Al aparecer como "NO", el nombre del host maestro tampoco se actualizó, lo que había cambiado en mi archivo .cnf. Además, skip-innoDB no estaba configurado en mi archivo .cnf, pero innoDB todavía no se habilitaba. Esto me llevó a sospechar que el problema estaba relacionado con el archivo .cnf.

Resultó, sin embargo, ser dos cosas separadas.

InnoDB no pudo aparecer debido a una escasez de memoria. La memoria que estaba asignando era más que la nueva instancia EC2 ofrecida. Esta es una lección para crear imágenes: preste atención al tamaño de la instancia que está creando.

El segundo problema fue que la replicación no estaba llegando. Esto es porque no tenía:

RESTABLECER ESCLAVO

Y luego debidamente modificado:

MASTER_LOG_POS

Recibí la respuesta a esto en otra pregunta de SF:

¿Por qué la replicación MySQL es tan complicada?

Gran guía publicada como respuesta allí.

Tengo punteros a todo esto en mi registro SQL ubicado en:

/var/log/mysql/error.log

Tenía las siguientes entradas:

InnoDB: Error: cannot allocate 1048592384 bytes of

InnoDB: memory with malloc! Total allocated memory

InnoDB: by InnoDB 38079360 bytes. Operating system errno: 12

InnoDB: Check if you should increase the swap file or

InnoDB: ulimits of your operating system.

InnoDB: On FreeBSD check you have compiled the OS with

InnoDB: a big enough maximum process size.

InnoDB: Note that in most 32-bit computers the process

InnoDB: memory space is limited to 2 GB or 4 GB.

InnoDB: We keep retrying the allocation for 60 seconds...

InnoDB: Fatal error: cannot allocate the memory for the buffer pool

110616 18:41:58 [ERROR] Plugin 'InnoDB' init function returned error.

110616 18:41:58 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

110616 18:41:58 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay- log=ip-xxxx-relay-bin' to avoid this problem.

110616 18:41:58 [ERROR] Failed to open the relay log 'xxxx' (relay_log_pos 251)

110616 18:41:58 [ERROR] Could not find target log during relay log initialization

110616 18:41:58 [ERROR] Failed to initialize the master info structure

¡Realmente espero que esto ayude a alguien algún día!

cono
fuente