stopping - usr sbin mysqld unknown storage engine innodb
Amazon EC2, mysql aborting start because InnoDB: mmap(x bytes) failed; errno 12 (4)
For me, this exactly problem was rectified by adding a swap volume to my EC2 instance. My services were simply consuming all the memory on the box, and would crash. Not something I was used to, being a RedHat/CentOS admin for years - Anaconda does a LOT of work that the free Ubuntu EC2 instance does not.
I simply created a 2Gb volume through the web console, attached it to my instance, and did "mkswap /dev/[whatever]", edited /etc/fstab, and the crashing stopped.
These instances do NOT install like a media-based OS install that most of us are used to - it's stripped bare with no packages, no proper filesystem, and things like AppArmor, which cause all kinds of problems if you aren't aware of it and/or don't know how to configure it.
I have set up a micro instance server on EC2 based on what I read here
mysql server fails frequently and for the third time mysql server is gone. The logs only shows
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
What is really
failed; errno 12? And how could I give more space/memory or whatever needed to make this fixed.
I fix this each time by rebooting the whole system and deleting all logs and restart the mysql server. But I know something is wrong with my configuration.
Also my `my.cnf' is like below :
[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
I had this problem too on an Amazon EC2 micro instance. I tried decreasing inno_db's memory usage by adding the following to
innodb_buffer_pool_size = 64M
That didn't work, I tried dropping it down to 16M and it still didnt work. Then I realized that the instance had basically zero free memory. So I tried restarting apache
sudo system httpd restart sudo system mysqld restart
And everything worked fine. Maybe another solution is to configure apache to not eat up so much memory somehow.
It looks like you are requesting 128M of memory for the innodb_buffer_pool_size in the my.cfg file you show in the post, but MySQL thinks you are asking for 512M of memory:
Initializing buffer pool, size = 512.0M
A few lines down, the error message tells you MySQL will not start because it cannot reserve enough (512M) memory for the InnoDB buffer pool:
Fatal error: cannot allocate memory for the buffer pool
That begs three questions:
- How much memory is on your instance? Should there be enough memory to accommodate the 512M InnoDB is trying to grab for the buffer pool, plus everything else MySQL allocates, plus your application(s), plus the operating system?
- Why is InnoDB trying to take more than you think it should?
- Why is MySQL restarting anyhow?
You can answer 1.
As to 2., there are a few different places MySQL option files can be located. Subsequently found files override options specified in previously found files. See
Issue 3. could be due to an out of memory condition that occurs sometime after startup. You should see an indication of that further back in the logs if that is the case.
Finally, but somewhat unrelated, are you using EBS backed instances? That's generally highly recommended for database servers (actually, for any instance barring special circumstances). For more on that see
The problem is that the server does not have enough memory to allocate for MySQL process. There are a few solutions to this problem.
(1) Increase the physical RAM. Adding 1GB of additional RAM will solve the problem. (2) Allocate SWAP space. Digital Ocean VPS instance is not configured to use swap space by default. By allocating 512MB of swap space, we were able to solve this problem. To add swap space to your server, please follow the following steps:
## 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
Reduce the size of MySQL buffer pool size
## Edit /etc/my.cnf, and add the following line under the [mysqld] heading. [mysqld] innodb_buffer_pool_size=64M
Also please check your Disk Space. Make sure you have sufficient space.