Amazon EC2, mysql aborting start because InnoDB: mmap (x bytes) failed; errno 12
I have a micro instance server on EC2 based this
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 met the same problem when I tried to run a wordpress on my micro instance without RDS.
Adding a Swap page solved the problem for me.
You can follow steps below to setup the swap space.
If it still doesn't work for you, consider using the RDS service.
===============================================
I copied the content of the blog for the record. Credit goes to the blog author pmoubed:
Amazon EC2 Micro Instance Swap Space - Linux
I have a Amazon EC2 Linux Micro instance. Since Micro instances have only 613MB of memory, MySQL crashed every now and then. After a long search about MySQL, Micro Instance and Memory Managment I found out there is no default SWAP space for Micro instance. So if you want to avoid the crash you may need to setup a swap space for your micro instance. Actually performance wise is better to enable swap.
Steps below show how to make a swap space for your Micro instance. I assume you have AWS Account with a Micro instance running.
- Run
dd if=/dev/zero of=/swapfile bs=1M count=1024
- Run
mkswap /swapfile
- Run
swapon /swapfile
- Add this line
/swapfile swap swap defaults 0 0
to/etc/fstab
Step 4 is needed if you would like to automatically enable swap file after each reboot.
Some useful command related to SWAP space:
$ swapon -s
$ free -k
$ swapoff -a
$ swapon -a
References:
- http://www.thegeekstuff.com/2010/08/how-to-add-swap-space/
- http://cloudstory.in/2012/02/getting-the-best-out-of-amazon-ec2-micro-instances/
- http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/
- http://aws.amazon.com/ec2/instance-types/
I had this problem too on an Amazon EC2 micro instance. I tried decreasing inno_db's memory usage by adding the following to /etc/my.cnf
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.