If you expect your InnoDB data to grow, you should prepare for it by having a larger InnoDB Buffer Pool.

Where does the idea of having additional 10% extra space for the Buffer Pool come from ???

Please note the following diagram of the InnoDB Architecture

Look in the upper left hand corner where you see the buffer pool. There is a section of it called the "Insert Buffer Part". The purpose of the Insert Buffer is to populate changes to non-unique indexes into the Insert Buffer inside the system tablespace file (a.k.a. ibdata1).

From the diagram, up to 50% of the Buffer Pool can be used to manage the Insert Buffer. That being the case, it would be in your best interests to assign a lot more memory to the Buffer Pool. With a data set of 60M, 256M would be a great place to start,

I am not totally convinced MySQL is running out of memory. Here is why:

ASPECT #1

When you use mysqltuner.pl, it calculates the total usage in the worst case scenario. It does it by adding 3 figures together

• key_buffer_size
• innodb_buffer_pool_size
• thread_memory : max_connections * the sum of
  • sort_buffer_size
  • join_buffer_size
  • read_buffer_size
  • read_rnd_buffer_size

In your case, given your current settings, that would be the sum of

• key_buffer_size (256M)
• innodb_buffer_pool_size (128M)

• thread_memory (200M) : max_connections (200) * the sum of

  • sort_buffer_size (256K)
  • join_buffer_size (256K)
  • read_buffer_size (256K)
  • read_rnd_buffer_size (256K is default)

• With given settings, your absolute worst case memory consumption for MySQL is 584M (256M + 128M + 200M).

• If you use RIBPS, your absolute worst case memory consumption for MySQL would become 939M (256M + 481M + 200M).
• If you use 500M, your absolute worst case memory consumption for MySQL would become 958M (256M + 481M + 200M).

Therefore, at its very worst, MySQL would consume only 9.58% of RAM.

ASPECT #2

You did not mention if the Server is a dedicated DB Server or if you are running a full stack. If you are running a full stack, please lower any memory-sensitive settings in the other parts of the stack (Varnish (more like Vanish), PHP, Munin, Nagios, Tomcat, Hibernate, etc).

ASPECT #3

Looking at the first crash around 3:36 AM I see

150708  3:36:36  InnoDB: Error: table 'thecityo_production_wp/wp_wfNet404s'
InnoDB: in InnoDB data dictionary has tablespace id 20744,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
InnoDB: table still exists in the InnoDB internal data dictionary.

At that point, MySQL is complaining that the data dictionary entry for the table wp_wfNet404s in the thecityo_production_wp database is still inside the system tablespace.

Next, mysqld restarted and was ready for new connections

150708  3:36:37 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.42-cll'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

One minute later, it crashed again. What was in the stack trace of the second crash ?

stack_bottom = 7f70e2625e58 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x7aabf5]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x686324]
/lib64/libpthread.so.0(+0xf710)[0x7f7120768710]
/lib64/libc.so.6(gsignal+0x35)[0x7f711f92f625]
/lib64/libc.so.6(abort+0x175)[0x7f711f930e05]
/usr/sbin/mysqld[0x8fbd91]
/usr/sbin/mysqld[0x8fbdee]
/usr/sbin/mysqld[0x881fc7]
/usr/sbin/mysqld[0x83c104]
/usr/sbin/mysqld[0x83efa5]
/usr/sbin/mysqld[0x81819b]
/usr/sbin/mysqld(_Z13rr_sequentialP11READ_RECORD+0x1f)[0x74de7f]
/usr/sbin/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x79)[0x5ace99]
/usr/sbin/mysqld[0x5b16c7]
/usr/sbin/mysqld(_ZN4JOIN4execEv+0xc81)[0x5c6f41]
/usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x12c)[0x5c873c]
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x165)[0x5c9175]
/usr/sbin/mysqld[0x584392]
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x144d)[0x5894cd]
150708  3:39:09 [ERROR] /usr/sbin/mysqld: Out of memory (Needed 258064 bytes)
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x330)[0x58ce20]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1af3)[0x58f1e3]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0xd7)[0x629297]
/usr/sbin/mysqld(handle_one_connection+0x51)[0x6293d1]
/lib64/libpthread.so.0(+0x79d1)[0x7f71207609d1]
/lib64/libc.so.6(clone+0x6d)[0x7f711f9e58fd]

It looks like you were doing some kind of SELECT ... JOIN query. My guess would be you were accessing the corrupt table in the SELECT ... JOIN because of this line

/usr/sbin/mysqld(_Z13rr_sequentialP11READ_RECORD+0x1f)[0x74de7f]

which might by some kind of sequential read.

If you keep seeing

150708  3:36:36  InnoDB: Error: table 'thecityo_production_wp/wp_wfNet404s'

upon every crash and restart of mysqld, you need to clean that entry out of ibdata1.

I would not be fooled by

150708  3:39:09 [ERROR] /usr/sbin/mysqld: Out of memory (Needed 258064 bytes)

It is complaining about not allocating 252K. That's just a side affect of the error because it could allocate needed memory for an operation that cannot read from a table.

EPILOGUE

Please look into removing the pidgeon hole in the data dictionary. Also, look for other memory consuming components in the DB Server.