MySQL crash on startup - mysql

I'm developing on my laptop with wamp and mysql is running fine from weeks. Today after 60 seconds after boot mysql crashes I and find the following error inside the log:
2016-03-17T20:34:37.662021Z 0 [ERROR] InnoDB: Cannot allocate 4294956804 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b74 InnoDB: Assertion failure in thread 11124 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20:34:37 UTC - mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=67108864
read_buffer_size=2097152
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 685380 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x103288c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
2016-03-17T20:34:37.682021Z 0 [ERROR] InnoDB: Cannot allocate 4294954524 bytes of memory after 60 retries over 60 seconds. OS error: Not enough space (12). Check if you should increase the swap file or ulimits of your operating system. Note that on most 32-bit computers the process memory space is limited to 2 GB or 4 GB.
2016-03-17 21:34:37 0x2b58 InnoDB: Assertion failure in thread 11096 in file ut0ut.cc line 938
InnoDB: Failing assertion: !m_fatal
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
To me it seems that there is a memory issue:
[ERROR] InnoDB: Cannot allocate 4294956804 bytes of memory after 60
retries over 60 seconds. OS error: Not enough space (12).
Could it be that the crash is due to this error? It's weird that mysql try to allocate 4Gb of ram, normally it uses more or less 500Mb.
this is my.ini:
innodb_buffer_pool_size = 16M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50
I'm running mysql 32 bit on a win7 64bit.
Is this something I can solve changing some variable?
Thanks very much for your help

It was probably a corruption of the InnoDB data. I added
innodb_force_recovery = 2
to my.ini, restarted the DB and I was able to dump all the data and recover it.
Be aware of using this, read the documentation before: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

I had similar problem on a CentOS VPS and Stefano Giacone's answer is basically what I did so it worked after hours of researching and a lot of stress...
Well the steps were:
1) Find my.cnf file (mine was located in /etc/my.cnf) and add the line:
innodb_force_recovery = X
replacing X with a integer from 1 to 6, starting from 1 and then incrementing if MySQL won't start. Setting to 4, 5 or 6 can delete your data so be carefull and read http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html before.
2) Restart MySQL service. Only SELECT will run and that's normal at this point.
3) Dump all your databases/schemas with mysqldump one by one, do not compress the dumps because you'd have to uncompress them later anyway in 6).
4) Move (or delete!) only the bd's directories inside /var/lib/mysql, preserving the individual files in the root.
5) Stop MySQL and then uncomment the line added in 1). Start MySQL.
6) Recover all bd's dumped in 3).
That worked for me, good luck!

Related

Getting Semaphore wait has lasted > 600 seconds error while using MySql(5.7.31)

Since i'm not to sure what to do other then what i've seen on here and stackoverflow but i'm getting this error when i startup MySql in WampServer: Semaphore wait has lasted > 600 seconds error. I've tried lowering and raising the values of these variables and this is what i have it set to now innodb_buffer_pool_size = 10M
innodb_log_file_size = 2G innodb_log_buffer_size = 10M in my my.ini config file the only way i've been able to overcome this error was by setting innodb_force_recovery to level 6 but then mysql is in read only mode and i need to create some more tables in my db any suggestions would help thanks
here's the whole error let me know if you need to see more of the log or more variables in my config file
InnoDB: ###### Diagnostic info printed to the standard error stream
2021-02-23T18:25:17.237395Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2021-02-23 13:25:17 0x3a8c InnoDB: Assertion failure in thread 14988 in file ut0ut.cc line 918
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
18:25:17 UTC - mysqld got exception 0x80000003 ;

mysql import on Docker

i'm trying to import a database (68GB) to my local docker, im not using volumes forward (so no -v), no soft and hard limit on the conatiner and my computer is 16GB RAM and 12 Core with ubuntu 18.04.
I'm using the "gzip method" so i have gzip the folder /var/lib/mysql on the mysql master and after i have unzipped all on my local docker. this is my.cnf:
port = 3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 10000
net_write_timeout = 10000
wait_timeout = 10000
max_allowed_packet = 16777216
interactive_timeout = 1000000
net_buffer_length = 1048576
net_read_timeout = 10000
innodb_strict_mode = 0
innodb_log_file_size = 100M
lower_case_table_names = 1
max_connections = 1500
key_buffer_size = 16777216
read_buffer_size = 16777216
sql_mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
innodb-stats-persistent = 0
innodb_change_buffering=inserts
innodb_flush_method=O_DIRECT
innodb_force_recovery = 1
query_cache_type=1
query_cache_size = 10M
query_cache_limit=256k
when i try to select something i receive that error:
InnoDB: is in the future! Current system log sequence number 596753491997.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-06-05 09:36:22 7f5bdba58700 InnoDB: Error: page 56030 log sequence number 596868932698
InnoDB: is in the future! Current system log sequence number 596753491997.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: for more information.
2019-06-05 09:36:22 15 [ERROR] InnoDB: InnoDB: Unable to allocate memory of size 18446744073709541240.
2019-06-05 09:36:22 7f5bdba58700 InnoDB: Assertion failure in thread 140032503809792 in file ha_innodb.cc line 17420
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
09:36:22 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=16777216
read_buffer_size=16777216
max_used_connections=1
max_threads=1500
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 24995579 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x559f8ba4b220
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f5bdba57e98 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2c)[0x559f8a80e28c]
/usr/sbin/mysqld(handle_fatal_signal+0x4b1)[0x559f8a5ac021]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f5c144830c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f5c1301ffff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f5c1302142a]
/usr/sbin/mysqld(+0x6fcd50)[0x559f8a849d50]
/usr/sbin/mysqld(+0x73656f)[0x559f8a88356f]
/usr/sbin/mysqld(+0x736623)[0x559f8a883623]
/usr/sbin/mysqld(+0x7bb5c5)[0x559f8a9085c5]
/usr/sbin/mysqld(+0x7bbaf9)[0x559f8a908af9]
/usr/sbin/mysqld(+0x7a1680)[0x559f8a8ee680]
/usr/sbin/mysqld(+0x798ba2)[0x559f8a8e5ba2]
/usr/sbin/mysqld(+0x6f9c5e)[0x559f8a846c5e]
/usr/sbin/mysqld(_ZN7handler11ha_rnd_nextEPh+0x5c)[0x559f8a4fbf1c]
/usr/sbin/mysqld(_Z13rr_sequentialP11READ_RECORD+0x35)[0x559f8a7455a5]
/usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x14e)[0x559f8a601e2e]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0x450)[0x559f8a601200]
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_P10SQL_I_ListI8st_orderESB_S7_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x29d)[0x559f8a64970d]
/usr/sbin/mysqld(_Z13handle_selectP3THDP13select_resultm+0x13c)[0x559f8a649ebc]
/usr/sbin/mysqld(+0x37912c)[0x559f8a4c612c]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x347e)[0x559f8a62668e]
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x378)[0x559f8a629a88]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1279)[0x559f8a62b4f9]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x17a)[0x559f8a5f795a]
/usr/sbin/mysqld(handle_one_connection+0x40)[0x559f8a5f79c0]
/usr/sbin/mysqld(pfs_spawn_thread+0x146)[0x559f8aa4c8d6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f5c14479494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f5c130d5acf]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f5ba8100f40): select * from event
Connection ID (thread ID): 1
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
is that a bug or i'm miss something?
i have also try to run the comand:
mysql_install_db
or change the my.cnf with innodb_change_buffering=none and after
mysql> DELETE FROM mysql.innodb_index_stats;
Query OK, 1112767 rows affected (8.95 sec)
mysql> DELETE FROM mysql.innodb_table_stats;
Query OK, 91044 rows affected (1.99 sec)
but nothing
any tips?

MySQL crash while mysqldump / mysqlcheck

everytime I try to backup or check all tables mysql server crashes on Windows server 2012,
I am using XAMPP stack for my development environment.
The database crypto has more then 1100+ tables in DB.
I am including the logs below.
InnoDB: End of page dump
2017-09-24 13:58:35 7dc InnoDB: uncompressed page, stored checksum in field1 2521749199, calculated checksums for field1: crc32 2344073126, innodb 1121903210, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 2344073126, innodb 2892594725, none 3735928559, page LSN 0 2936733816, low 4 bytes of LSN at page end 0, page number (if stored to page already) 34, space id (if created with >= MySQL-4.1.1 and stored already) 1767
InnoDB: page type 17855 meaning INDEX
InnoDB: Page may be an index page where index id is 1522
InnoDB: (index "PRIMARY" of table "crypto"."300-token")
2017-09-24 13:58:35 2012 [ERROR] InnoDB: It is also possible that your operatingsystem has corrupted its own file cache.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: and rebooting your computer removes the error.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: If the corrupt page is an index page you can also try to
2017-09-24 13:58:35 2012 [ERROR] InnoDB: fix the corruption by dumping, dropping, and reimporting
2017-09-24 13:58:35 2012 [ERROR] InnoDB: the corrupt table. You can use CHECK
2017-09-24 13:58:35 2012 [ERROR] InnoDB: TABLE to scan your table for corruption.
2017-09-24 13:58:35 2012 [ERROR] InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html about forcing recovery.
2017-09-24 13:58:35 7dc InnoDB: Assertion failure in thread 2012 in file buf0lru.cc line 2394
InnoDB: Failing assertion: bpage->buf_fix_count == 0
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
170924 13:58:35 [ERROR] mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, something is
definitely wrong and this may fail.
Server version: 10.1.22-MariaDB key_buffer_size=16777216
read_buffer_size=262144 max_used_connections=1 max_threads=1001
thread_count=1 It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
787106 K bytes of memory Hope that's ok; if not, decrease some
variables in the equation.
Thread pointer: 0x0 Attempting backtrace. You can use the following
information to find out where mysqld died. If you see no messages
after this, something went terribly wrong...
mysqld.exe!my_parameter_handler() mysqld.exe!my_wildcmp_mb_bin()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
mysqld.exe!?save_in_result_field#Item##UAEX_N#Z()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlInitializeExceptionChain()
ntdll.dll!RtlInitializeExceptionChain() The manual page at
http://dev.mysql.com/doc/mysql/en/crashing.html contains information
that should help you find out what is causing the crash.
I hope someone will help me out
Thanks.
From this content in your question,
"Server version: 10.1.22-MariaDB key_buffer_size=16777216 read_buffer_size=262144 max_used_connections=1 max_threads=1001 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787106 K ...."
with max_threads=1001 clue above - check for max_connections in your my.ini or .cnf. Lowering max_connections to = 100 may or may not help get you past the BaseThreadInitThunk() ntdll.dll!

Error 1067: The process terminated unexpectedly [InnoDB]

I am facing the following error when i try to restart the MySQL service after an unexpected shutdown of the database server last night.
Could not start the MySQL service on Local Computer.
Error 1067: The process terminated unexpectedly.
When i check the .err log file under MySql data folder, the log details are as per below.
InnoDB: Log scan progressed past the checkpoint lsn 804 2135184621
150513 12:20:39 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 804 2136195241
150513 12:20:50 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 150513 12:20:50 InnoDB: Assertion failure in thread 2412 in file .\rem\rem0rec.c line 337
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http:// bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http:// dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
150513 12:20:51 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=135266304
read_buffer_size=65536
max_used_connections=0
max_threads=400
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 262617 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
InnoDB: Thread 164 stopped in file .\os\os0sync.c line 391
0070A1A8 mysqld.exe!rec_get_offsets_func()[rem0rec.c:337]
0071B498 mysqld.exe!page_cur_parse_insert_rec()[page0cur.c:798]
0071512F mysqld.exe!recv_parse_or_apply_log_rec_body()[log0recv.c:814]
00715CF1 mysqld.exe!recv_recover_page()[log0recv.c:1294]
006EBE0F mysqld.exe!buf_page_io_complete()[buf0buf.c:2033]
006E4472 mysqld.exe!fil_aio_wait()[fil0fil.c:4273]
006BCDCD mysqld.exe!io_handler_thread()[srv0start.c:437]
77E6482F kernel32.dll!GetModuleHandleA()
The manual page at http:// dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Error log show in Event Viewer:
An unhandled win32 exception occurred in mysqld.exe [1200]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.
MySQL version: 5.1<br>
Table Type: InnoDB<br>
ibdata1 Size: 28GB
There are no SQL dump backup files for the tables made and there is only the SQL physical data files. I am desperately needed to restore the data of these and bring the website back to online.
Please help.
Apparently this is a known bug within MySQL 5.1 as mentioned within a few bug docs below.
http://bugs.mysql.com/bug.php?id=44416
http://bugs.mysql.com/bug.php?id=45844
I have updated the MySQL version to the latest (5.1.73) and then force recovery the InnoDB at level 6 (can only be started at this level for my case). After that, i can proceed with mysqldump.
setting file my.ini
change or add setting
innodb_flush_method=normal
restart service mysql

MySQL fails on restart, InnoDB me alloc error 12

I am having a problem with MySQL on my Rackspace Centos 6.4 server instance. The problem is similar to the one described in this StackOverflow question. MySQL is being restarted automatically at some point by mysqld_safe, and the restart fails because InnoDB tries to allocate 128Mb of RAM, which fails. The output of mysqld.log is as follows:
140129 18:05:26 mysqld_safe Number of processes running now: 0
140129 18:07:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140129 18:07:30 InnoDB: Compressed tables use zlib 1.2.3
140129 18:07:30 InnoDB: Using Linux native AIO
140129 18:07:35 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
140129 18:07:46 InnoDB: Completed initialization of buffer pool
140129 18:07:46 InnoDB: Fatal error: cannot allocate memory for the buffer pool
140129 18:07:47 [ERROR] Plugin 'InnoDB' init function returned error.
140129 18:07:47 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140129 18:08:07 [ERROR] Unknown/unsupported storage engine: InnoDB
140129 18:08:10 [ERROR] Aborting
140129 18:08:53 [Note] /usr/libexec/mysqld: Shutdown complete
140129 18:18:18 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
The solution provided in that other question seemed to be one of "create a swap file". I have checked my server and it seems there is already an active swap file:
# swapon -s
Filename Type Size Used Priority
/dev/xvdc1 partition 499992 34876 -1
and, looking at that output, it is the size I was thinking I needed (512Mb). For completeness, here are the contents of my /etc/fstab file:
/dev/xvda1 / ext3 defaults,noatime,barrier=0 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/xvdc1 none swap sw 0 0
So am I missing something, or do I already have a working swap file, of about 512Mb, which is reasonably empty and therefore should be capable of handling a request for 128Mb? Should I reduce the size of the InnoDB buffer to, say, 64Mb? Will there be any issues related to shrinking this buffer?
(My Rackspace server is the smallest one available, which has 512Mb RAM. Whenever I do a top on the server, it seems to have between 50 and 80 Mb free.)
From the output it does look like you have approximately 488MB of swap space.
I am not sure if MySQL allocates the innodb buffer pool based off how much memory+swap is free. Even if it did, you would want to avoid it going to swap as it is slower than keeping things in RAM. My guess is that it does not include swap.
The error "InnoDB: mmap(137363456 bytes) failed; errno 12" lets us know that you could not allocate the memory.
# perror 12
OS error code 12: Cannot allocate memory
I would reduce the size of the innodb buffer pool to 64MB; see if that works. If it does not, either increase the size of the cloud server or reduce the size of the buffer pool again.
In general InnoDB likes memory. It tries to keep as much of the data in memory as possible and reduce disk IO. By reducing the buffer size, you decrease how much MySQL can keep in memory. MySQL will go to disk more often to retrieve data.
This number should reflect the size of your data set. No point in having a buffer much larger than your actual data set.
You may be able to use some of the queries here to determine the size. http://www.mysqlperformanceblog.com/2008/03/17/researching-your-mysql-table-sizes/
If your data set is much larger than the amount of RAM you normally have on hand, you may need to increase the size of the server itself.