180316 11:16:49 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:16:49 [Note] Plugin 'FEDERATED' is disabled.
180316 11:16:49 InnoDB: The InnoDB memory heap is disabled
180316 11:16:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:16:49 InnoDB: Compressed tables use zlib 1.2.8
180316 11:16:49 InnoDB: Using Linux native AIO
180316 11:16:49 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:16:49 InnoDB: Completed initialization of buffer pool
180316 11:16:49 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761422089
180316 11:16:49  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 44761424692
180316 11:16:50  InnoDB: Error: page 32780 log sequence number 44761426002
InnoDB: is in the future! Current system log sequence number 44761424692.
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.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
180316 11:16:50  InnoDB: Error: page 32783 log sequence number 44761426543
InnoDB: is in the future! Current system log sequence number 44761424692.
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.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
180316 11:16:50  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:16:50  InnoDB: Waiting for the background threads to start
180316 11:16:51 InnoDB: 5.5.59 started; log sequence number 44761424692
180316 11:16:51 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:16:51 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:16:51 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:16:51 [Note] Event Scheduler: Loaded 0 events
180316 11:16:51 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:29:44  InnoDB: Assertion failure in thread 140568669103872 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:29:44 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=4194304
read_buffer_size=65536
max_used_connections=2
max_threads=151
thread_count=2
connection_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55cea46d9e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55cea45c2cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd8e5005330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fd8e464bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fd8e464f028]
/usr/sbin/mysqld(+0x538b45)[0x55cea471cb45]
/usr/sbin/mysqld(+0x5395bb)[0x55cea471d5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55cea47df27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55cea47d5b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55cea471f3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55cea471110c]
/usr/sbin/mysqld(+0x530f82)[0x55cea4714f82]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fd8e4ffd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd8e471303d]
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.
180316 11:29:45 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:29:45 [Note] Plugin 'FEDERATED' is disabled.
180316 11:29:45 InnoDB: The InnoDB memory heap is disabled
180316 11:29:45 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:29:45 InnoDB: Compressed tables use zlib 1.2.8
180316 11:29:45 InnoDB: Using Linux native AIO
180316 11:29:45 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:29:45 InnoDB: Completed initialization of buffer pool
180316 11:29:45 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761435249
180316 11:29:45  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 44763280113
180316 11:29:45  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:29:45  InnoDB: Waiting for the background threads to start
180316 11:29:46 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:29:46 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:29:46 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:29:46 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:29:46 [Note] Event Scheduler: Loaded 0 events
180316 11:29:46 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:29:46  InnoDB: Assertion failure in thread 140563986761472 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:29:46 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=4194304
read_buffer_size=65536
max_used_connections=1
max_threads=151
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55a2178e8e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55a2177d1cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd7da515330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fd7d9b5bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fd7d9b5f028]
/usr/sbin/mysqld(+0x538b45)[0x55a21792bb45]
/usr/sbin/mysqld(+0x5395bb)[0x55a21792c5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55a2179ee27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55a2179e4b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55a21792e3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55a21792010c]
/usr/sbin/mysqld(+0x5311d3)[0x55a2179241d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fd7da50d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd7d9c2303d]
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.
180316 11:29:47 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:29:47 [Note] Plugin 'FEDERATED' is disabled.
180316 11:29:47 InnoDB: The InnoDB memory heap is disabled
180316 11:29:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:29:47 InnoDB: Compressed tables use zlib 1.2.8
180316 11:29:47 InnoDB: Using Linux native AIO
180316 11:29:47 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:29:47 InnoDB: Completed initialization of buffer pool
180316 11:29:47 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:29:47  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 44763280113
180316 11:29:47  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:29:47  InnoDB: Waiting for the background threads to start
180316 11:29:48 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:29:48 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:29:48 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:29:48 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:29:48  InnoDB: Assertion failure in thread 140511701485312 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:29:48 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55fb29042e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55fb28f2bcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fcba172d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fcba0d73c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fcba0d77028]
/usr/sbin/mysqld(+0x538b45)[0x55fb29085b45]
/usr/sbin/mysqld(+0x5395bb)[0x55fb290865bb]
180316 11:29:48 [Note] Event Scheduler: Loaded 0 events
180316 11:29:48 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
/usr/sbin/mysqld(+0x5fb27f)[0x55fb2914827f]
/usr/sbin/mysqld(+0x5f1b15)[0x55fb2913eb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55fb290883e5]
/usr/sbin/mysqld(+0x52d10c)[0x55fb2907a10c]
/usr/sbin/mysqld(+0x5311d3)[0x55fb2907e1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fcba1725184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fcba0e3b03d]
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.
180316 11:32:09 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:32:09 [Note] Plugin 'FEDERATED' is disabled.
180316 11:32:09 InnoDB: The InnoDB memory heap is disabled
180316 11:32:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:32:09 InnoDB: Compressed tables use zlib 1.2.8
180316 11:32:09 InnoDB: Using Linux native AIO
180316 11:32:09 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:32:09 InnoDB: Completed initialization of buffer pool
180316 11:32:09 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:32:09  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 44763280113
180316 11:32:09  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:32:10  InnoDB: Waiting for the background threads to start
180316 11:32:11 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:32:11 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:32:11 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:32:11 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:32:11 [Note] Event Scheduler: Loaded 0 events
180316 11:32:11 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:32:11  InnoDB: Assertion failure in thread 140637525481216 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:32:11 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55b764fd6e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55b764ebfcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe8eb1fd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fe8ea843c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fe8ea847028]
/usr/sbin/mysqld(+0x538b45)[0x55b765019b45]
/usr/sbin/mysqld(+0x5395bb)[0x55b76501a5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55b7650dc27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55b7650d2b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55b76501c3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55b76500e10c]
/usr/sbin/mysqld(+0x5311d3)[0x55b7650121d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe8eb1f5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe8ea90b03d]
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.
180316 11:32:11 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:32:11 [Note] Plugin 'FEDERATED' is disabled.
180316 11:32:11 InnoDB: The InnoDB memory heap is disabled
180316 11:32:11 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:32:11 InnoDB: Compressed tables use zlib 1.2.8
180316 11:32:11 InnoDB: Using Linux native AIO
180316 11:32:11 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:32:11 InnoDB: Completed initialization of buffer pool
180316 11:32:11 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:32:11  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 44763280113
180316 11:32:11  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:32:12  InnoDB: Waiting for the background threads to start
180316 11:32:13 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:32:13 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:32:13 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:32:13 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:32:13 [Note] Event Scheduler: Loaded 0 events
180316 11:32:13 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:32:13  InnoDB: Assertion failure in thread 139964587173632 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:32:13 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55e9d2fb1e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55e9d2e9acd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f4c4a99d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f4c49fe3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f4c49fe7028]
/usr/sbin/mysqld(+0x538b45)[0x55e9d2ff4b45]
/usr/sbin/mysqld(+0x5395bb)[0x55e9d2ff55bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55e9d30b727f]
/usr/sbin/mysqld(+0x5f1b15)[0x55e9d30adb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55e9d2ff73e5]
/usr/sbin/mysqld(+0x52d10c)[0x55e9d2fe910c]
/usr/sbin/mysqld(+0x5311d3)[0x55e9d2fed1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f4c4a995184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4c4a0ab03d]
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.
180316 11:32:13 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:32:13 [Note] Plugin 'FEDERATED' is disabled.
180316 11:32:13 InnoDB: The InnoDB memory heap is disabled
180316 11:32:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:32:13 InnoDB: Compressed tables use zlib 1.2.8
180316 11:32:13 InnoDB: Using Linux native AIO
180316 11:32:13 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:32:13 InnoDB: Completed initialization of buffer pool
180316 11:32:13 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:32:13  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 44763280113
180316 11:32:13  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:32:14  InnoDB: Waiting for the background threads to start
180316 11:32:15 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:32:15 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:32:15 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:32:15 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:32:15 [Note] Event Scheduler: Loaded 0 events
180316 11:32:15 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:32:15  InnoDB: Assertion failure in thread 140545305818880 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:32:15 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55c017828e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55c017711cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd3747a5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fd373debc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fd373def028]
/usr/sbin/mysqld(+0x538b45)[0x55c01786bb45]
/usr/sbin/mysqld(+0x5395bb)[0x55c01786c5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55c01792e27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55c017924b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55c01786e3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55c01786010c]
/usr/sbin/mysqld(+0x5311d3)[0x55c0178641d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fd37479d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd373eb303d]
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.
180316 11:34:34 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:34:34 [Note] Plugin 'FEDERATED' is disabled.
180316 11:34:34 InnoDB: The InnoDB memory heap is disabled
180316 11:34:34 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:34:34 InnoDB: Compressed tables use zlib 1.2.8
180316 11:34:34 InnoDB: Using Linux native AIO
180316 11:34:34 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:34:34 InnoDB: Completed initialization of buffer pool
180316 11:34:34 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:34:34  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 44763280113
180316 11:34:34  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:34:34  InnoDB: Waiting for the background threads to start
180316 11:34:35 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:34:35 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:34:35 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:34:35 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:34:35 [Note] Event Scheduler: Loaded 0 events
180316 11:34:35 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:34:35  InnoDB: Assertion failure in thread 140044975200000 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:34:35 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55dba9a74e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55dba995dcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f5f02856330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f5f01e9cc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f5f01ea0028]
/usr/sbin/mysqld(+0x538b45)[0x55dba9ab7b45]
/usr/sbin/mysqld(+0x5395bb)[0x55dba9ab85bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55dba9b7a27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55dba9b70b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55dba9aba3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55dba9aac10c]
/usr/sbin/mysqld(+0x5311d3)[0x55dba9ab01d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f5f0284e184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f5f01f6403d]
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.
180316 11:34:36 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:34:36 [Note] Plugin 'FEDERATED' is disabled.
180316 11:34:36 InnoDB: The InnoDB memory heap is disabled
180316 11:34:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:34:36 InnoDB: Compressed tables use zlib 1.2.8
180316 11:34:36 InnoDB: Using Linux native AIO
180316 11:34:36 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:34:36 InnoDB: Completed initialization of buffer pool
180316 11:34:36 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:34:36  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 44763280113
180316 11:34:37  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:34:37  InnoDB: Waiting for the background threads to start
180316 11:34:38 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:34:38 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:34:38 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:34:38 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:34:38 [Note] Event Scheduler: Loaded 0 events
180316 11:34:38 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:34:38  InnoDB: Assertion failure in thread 140561749608192 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:34:38 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55df05150e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55df05039cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd7488ee330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fd747f34c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fd747f38028]
/usr/sbin/mysqld(+0x538b45)[0x55df05193b45]
/usr/sbin/mysqld(+0x5395bb)[0x55df051945bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55df0525627f]
/usr/sbin/mysqld(+0x5f1b15)[0x55df0524cb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55df051963e5]
/usr/sbin/mysqld(+0x52d10c)[0x55df0518810c]
/usr/sbin/mysqld(+0x5311d3)[0x55df0518c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fd7488e6184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd747ffc03d]
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.
180316 11:34:38 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:34:38 [Note] Plugin 'FEDERATED' is disabled.
180316 11:34:38 InnoDB: The InnoDB memory heap is disabled
180316 11:34:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:34:38 InnoDB: Compressed tables use zlib 1.2.8
180316 11:34:38 InnoDB: Using Linux native AIO
180316 11:34:38 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:34:39 InnoDB: Completed initialization of buffer pool
180316 11:34:39 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:34: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 44763280113
180316 11:34:39  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:34:39  InnoDB: Waiting for the background threads to start
180316 11:34:40 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:34:40 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:34:40 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:34:40 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:34:40 [Note] Event Scheduler: Loaded 0 events
180316 11:34:40 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:34:40  InnoDB: Assertion failure in thread 140357031417600 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:34:40 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x564578ce0e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x564578bc9cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fa7aa096330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fa7a96dcc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fa7a96e0028]
/usr/sbin/mysqld(+0x538b45)[0x564578d23b45]
/usr/sbin/mysqld(+0x5395bb)[0x564578d245bb]
/usr/sbin/mysqld(+0x5fb27f)[0x564578de627f]
/usr/sbin/mysqld(+0x5f1b15)[0x564578ddcb15]
/usr/sbin/mysqld(+0x53b3e5)[0x564578d263e5]
/usr/sbin/mysqld(+0x52d10c)[0x564578d1810c]
/usr/sbin/mysqld(+0x5311d3)[0x564578d1c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fa7aa08e184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fa7a97a403d]
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.
180316 11:34:41 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:34:41 [Note] Plugin 'FEDERATED' is disabled.
180316 11:34:41 InnoDB: The InnoDB memory heap is disabled
180316 11:34:41 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:34:41 InnoDB: Compressed tables use zlib 1.2.8
180316 11:34:41 InnoDB: Using Linux native AIO
180316 11:34:41 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:34:41 InnoDB: Completed initialization of buffer pool
180316 11:34:41 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:34:41  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 44763280113
180316 11:34:41  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:34:41  InnoDB: Waiting for the background threads to start
180316 11:34:42 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:34:42 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:34:42 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:34:42 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:34:42 [Note] Event Scheduler: Loaded 0 events
180316 11:34:42 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:34:42  InnoDB: Assertion failure in thread 140522739988224 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:34:42 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55fdb1107e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55fdb0ff0cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fce3f6f6330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fce3ed3cc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fce3ed40028]
/usr/sbin/mysqld(+0x538b45)[0x55fdb114ab45]
/usr/sbin/mysqld(+0x5395bb)[0x55fdb114b5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55fdb120d27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55fdb1203b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55fdb114d3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55fdb113f10c]
/usr/sbin/mysqld(+0x5311d3)[0x55fdb11431d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fce3f6ee184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fce3ee0403d]
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.
180316 11:34:43 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:34:43 [Note] Plugin 'FEDERATED' is disabled.
180316 11:34:43 InnoDB: The InnoDB memory heap is disabled
180316 11:34:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:34:43 InnoDB: Compressed tables use zlib 1.2.8
180316 11:34:43 InnoDB: Using Linux native AIO
180316 11:34:43 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:34:43 InnoDB: Completed initialization of buffer pool
180316 11:34:43 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:34:43  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 44763280113
180316 11:34:43  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:34:43  InnoDB: Waiting for the background threads to start
180316 11:34:44 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:34:44 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:34:44 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:34:44 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:34:44  InnoDB: Assertion failure in thread 139998271616768 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:34:44 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55a535d38e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55a535c21cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f54146c6330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f5413d0cc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f5413d10028]
/usr/sbin/mysqld(+0x538b45)[0x55a535d7bb45]
/usr/sbin/mysqld(+0x5395bb)[0x55a535d7c5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55a535e3e27f]
180316 11:34:44 [Note] Event Scheduler: Loaded 0 events
180316 11:34:44 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
/usr/sbin/mysqld(+0x5f1b15)[0x55a535e34b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55a535d7e3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55a535d7010c]
/usr/sbin/mysqld(+0x5311d3)[0x55a535d741d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f54146be184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f5413dd403d]
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.
180316 11:51:47 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:51:47 [Note] Plugin 'FEDERATED' is disabled.
180316 11:51:47 InnoDB: The InnoDB memory heap is disabled
180316 11:51:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:51:47 InnoDB: Compressed tables use zlib 1.2.8
180316 11:51:47 InnoDB: Using Linux native AIO
180316 11:51:47 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:51:47 InnoDB: Completed initialization of buffer pool
180316 11:51:47 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:51:47  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 44763280113
180316 11:51:47  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:51:47  InnoDB: Waiting for the background threads to start
180316 11:51:48 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:51:48 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:51:48 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:51:48 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:51:48 [Note] Event Scheduler: Loaded 0 events
180316 11:51:48 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:51:48  InnoDB: Assertion failure in thread 140331882379008 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:51:48 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x555e06094e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x555e05f7dcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fa1cfcdd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fa1cf323c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fa1cf327028]
/usr/sbin/mysqld(+0x538b45)[0x555e060d7b45]
/usr/sbin/mysqld(+0x5395bb)[0x555e060d85bb]
/usr/sbin/mysqld(+0x5fb27f)[0x555e0619a27f]
/usr/sbin/mysqld(+0x5f1b15)[0x555e06190b15]
/usr/sbin/mysqld(+0x53b3e5)[0x555e060da3e5]
/usr/sbin/mysqld(+0x52d10c)[0x555e060cc10c]
/usr/sbin/mysqld(+0x5311d3)[0x555e060d01d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fa1cfcd5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fa1cf3eb03d]
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.
180316 11:51:49 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:51:49 [Note] Plugin 'FEDERATED' is disabled.
180316 11:51:49 InnoDB: The InnoDB memory heap is disabled
180316 11:51:49 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:51:49 InnoDB: Compressed tables use zlib 1.2.8
180316 11:51:49 InnoDB: Using Linux native AIO
180316 11:51:49 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:51:49 InnoDB: Completed initialization of buffer pool
180316 11:51:49 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:51:49  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 44763280113
180316 11:51:49  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:51:50  InnoDB: Waiting for the background threads to start
180316 11:51:51 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:51:51 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:51:51 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:51:51 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:51:51 [Note] Event Scheduler: Loaded 0 events
180316 11:51:51 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:51:51  InnoDB: Assertion failure in thread 140654822778624 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:51:51 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x563f22d40e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x563f22c29cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fecf42cd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fecf3913c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fecf3917028]
/usr/sbin/mysqld(+0x538b45)[0x563f22d83b45]
/usr/sbin/mysqld(+0x5395bb)[0x563f22d845bb]
/usr/sbin/mysqld(+0x5fb27f)[0x563f22e4627f]
/usr/sbin/mysqld(+0x5f1b15)[0x563f22e3cb15]
/usr/sbin/mysqld(+0x53b3e5)[0x563f22d863e5]
/usr/sbin/mysqld(+0x52d10c)[0x563f22d7810c]
/usr/sbin/mysqld(+0x5311d3)[0x563f22d7c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fecf42c5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fecf39db03d]
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.
180316 11:51:51 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:51:51 [Note] Plugin 'FEDERATED' is disabled.
180316 11:51:51 InnoDB: The InnoDB memory heap is disabled
180316 11:51:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:51:51 InnoDB: Compressed tables use zlib 1.2.8
180316 11:51:51 InnoDB: Using Linux native AIO
180316 11:51:51 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:51:51 InnoDB: Completed initialization of buffer pool
180316 11:51:51 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:51:51  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 44763280113
180316 11:51:52  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:51:52  InnoDB: Waiting for the background threads to start
180316 11:51:53 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:51:53 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:51:53 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:51:53 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:51:53 [Note] Event Scheduler: Loaded 0 events
180316 11:51:53 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:51:53  InnoDB: Assertion failure in thread 139719722583808 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:51:53 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x560295d4ae90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x560295c33cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f13396a5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1338cebc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f1338cef028]
/usr/sbin/mysqld(+0x538b45)[0x560295d8db45]
/usr/sbin/mysqld(+0x5395bb)[0x560295d8e5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x560295e5027f]
/usr/sbin/mysqld(+0x5f1b15)[0x560295e46b15]
/usr/sbin/mysqld(+0x53b3e5)[0x560295d903e5]
/usr/sbin/mysqld(+0x52d10c)[0x560295d8210c]
/usr/sbin/mysqld(+0x5311d3)[0x560295d861d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f133969d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1338db303d]
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.
180316 11:51:53 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:51:53 [Note] Plugin 'FEDERATED' is disabled.
180316 11:51:53 InnoDB: The InnoDB memory heap is disabled
180316 11:51:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:51:53 InnoDB: Compressed tables use zlib 1.2.8
180316 11:51:53 InnoDB: Using Linux native AIO
180316 11:51:53 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:51:54 InnoDB: Completed initialization of buffer pool
180316 11:51:54 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:51:54  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 44763280113
180316 11:51:54  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:51:54  InnoDB: Waiting for the background threads to start
180316 11:51:55 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:51:55 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:51:55 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:51:55 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:51:55 [Note] Event Scheduler: Loaded 0 events
180316 11:51:55 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:51:55  InnoDB: Assertion failure in thread 139768675411712 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:51:55 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x561010186e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x56101006fcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f1e9f6ad330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1e9ecf3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f1e9ecf7028]
/usr/sbin/mysqld(+0x538b45)[0x5610101c9b45]
/usr/sbin/mysqld(+0x5395bb)[0x5610101ca5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x56101028c27f]
/usr/sbin/mysqld(+0x5f1b15)[0x561010282b15]
/usr/sbin/mysqld(+0x53b3e5)[0x5610101cc3e5]
/usr/sbin/mysqld(+0x52d10c)[0x5610101be10c]
/usr/sbin/mysqld(+0x5311d3)[0x5610101c21d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f1e9f6a5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1e9edbb03d]
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.
180316 11:51:56 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 11:51:56 [Note] Plugin 'FEDERATED' is disabled.
180316 11:51:56 InnoDB: The InnoDB memory heap is disabled
180316 11:51:56 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 11:51:56 InnoDB: Compressed tables use zlib 1.2.8
180316 11:51:56 InnoDB: Using Linux native AIO
180316 11:51:56 InnoDB: Initializing buffer pool, size = 512.0M
180316 11:51:56 InnoDB: Completed initialization of buffer pool
180316 11:51:56 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 11:51:56  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 44763280113
180316 11:51:56  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 11:51:56  InnoDB: Waiting for the background threads to start
180316 11:51:57 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 11:51:57 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 11:51:57 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 11:51:57 [Note] Server socket created on IP: '0.0.0.0'.
180316 11:51:57 [Note] Event Scheduler: Loaded 0 events
180316 11:51:57 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 11:51:57  InnoDB: Assertion failure in thread 139738946184960 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:51:57 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55c066993e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55c06687ccd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f17b3745330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f17b2d8bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f17b2d8f028]
/usr/sbin/mysqld(+0x538b45)[0x55c0669d6b45]
/usr/sbin/mysqld(+0x5395bb)[0x55c0669d75bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55c066a9927f]
/usr/sbin/mysqld(+0x5f1b15)[0x55c066a8fb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55c0669d93e5]
/usr/sbin/mysqld(+0x52d10c)[0x55c0669cb10c]
/usr/sbin/mysqld(+0x5311d3)[0x55c0669cf1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f17b373d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f17b2e5303d]
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.
180316 12:05:19 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:05:19 [Note] Plugin 'FEDERATED' is disabled.
180316 12:05:19 InnoDB: The InnoDB memory heap is disabled
180316 12:05:19 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:05:19 InnoDB: Compressed tables use zlib 1.2.8
180316 12:05:19 InnoDB: Using Linux native AIO
180316 12:05:19 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:05:19 InnoDB: Completed initialization of buffer pool
180316 12:05:19 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:05:19  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 44763280113
180316 12:05:19  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:05:20  InnoDB: Waiting for the background threads to start
180316 12:05:21 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:05:21 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:05:21 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:05:21 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:05:21 [Note] Event Scheduler: Loaded 0 events
180316 12:05:21 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:05:21  InnoDB: Assertion failure in thread 139704410294016 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:05:21 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55ccbce46e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55ccbcd2fcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f0fa8f55330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f0fa859bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f0fa859f028]
/usr/sbin/mysqld(+0x538b45)[0x55ccbce89b45]
/usr/sbin/mysqld(+0x5395bb)[0x55ccbce8a5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55ccbcf4c27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55ccbcf42b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55ccbce8c3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55ccbce7e10c]
/usr/sbin/mysqld(+0x5311d3)[0x55ccbce821d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f0fa8f4d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f0fa866303d]
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.
180316 12:05:21 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:05:21 [Note] Plugin 'FEDERATED' is disabled.
180316 12:05:21 InnoDB: The InnoDB memory heap is disabled
180316 12:05:21 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:05:21 InnoDB: Compressed tables use zlib 1.2.8
180316 12:05:21 InnoDB: Using Linux native AIO
180316 12:05:21 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:05:21 InnoDB: Completed initialization of buffer pool
180316 12:05:21 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:05:21  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 44763280113
180316 12:05:21  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:05:22  InnoDB: Waiting for the background threads to start
180316 12:05:23 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:05:23 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:05:23 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:05:23 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:05:23 [Note] Event Scheduler: Loaded 0 events
180316 12:05:23 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:05:23  InnoDB: Assertion failure in thread 140614607816448 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:05:23 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5649a7f83e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5649a7e6ccd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe3952c5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fe39490bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fe39490f028]
/usr/sbin/mysqld(+0x538b45)[0x5649a7fc6b45]
/usr/sbin/mysqld(+0x5395bb)[0x5649a7fc75bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5649a808927f]
/usr/sbin/mysqld(+0x5f1b15)[0x5649a807fb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5649a7fc93e5]
/usr/sbin/mysqld(+0x52d10c)[0x5649a7fbb10c]
/usr/sbin/mysqld(+0x5311d3)[0x5649a7fbf1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe3952bd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe3949d303d]
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.
180316 12:05:23 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:05:23 [Note] Plugin 'FEDERATED' is disabled.
180316 12:05:23 InnoDB: The InnoDB memory heap is disabled
180316 12:05:23 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:05:23 InnoDB: Compressed tables use zlib 1.2.8
180316 12:05:23 InnoDB: Using Linux native AIO
180316 12:05:23 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:05:23 InnoDB: Completed initialization of buffer pool
180316 12:05:23 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:05:23  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 44763280113
180316 12:05:24  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:05:24  InnoDB: Waiting for the background threads to start
180316 12:05:25 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:05:25 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:05:25 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:05:25 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:05:25 [Note] Event Scheduler: Loaded 0 events
180316 12:05:25 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:05:25  InnoDB: Assertion failure in thread 140149656635136 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:05:25 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55838fd1ee90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55838fc07cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f77624fd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f7761b43c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f7761b47028]
/usr/sbin/mysqld(+0x538b45)[0x55838fd61b45]
/usr/sbin/mysqld(+0x5395bb)[0x55838fd625bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55838fe2427f]
/usr/sbin/mysqld(+0x5f1b15)[0x55838fe1ab15]
/usr/sbin/mysqld(+0x53b3e5)[0x55838fd643e5]
/usr/sbin/mysqld(+0x52d10c)[0x55838fd5610c]
/usr/sbin/mysqld(+0x5311d3)[0x55838fd5a1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f77624f5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f7761c0b03d]
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.
180316 12:10:00 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:10:00 [Note] Plugin 'FEDERATED' is disabled.
180316 12:10:00 InnoDB: The InnoDB memory heap is disabled
180316 12:10:00 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:10:00 InnoDB: Compressed tables use zlib 1.2.8
180316 12:10:00 InnoDB: Using Linux native AIO
180316 12:10:00 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:10:00 InnoDB: Completed initialization of buffer pool
180316 12:10:00 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:10:00  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 44763280113
180316 12:10:00  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:10:00  InnoDB: Waiting for the background threads to start
180316 12:10:01 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:10:01 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:10:01 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:10:01 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:10:01 [Note] Event Scheduler: Loaded 0 events
180316 12:10:01 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:10:01  InnoDB: Assertion failure in thread 139935960565504 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:10:01 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55cf8a57ce90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55cf8a465cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f459251d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f4591b63c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f4591b67028]
/usr/sbin/mysqld(+0x538b45)[0x55cf8a5bfb45]
/usr/sbin/mysqld(+0x5395bb)[0x55cf8a5c05bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55cf8a68227f]
/usr/sbin/mysqld(+0x5f1b15)[0x55cf8a678b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55cf8a5c23e5]
/usr/sbin/mysqld(+0x52d10c)[0x55cf8a5b410c]
/usr/sbin/mysqld(+0x5311d3)[0x55cf8a5b81d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f4592515184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f4591c2b03d]
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.
180316 12:10:02 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:10:02 [Note] Plugin 'FEDERATED' is disabled.
180316 12:10:02 InnoDB: The InnoDB memory heap is disabled
180316 12:10:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:10:02 InnoDB: Compressed tables use zlib 1.2.8
180316 12:10:02 InnoDB: Using Linux native AIO
180316 12:10:02 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:10:02 InnoDB: Completed initialization of buffer pool
180316 12:10:02 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:10:02  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 44763280113
180316 12:10:02  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:10:02  InnoDB: Waiting for the background threads to start
180316 12:10:03 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:10:03 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:10:03 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:10:03 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:10:03 [Note] Event Scheduler: Loaded 0 events
180316 12:10:03 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:10:03  InnoDB: Assertion failure in thread 139991548151552 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:10:03 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x560902ff9e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x560902ee2cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f5299f95330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f52995dbc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f52995df028]
/usr/sbin/mysqld(+0x538b45)[0x56090303cb45]
/usr/sbin/mysqld(+0x5395bb)[0x56090303d5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5609030ff27f]
/usr/sbin/mysqld(+0x5f1b15)[0x5609030f5b15]
/usr/sbin/mysqld(+0x53b3e5)[0x56090303f3e5]
/usr/sbin/mysqld(+0x52d10c)[0x56090303110c]
/usr/sbin/mysqld(+0x5311d3)[0x5609030351d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f5299f8d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f52996a303d]
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.
180316 12:10:04 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:10:04 [Note] Plugin 'FEDERATED' is disabled.
180316 12:10:04 InnoDB: The InnoDB memory heap is disabled
180316 12:10:04 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:10:04 InnoDB: Compressed tables use zlib 1.2.8
180316 12:10:04 InnoDB: Using Linux native AIO
180316 12:10:04 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:10:04 InnoDB: Completed initialization of buffer pool
180316 12:10:04 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:10:04  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 44763280113
180316 12:10:04  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:10:04  InnoDB: Waiting for the background threads to start
180316 12:10:05 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:10:05 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:10:05 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:10:05 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:10:05 [Note] Event Scheduler: Loaded 0 events
180316 12:10:05 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:10:05  InnoDB: Assertion failure in thread 139804742252288 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:10:05 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x560ce2747e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x560ce2630cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f271bac5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f271b10bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f271b10f028]
/usr/sbin/mysqld(+0x538b45)[0x560ce278ab45]
/usr/sbin/mysqld(+0x5395bb)[0x560ce278b5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x560ce284d27f]
/usr/sbin/mysqld(+0x5f1b15)[0x560ce2843b15]
/usr/sbin/mysqld(+0x53b3e5)[0x560ce278d3e5]
/usr/sbin/mysqld(+0x52d10c)[0x560ce277f10c]
/usr/sbin/mysqld(+0x5311d3)[0x560ce27831d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f271babd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f271b1d303d]
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.
180316 12:17:36 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:17:36 [Note] Plugin 'FEDERATED' is disabled.
180316 12:17:36 InnoDB: The InnoDB memory heap is disabled
180316 12:17:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:17:36 InnoDB: Compressed tables use zlib 1.2.8
180316 12:17:36 InnoDB: Using Linux native AIO
180316 12:17:36 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:17:36 InnoDB: Completed initialization of buffer pool
180316 12:17:36 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:17:36  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 44763280113
180316 12:17:36  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:17:37  InnoDB: Waiting for the background threads to start
180316 12:17:38 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:17:38 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:17:38 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:17:38 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:17:38 [Note] Event Scheduler: Loaded 0 events
180316 12:17:38 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:17:38  InnoDB: Assertion failure in thread 139724308059904 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:17:38 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x559ef3b82e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x559ef3a6bcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f144ac25330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f144a26bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f144a26f028]
/usr/sbin/mysqld(+0x538b45)[0x559ef3bc5b45]
/usr/sbin/mysqld(+0x5395bb)[0x559ef3bc65bb]
/usr/sbin/mysqld(+0x5fb27f)[0x559ef3c8827f]
/usr/sbin/mysqld(+0x5f1b15)[0x559ef3c7eb15]
/usr/sbin/mysqld(+0x53b3e5)[0x559ef3bc83e5]
/usr/sbin/mysqld(+0x52d10c)[0x559ef3bba10c]
/usr/sbin/mysqld(+0x5311d3)[0x559ef3bbe1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f144ac1d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f144a33303d]
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.
180316 12:17:38 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:17:38 [Note] Plugin 'FEDERATED' is disabled.
180316 12:17:38 InnoDB: The InnoDB memory heap is disabled
180316 12:17:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:17:38 InnoDB: Compressed tables use zlib 1.2.8
180316 12:17:38 InnoDB: Using Linux native AIO
180316 12:17:38 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:17:38 InnoDB: Completed initialization of buffer pool
180316 12:17:38 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:17:38  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 44763280113
180316 12:17:38  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:17:39  InnoDB: Waiting for the background threads to start
180316 12:17:40 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:17:40 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:17:40 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:17:40 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:17:40 [Note] Event Scheduler: Loaded 0 events
180316 12:17:40 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:17:40  InnoDB: Assertion failure in thread 140084832327424 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:17:40 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x560c3e5abe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x560c3e494cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f683bb1d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f683b163c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f683b167028]
/usr/sbin/mysqld(+0x538b45)[0x560c3e5eeb45]
/usr/sbin/mysqld(+0x5395bb)[0x560c3e5ef5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x560c3e6b127f]
/usr/sbin/mysqld(+0x5f1b15)[0x560c3e6a7b15]
/usr/sbin/mysqld(+0x53b3e5)[0x560c3e5f13e5]
/usr/sbin/mysqld(+0x52d10c)[0x560c3e5e310c]
/usr/sbin/mysqld(+0x5311d3)[0x560c3e5e71d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f683bb15184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f683b22b03d]
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.
180316 12:17:40 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 12:17:40 [Note] Plugin 'FEDERATED' is disabled.
180316 12:17:40 InnoDB: The InnoDB memory heap is disabled
180316 12:17:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 12:17:40 InnoDB: Compressed tables use zlib 1.2.8
180316 12:17:40 InnoDB: Using Linux native AIO
180316 12:17:40 InnoDB: Initializing buffer pool, size = 512.0M
180316 12:17:40 InnoDB: Completed initialization of buffer pool
180316 12:17:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 12:17:40  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 44763280113
180316 12:17:40  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 12:17:41  InnoDB: Waiting for the background threads to start
180316 12:17:42 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 12:17:42 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 12:17:42 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 12:17:42 [Note] Server socket created on IP: '0.0.0.0'.
180316 12:17:42 [Note] Event Scheduler: Loaded 0 events
180316 12:17:42 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 12:17:42  InnoDB: Assertion failure in thread 140093494908672 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:17:42 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55db69bcee90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55db69ab7cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f6a4e9d5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f6a4e01bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f6a4e01f028]
/usr/sbin/mysqld(+0x538b45)[0x55db69c11b45]
/usr/sbin/mysqld(+0x5395bb)[0x55db69c125bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55db69cd427f]
/usr/sbin/mysqld(+0x5f1b15)[0x55db69ccab15]
/usr/sbin/mysqld(+0x53b3e5)[0x55db69c143e5]
/usr/sbin/mysqld(+0x52d10c)[0x55db69c0610c]
/usr/sbin/mysqld(+0x5311d3)[0x55db69c0a1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f6a4e9cd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6a4e0e303d]
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.
180316 13:35:53 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:35:53 [Note] Plugin 'FEDERATED' is disabled.
180316 13:35:53 InnoDB: The InnoDB memory heap is disabled
180316 13:35:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:35:53 InnoDB: Compressed tables use zlib 1.2.8
180316 13:35:53 InnoDB: Using Linux native AIO
180316 13:35:53 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:35:53 InnoDB: Completed initialization of buffer pool
180316 13:35:53 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:35:53  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 44763280113
180316 13:35:53  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:35:53  InnoDB: Waiting for the background threads to start
180316 13:35:54 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:35:54 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:35:54 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:35:54 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:35:54 [Note] Event Scheduler: Loaded 0 events
180316 13:35:54 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:35:54  InnoDB: Assertion failure in thread 140500078130944 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:35:54 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x56338da4be90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x56338d934cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fc8ecb05330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fc8ec14bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fc8ec14f028]
/usr/sbin/mysqld(+0x538b45)[0x56338da8eb45]
/usr/sbin/mysqld(+0x5395bb)[0x56338da8f5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x56338db5127f]
/usr/sbin/mysqld(+0x5f1b15)[0x56338db47b15]
/usr/sbin/mysqld(+0x53b3e5)[0x56338da913e5]
/usr/sbin/mysqld(+0x52d10c)[0x56338da8310c]
/usr/sbin/mysqld(+0x5311d3)[0x56338da871d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fc8ecafd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc8ec21303d]
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.
180316 13:35:55 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:35:55 [Note] Plugin 'FEDERATED' is disabled.
180316 13:35:55 InnoDB: The InnoDB memory heap is disabled
180316 13:35:55 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:35:55 InnoDB: Compressed tables use zlib 1.2.8
180316 13:35:55 InnoDB: Using Linux native AIO
180316 13:35:55 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:35:55 InnoDB: Completed initialization of buffer pool
180316 13:35:55 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:35:55  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 44763280113
180316 13:35:55  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:35:56  InnoDB: Waiting for the background threads to start
180316 13:35:57 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:35:57 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:35:57 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:35:57 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:35:57 [Note] Event Scheduler: Loaded 0 events
180316 13:35:57 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:35:57  InnoDB: Assertion failure in thread 140088019035904 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:35:57 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55fb56530e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55fb56419cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f68f9a0d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f68f9053c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f68f9057028]
/usr/sbin/mysqld(+0x538b45)[0x55fb56573b45]
/usr/sbin/mysqld(+0x5395bb)[0x55fb565745bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55fb5663627f]
/usr/sbin/mysqld(+0x5f1b15)[0x55fb5662cb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55fb565763e5]
/usr/sbin/mysqld(+0x52d10c)[0x55fb5656810c]
/usr/sbin/mysqld(+0x5311d3)[0x55fb5656c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f68f9a05184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f68f911b03d]
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.
180316 13:35:57 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:35:57 [Note] Plugin 'FEDERATED' is disabled.
180316 13:35:57 InnoDB: The InnoDB memory heap is disabled
180316 13:35:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:35:57 InnoDB: Compressed tables use zlib 1.2.8
180316 13:35:57 InnoDB: Using Linux native AIO
180316 13:35:57 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:35:57 InnoDB: Completed initialization of buffer pool
180316 13:35:57 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:35:57  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 44763280113
180316 13:35:57  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:35:58  InnoDB: Waiting for the background threads to start
180316 13:35:59 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:35:59 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:35:59 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:35:59 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:35:59 [Note] Event Scheduler: Loaded 0 events
180316 13:35:59 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:35:59  InnoDB: Assertion failure in thread 140134716536576 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:35:59 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5584c5163e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5584c504ccd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f73efe95330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f73ef4dbc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f73ef4df028]
/usr/sbin/mysqld(+0x538b45)[0x5584c51a6b45]
/usr/sbin/mysqld(+0x5395bb)[0x5584c51a75bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5584c526927f]
/usr/sbin/mysqld(+0x5f1b15)[0x5584c525fb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5584c51a93e5]
/usr/sbin/mysqld(+0x52d10c)[0x5584c519b10c]
/usr/sbin/mysqld(+0x5311d3)[0x5584c519f1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f73efe8d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f73ef5a303d]
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.
180316 13:39:22 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:39:22 [Note] Plugin 'FEDERATED' is disabled.
180316 13:39:22 InnoDB: The InnoDB memory heap is disabled
180316 13:39:22 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:39:22 InnoDB: Compressed tables use zlib 1.2.8
180316 13:39:22 InnoDB: Using Linux native AIO
180316 13:39:23 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:39:23 InnoDB: Completed initialization of buffer pool
180316 13:39:23 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:39:23  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 44763280113
180316 13:39:23  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:39:23  InnoDB: Waiting for the background threads to start
180316 13:39:24 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:39:24 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:39:24 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:39:24 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:39:24 [Note] Event Scheduler: Loaded 0 events
180316 13:39:24 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:39:24  InnoDB: Assertion failure in thread 140196783843072 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:39:24 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55911980fe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5591196f8cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f825b4e5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f825ab2bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f825ab2f028]
/usr/sbin/mysqld(+0x538b45)[0x559119852b45]
/usr/sbin/mysqld(+0x5395bb)[0x5591198535bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55911991527f]
/usr/sbin/mysqld(+0x5f1b15)[0x55911990bb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5591198553e5]
/usr/sbin/mysqld(+0x52d10c)[0x55911984710c]
/usr/sbin/mysqld(+0x5311d3)[0x55911984b1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f825b4dd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f825abf303d]
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.
180316 13:39:25 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:39:25 [Note] Plugin 'FEDERATED' is disabled.
180316 13:39:25 InnoDB: The InnoDB memory heap is disabled
180316 13:39:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:39:25 InnoDB: Compressed tables use zlib 1.2.8
180316 13:39:25 InnoDB: Using Linux native AIO
180316 13:39:25 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:39:25 InnoDB: Completed initialization of buffer pool
180316 13:39:25 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:39:25  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 44763280113
180316 13:39:25  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:39:25  InnoDB: Waiting for the background threads to start
180316 13:39:26 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:39:26 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:39:26 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:39:26 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:39:26 [Note] Event Scheduler: Loaded 0 events
180316 13:39:26 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:39:26  InnoDB: Assertion failure in thread 139630653466368 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:39:26 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55aebe551e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55aebe43acd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7efe8aa25330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7efe8a06bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7efe8a06f028]
/usr/sbin/mysqld(+0x538b45)[0x55aebe594b45]
/usr/sbin/mysqld(+0x5395bb)[0x55aebe5955bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55aebe65727f]
/usr/sbin/mysqld(+0x5f1b15)[0x55aebe64db15]
/usr/sbin/mysqld(+0x53b3e5)[0x55aebe5973e5]
/usr/sbin/mysqld(+0x52d10c)[0x55aebe58910c]
/usr/sbin/mysqld(+0x5311d3)[0x55aebe58d1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7efe8aa1d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7efe8a13303d]
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.
180316 13:39:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:39:27 [Note] Plugin 'FEDERATED' is disabled.
180316 13:39:27 InnoDB: The InnoDB memory heap is disabled
180316 13:39:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:39:27 InnoDB: Compressed tables use zlib 1.2.8
180316 13:39:27 InnoDB: Using Linux native AIO
180316 13:39:27 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:39:27 InnoDB: Completed initialization of buffer pool
180316 13:39:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:39:27  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 44763280113
180316 13:39:27  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:39:27  InnoDB: Waiting for the background threads to start
180316 13:39:28 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:39:28 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:39:28 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:39:28 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:39:28 [Note] Event Scheduler: Loaded 0 events
180316 13:39:28 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:39:28  InnoDB: Assertion failure in thread 140295132366592 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:39:28 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55664e946e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55664e82fcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f9934fad330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f99345f3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f99345f7028]
/usr/sbin/mysqld(+0x538b45)[0x55664e989b45]
/usr/sbin/mysqld(+0x5395bb)[0x55664e98a5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55664ea4c27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55664ea42b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55664e98c3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55664e97e10c]
/usr/sbin/mysqld(+0x5311d3)[0x55664e9821d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f9934fa5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f99346bb03d]
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.
180316 13:57:40 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:57:40 [Note] Plugin 'FEDERATED' is disabled.
180316 13:57:40 InnoDB: The InnoDB memory heap is disabled
180316 13:57:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:57:40 InnoDB: Compressed tables use zlib 1.2.8
180316 13:57:40 InnoDB: Using Linux native AIO
180316 13:57:40 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:57:40 InnoDB: Completed initialization of buffer pool
180316 13:57:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:57:40  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 44763280113
180316 13:57:40  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:57:40  InnoDB: Waiting for the background threads to start
180316 13:57:41 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:57:41 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:57:41 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:57:41 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:57:41  InnoDB: Assertion failure in thread 139751592032000 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:57:41 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=4194304
read_buffer_size=65536
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 = 324749 K  bytes of memory
180316 13:57:41 [Note] Event Scheduler: Loaded 0 events
Hope that's ok; if not, decrease some variables in the equation.

180316 13:57:41 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x561323715e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5613235fecd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f1ab38dd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f1ab2f23c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f1ab2f27028]
/usr/sbin/mysqld(+0x538b45)[0x561323758b45]
/usr/sbin/mysqld(+0x5395bb)[0x5613237595bb]
/usr/sbin/mysqld(+0x5fb27f)[0x56132381b27f]
/usr/sbin/mysqld(+0x5f1b15)[0x561323811b15]
/usr/sbin/mysqld(+0x53b3e5)[0x56132375b3e5]
/usr/sbin/mysqld(+0x52d10c)[0x56132374d10c]
/usr/sbin/mysqld(+0x5311d3)[0x5613237511d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f1ab38d5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1ab2feb03d]
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.
180316 13:57:42 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:57:42 [Note] Plugin 'FEDERATED' is disabled.
180316 13:57:42 InnoDB: The InnoDB memory heap is disabled
180316 13:57:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:57:42 InnoDB: Compressed tables use zlib 1.2.8
180316 13:57:42 InnoDB: Using Linux native AIO
180316 13:57:42 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:57:42 InnoDB: Completed initialization of buffer pool
180316 13:57:42 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:57:42  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 44763280113
180316 13:57:42  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:57:43  InnoDB: Waiting for the background threads to start
180316 13:57:44 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:57:44 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:57:44 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:57:44 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:57:44 [Note] Event Scheduler: Loaded 0 events
180316 13:57:44 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:57:44  InnoDB: Assertion failure in thread 140651433797376 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:57:44 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5557df0e8e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5557defd1cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fec27dad330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fec273f3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fec273f7028]
/usr/sbin/mysqld(+0x538b45)[0x5557df12bb45]
/usr/sbin/mysqld(+0x5395bb)[0x5557df12c5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5557df1ee27f]
/usr/sbin/mysqld(+0x5f1b15)[0x5557df1e4b15]
/usr/sbin/mysqld(+0x53b3e5)[0x5557df12e3e5]
/usr/sbin/mysqld(+0x52d10c)[0x5557df12010c]
/usr/sbin/mysqld(+0x5311d3)[0x5557df1241d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fec27da5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fec274bb03d]
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.
180316 13:57:44 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:57:44 [Note] Plugin 'FEDERATED' is disabled.
180316 13:57:44 InnoDB: The InnoDB memory heap is disabled
180316 13:57:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:57:44 InnoDB: Compressed tables use zlib 1.2.8
180316 13:57:44 InnoDB: Using Linux native AIO
180316 13:57:44 InnoDB: Initializing buffer pool, size = 512.0M
180316 13:57:44 InnoDB: Completed initialization of buffer pool
180316 13:57:44 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:57:44  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 44763280113
180316 13:57:44  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:57:45  InnoDB: Waiting for the background threads to start
180316 13:57:46 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:57:46 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 13:57:46 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 13:57:46 [Note] Server socket created on IP: '0.0.0.0'.
180316 13:57:46 [Note] Event Scheduler: Loaded 0 events
180316 13:57:46 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:57:46  InnoDB: Assertion failure in thread 139839792449280 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:57:46 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55a681fd0e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55a681eb9cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f2f30965330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f2f2ffabc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f2f2ffaf028]
/usr/sbin/mysqld(+0x538b45)[0x55a682013b45]
/usr/sbin/mysqld(+0x5395bb)[0x55a6820145bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55a6820d627f]
/usr/sbin/mysqld(+0x5f1b15)[0x55a6820ccb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55a6820163e5]
/usr/sbin/mysqld(+0x52d10c)[0x55a68200810c]
/usr/sbin/mysqld(+0x5311d3)[0x55a68200c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f2f3095d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2f3007303d]
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.
180316 13:59:27 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:59:27 [Note] Plugin 'FEDERATED' is disabled.
180316 13:59:27 InnoDB: The InnoDB memory heap is disabled
180316 13:59:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:59:27 InnoDB: Compressed tables use zlib 1.2.8
180316 13:59:27 InnoDB: Using Linux native AIO
180316 13:59:27 InnoDB: Initializing buffer pool, size = 128.0M
180316 13:59:27 InnoDB: Completed initialization of buffer pool
180316 13:59:27 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:59:27  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 44763280113
180316 13:59:27  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:59:28  InnoDB: Waiting for the background threads to start
180316 13:59:29 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:59:29 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
180316 13:59:29 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
180316 13:59:29 [Note] Server socket created on IP: '127.0.0.1'.
180316 13:59:29  InnoDB: Assertion failure in thread 139841299797760 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:59:29 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=268435456
read_buffer_size=131072
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 = 592461 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...
180316 13:59:29 [Note] Event Scheduler: Loaded 0 events
180316 13:59:29 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5653f3b2fe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5653f3a18cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f2f89515330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f2f88b5bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f2f88b5f028]
/usr/sbin/mysqld(+0x538b45)[0x5653f3b72b45]
/usr/sbin/mysqld(+0x5395bb)[0x5653f3b735bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5653f3c3527f]
/usr/sbin/mysqld(+0x5f1b15)[0x5653f3c2bb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5653f3b753e5]
/usr/sbin/mysqld(+0x52d10c)[0x5653f3b6710c]
/usr/sbin/mysqld(+0x5311d3)[0x5653f3b6b1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f2f8950d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2f88c2303d]
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.
180316 13:59:29 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:59:29 [Note] Plugin 'FEDERATED' is disabled.
180316 13:59:29 InnoDB: The InnoDB memory heap is disabled
180316 13:59:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:59:29 InnoDB: Compressed tables use zlib 1.2.8
180316 13:59:29 InnoDB: Using Linux native AIO
180316 13:59:29 InnoDB: Initializing buffer pool, size = 128.0M
180316 13:59:29 InnoDB: Completed initialization of buffer pool
180316 13:59:29 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:59:29  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 44763280113
180316 13:59:30  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:59:30  InnoDB: Waiting for the background threads to start
180316 13:59:31 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:59:31 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
180316 13:59:31 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
180316 13:59:31 [Note] Server socket created on IP: '127.0.0.1'.
180316 13:59:31 [Note] Event Scheduler: Loaded 0 events
180316 13:59:31 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:59:31  InnoDB: Assertion failure in thread 140609000900352 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:59:31 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=268435456
read_buffer_size=131072
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 = 592461 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x56535a7ebe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x56535a6d4cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe23c33d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fe23b983c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fe23b987028]
/usr/sbin/mysqld(+0x538b45)[0x56535a82eb45]
/usr/sbin/mysqld(+0x5395bb)[0x56535a82f5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x56535a8f127f]
/usr/sbin/mysqld(+0x5f1b15)[0x56535a8e7b15]
/usr/sbin/mysqld(+0x53b3e5)[0x56535a8313e5]
/usr/sbin/mysqld(+0x52d10c)[0x56535a82310c]
/usr/sbin/mysqld(+0x5311d3)[0x56535a8271d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe23c335184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe23ba4b03d]
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.
180316 13:59:32 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 13:59:32 [Note] Plugin 'FEDERATED' is disabled.
180316 13:59:32 InnoDB: The InnoDB memory heap is disabled
180316 13:59:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 13:59:32 InnoDB: Compressed tables use zlib 1.2.8
180316 13:59:32 InnoDB: Using Linux native AIO
180316 13:59:32 InnoDB: Initializing buffer pool, size = 128.0M
180316 13:59:32 InnoDB: Completed initialization of buffer pool
180316 13:59:32 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 13:59:32  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 44763280113
180316 13:59:32  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 13:59:32  InnoDB: Waiting for the background threads to start
180316 13:59:33 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 13:59:33 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
180316 13:59:33 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
180316 13:59:33 [Note] Server socket created on IP: '127.0.0.1'.
180316 13:59:33 [Note] Event Scheduler: Loaded 0 events
180316 13:59:33 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 13:59:33  InnoDB: Assertion failure in thread 140609535694592 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:59:33 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=268435456
read_buffer_size=131072
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 = 592461 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x557d208cae90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x557d207b3cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fe25a0bd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fe259703c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fe259707028]
/usr/sbin/mysqld(+0x538b45)[0x557d2090db45]
/usr/sbin/mysqld(+0x5395bb)[0x557d2090e5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x557d209d027f]
/usr/sbin/mysqld(+0x5f1b15)[0x557d209c6b15]
/usr/sbin/mysqld(+0x53b3e5)[0x557d209103e5]
/usr/sbin/mysqld(+0x52d10c)[0x557d2090210c]
/usr/sbin/mysqld(+0x5311d3)[0x557d209061d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe25a0b5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe2597cb03d]
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.
180316 14:00:36 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:00:36 [Note] Plugin 'FEDERATED' is disabled.
180316 14:00:36 InnoDB: The InnoDB memory heap is disabled
180316 14:00:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:00:36 InnoDB: Compressed tables use zlib 1.2.8
180316 14:00:36 InnoDB: Using Linux native AIO
180316 14:00:36 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:00:36 InnoDB: Completed initialization of buffer pool
180316 14:00:36 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:00:36  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 44763280113
180316 14:00:36  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:00:37  InnoDB: Waiting for the background threads to start
180316 14:00:38 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:00:38 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:00:38 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:00:38 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:00:38 [Note] Event Scheduler: Loaded 0 events
180316 14:00:38 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:00:38  InnoDB: Assertion failure in thread 140462496712448 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:00:38 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55eb453ede90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55eb452d6cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fc02a3e5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fc029a2bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fc029a2f028]
/usr/sbin/mysqld(+0x538b45)[0x55eb45430b45]
/usr/sbin/mysqld(+0x5395bb)[0x55eb454315bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55eb454f327f]
/usr/sbin/mysqld(+0x5f1b15)[0x55eb454e9b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55eb454333e5]
/usr/sbin/mysqld(+0x52d10c)[0x55eb4542510c]
/usr/sbin/mysqld(+0x5311d3)[0x55eb454291d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fc02a3dd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc029af303d]
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.
180316 14:00:38 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:00:38 [Note] Plugin 'FEDERATED' is disabled.
180316 14:00:38 InnoDB: The InnoDB memory heap is disabled
180316 14:00:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:00:38 InnoDB: Compressed tables use zlib 1.2.8
180316 14:00:38 InnoDB: Using Linux native AIO
180316 14:00:38 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:00:38 InnoDB: Completed initialization of buffer pool
180316 14:00:38 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:00:38  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 44763280113
180316 14:00:38  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:00:39  InnoDB: Waiting for the background threads to start
180316 14:00:40 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:00:40 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:00:40 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:00:40 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:00:40 [Note] Event Scheduler: Loaded 0 events
180316 14:00:40 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:00:40  InnoDB: Assertion failure in thread 140449771661056 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:00:40 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5600cc071e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5600cbf5acd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fbd3420d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fbd33853c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fbd33857028]
/usr/sbin/mysqld(+0x538b45)[0x5600cc0b4b45]
/usr/sbin/mysqld(+0x5395bb)[0x5600cc0b55bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5600cc17727f]
/usr/sbin/mysqld(+0x5f1b15)[0x5600cc16db15]
/usr/sbin/mysqld(+0x53b3e5)[0x5600cc0b73e5]
/usr/sbin/mysqld(+0x52d10c)[0x5600cc0a910c]
/usr/sbin/mysqld(+0x5311d3)[0x5600cc0ad1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fbd34205184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fbd3391b03d]
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.
180316 14:00:40 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:00:40 [Note] Plugin 'FEDERATED' is disabled.
180316 14:00:40 InnoDB: The InnoDB memory heap is disabled
180316 14:00:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:00:40 InnoDB: Compressed tables use zlib 1.2.8
180316 14:00:40 InnoDB: Using Linux native AIO
180316 14:00:40 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:00:40 InnoDB: Completed initialization of buffer pool
180316 14:00:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:00:40  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 44763280113
180316 14:00:40  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:00:41  InnoDB: Waiting for the background threads to start
180316 14:00:42 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:00:42 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:00:42 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:00:42 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:00:42 [Note] Event Scheduler: Loaded 0 events
180316 14:00:42 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:00:42  InnoDB: Assertion failure in thread 140455484307200 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:00:42 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x564e96987e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x564e96870cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fbe884a5330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fbe87aebc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fbe87aef028]
/usr/sbin/mysqld(+0x538b45)[0x564e969cab45]
/usr/sbin/mysqld(+0x5395bb)[0x564e969cb5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x564e96a8d27f]
/usr/sbin/mysqld(+0x5f1b15)[0x564e96a83b15]
/usr/sbin/mysqld(+0x53b3e5)[0x564e969cd3e5]
/usr/sbin/mysqld(+0x52d10c)[0x564e969bf10c]
/usr/sbin/mysqld(+0x5311d3)[0x564e969c31d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fbe8849d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fbe87bb303d]
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.
180316 14:10:57 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:10:57 [Note] Plugin 'FEDERATED' is disabled.
180316 14:10:57 InnoDB: The InnoDB memory heap is disabled
180316 14:10:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:10:57 InnoDB: Compressed tables use zlib 1.2.8
180316 14:10:57 InnoDB: Using Linux native AIO
180316 14:10:57 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:10:57 InnoDB: Completed initialization of buffer pool
180316 14:10:57 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:10:57  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 44763280113
180316 14:10:57  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:10:57  InnoDB: Waiting for the background threads to start
180316 14:10:58 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:10:58 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:10:58 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:10:58 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:10:58 [Note] Event Scheduler: Loaded 0 events
180316 14:10:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:10:58  InnoDB: Assertion failure in thread 140261879441152 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:10:58 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55c118b72e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55c118a5bcd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f918345d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f9182aa3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f9182aa7028]
/usr/sbin/mysqld(+0x538b45)[0x55c118bb5b45]
/usr/sbin/mysqld(+0x5395bb)[0x55c118bb65bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55c118c7827f]
/usr/sbin/mysqld(+0x5f1b15)[0x55c118c6eb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55c118bb83e5]
/usr/sbin/mysqld(+0x52d10c)[0x55c118baa10c]
/usr/sbin/mysqld(+0x5311d3)[0x55c118bae1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f9183455184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f9182b6b03d]
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.
180316 14:10:59 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:10:59 [Note] Plugin 'FEDERATED' is disabled.
180316 14:10:59 InnoDB: The InnoDB memory heap is disabled
180316 14:10:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:10:59 InnoDB: Compressed tables use zlib 1.2.8
180316 14:10:59 InnoDB: Using Linux native AIO
180316 14:10:59 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:10:59 InnoDB: Completed initialization of buffer pool
180316 14:10:59 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:10:59  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 44763280113
180316 14:10:59  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:10:59  InnoDB: Waiting for the background threads to start
180316 14:11:00 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:11:00 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:11:00 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:11:00 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:11:00 [Note] Event Scheduler: Loaded 0 events
180316 14:11:00 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:11:00  InnoDB: Assertion failure in thread 139912194520832 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:11:00 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55751e940e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55751e829cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f400c135330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f400b77bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f400b77f028]
/usr/sbin/mysqld(+0x538b45)[0x55751e983b45]
/usr/sbin/mysqld(+0x5395bb)[0x55751e9845bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55751ea4627f]
/usr/sbin/mysqld(+0x5f1b15)[0x55751ea3cb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55751e9863e5]
/usr/sbin/mysqld(+0x52d10c)[0x55751e97810c]
/usr/sbin/mysqld(+0x5311d3)[0x55751e97c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f400c12d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f400b84303d]
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.
180316 14:11:01 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:11:01 [Note] Plugin 'FEDERATED' is disabled.
180316 14:11:01 InnoDB: The InnoDB memory heap is disabled
180316 14:11:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:11:01 InnoDB: Compressed tables use zlib 1.2.8
180316 14:11:01 InnoDB: Using Linux native AIO
180316 14:11:01 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:11:01 InnoDB: Completed initialization of buffer pool
180316 14:11:01 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:11:01  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 44763280113
180316 14:11:01  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:11:01  InnoDB: Waiting for the background threads to start
180316 14:11:02 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:11:02 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:11:02 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:11:02 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:11:02 [Note] Event Scheduler: Loaded 0 events
180316 14:11:02 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:11:02  InnoDB: Assertion failure in thread 140398819251968 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:11:02 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x555fbbb8ae90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x555fbba73cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fb156bfd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fb156243c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fb156247028]
/usr/sbin/mysqld(+0x538b45)[0x555fbbbcdb45]
/usr/sbin/mysqld(+0x5395bb)[0x555fbbbce5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x555fbbc9027f]
/usr/sbin/mysqld(+0x5f1b15)[0x555fbbc86b15]
/usr/sbin/mysqld(+0x53b3e5)[0x555fbbbd03e5]
/usr/sbin/mysqld(+0x52d10c)[0x555fbbbc210c]
/usr/sbin/mysqld(+0x5311d3)[0x555fbbbc61d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fb156bf5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fb15630b03d]
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.
180316 14:12:05 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:05 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:05 InnoDB: The InnoDB memory heap is disabled
180316 14:12:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:05 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:05 InnoDB: Using Linux native AIO
180316 14:12:05 InnoDB: Initializing buffer pool, size = 16.0M
180316 14:12:05 InnoDB: Completed initialization of buffer pool
180316 14:12:05 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:05  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 44763280113
180316 14:12:05  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:06  InnoDB: Waiting for the background threads to start
180316 14:12:07 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:12:07 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:12:07 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:12:07 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:12:07 [Note] Event Scheduler: Loaded 0 events
180316 14:12:07 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:12:07  InnoDB: Assertion failure in thread 140441353676544 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:12:07 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x560dfa9d8e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x560dfa8c1cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fbb1ffbd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fbb1f603c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fbb1f607028]
/usr/sbin/mysqld(+0x538b45)[0x560dfaa1bb45]
/usr/sbin/mysqld(+0x5395bb)[0x560dfaa1c5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x560dfaade27f]
/usr/sbin/mysqld(+0x5f1b15)[0x560dfaad4b15]
/usr/sbin/mysqld(+0x53b3e5)[0x560dfaa1e3e5]
/usr/sbin/mysqld(+0x52d10c)[0x560dfaa1010c]
/usr/sbin/mysqld(+0x5311d3)[0x560dfaa141d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fbb1ffb5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fbb1f6cb03d]
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.
180316 14:12:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:07 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:07 InnoDB: The InnoDB memory heap is disabled
180316 14:12:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:07 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:07 InnoDB: Using Linux native AIO
180316 14:12:07 InnoDB: Initializing buffer pool, size = 16.0M
180316 14:12:07 InnoDB: Completed initialization of buffer pool
180316 14:12:07 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:07  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 44763280113
180316 14:12:07  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:08  InnoDB: Waiting for the background threads to start
180316 14:12:09 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:12:09 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:12:09 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:12:09 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:12:09 [Note] Event Scheduler: Loaded 0 events
180316 14:12:09 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:12:09  InnoDB: Assertion failure in thread 139901678577408 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:12:09 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55e4040f0e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55e403fd9cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f3d78b95330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f3d781dbc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f3d781df028]
/usr/sbin/mysqld(+0x538b45)[0x55e404133b45]
/usr/sbin/mysqld(+0x5395bb)[0x55e4041345bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55e4041f627f]
/usr/sbin/mysqld(+0x5f1b15)[0x55e4041ecb15]
/usr/sbin/mysqld(+0x53b3e5)[0x55e4041363e5]
/usr/sbin/mysqld(+0x52d10c)[0x55e40412810c]
/usr/sbin/mysqld(+0x5311d3)[0x55e40412c1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f3d78b8d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f3d782a303d]
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.
180316 14:12:09 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:09 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:09 InnoDB: The InnoDB memory heap is disabled
180316 14:12:09 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:09 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:09 InnoDB: Using Linux native AIO
180316 14:12:09 InnoDB: Initializing buffer pool, size = 16.0M
180316 14:12:09 InnoDB: Completed initialization of buffer pool
180316 14:12:09 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:09  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 44763280113
180316 14:12:09  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:10  InnoDB: Waiting for the background threads to start
180316 14:12:11 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:12:11 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:12:11 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:12:11 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:12:11 [Note] Event Scheduler: Loaded 0 events
180316 14:12:11 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:12:11  InnoDB: Assertion failure in thread 139836295620352 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:12:11 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5624f45f9e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5624f44e2cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f2e3d98d330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f2e3cfd3c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f2e3cfd7028]
/usr/sbin/mysqld(+0x538b45)[0x5624f463cb45]
/usr/sbin/mysqld(+0x5395bb)[0x5624f463d5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5624f46ff27f]
/usr/sbin/mysqld(+0x5f1b15)[0x5624f46f5b15]
/usr/sbin/mysqld(+0x53b3e5)[0x5624f463f3e5]
/usr/sbin/mysqld(+0x52d10c)[0x5624f463110c]
/usr/sbin/mysqld(+0x5311d3)[0x5624f46351d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f2e3d985184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2e3d09b03d]
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.
180316 14:12:54 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:54 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:54 InnoDB: The InnoDB memory heap is disabled
180316 14:12:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:54 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:54 InnoDB: Using Linux native AIO
180316 14:12:54 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:12:54 InnoDB: Completed initialization of buffer pool
180316 14:12:55 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:55  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 44763280113
180316 14:12:55  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:55  InnoDB: Waiting for the background threads to start
180316 14:12:56 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:12:56 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:12:56 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:12:56 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:12:56 [Note] Event Scheduler: Loaded 0 events
180316 14:12:56 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:12:56  InnoDB: Assertion failure in thread 139725311002368 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:12:56 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5567a8f3fe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5567a8e28cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f1488f75330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f14885bbc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f14885bf028]
/usr/sbin/mysqld(+0x538b45)[0x5567a8f82b45]
/usr/sbin/mysqld(+0x5395bb)[0x5567a8f835bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5567a904527f]
/usr/sbin/mysqld(+0x5f1b15)[0x5567a903bb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5567a8f853e5]
/usr/sbin/mysqld(+0x52d10c)[0x5567a8f7710c]
/usr/sbin/mysqld(+0x5311d3)[0x5567a8f7b1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f1488f6d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f148868303d]
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.
180316 14:12:57 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:57 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:57 InnoDB: The InnoDB memory heap is disabled
180316 14:12:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:57 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:57 InnoDB: Using Linux native AIO
180316 14:12:57 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:12:57 InnoDB: Completed initialization of buffer pool
180316 14:12:57 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:57  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 44763280113
180316 14:12:57  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:57  InnoDB: Waiting for the background threads to start
180316 14:12:58 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:12:58 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:12:58 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:12:58 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:12:58 [Note] Event Scheduler: Loaded 0 events
180316 14:12:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:12:58  InnoDB: Assertion failure in thread 140104970524416 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:12:58 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x55da936b8e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x55da935a1cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7f6cfa805330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f6cf9e4bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f6cf9e4f028]
/usr/sbin/mysqld(+0x538b45)[0x55da936fbb45]
/usr/sbin/mysqld(+0x5395bb)[0x55da936fc5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x55da937be27f]
/usr/sbin/mysqld(+0x5f1b15)[0x55da937b4b15]
/usr/sbin/mysqld(+0x53b3e5)[0x55da936fe3e5]
/usr/sbin/mysqld(+0x52d10c)[0x55da936f010c]
/usr/sbin/mysqld(+0x5311d3)[0x55da936f41d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7f6cfa7fd184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6cf9f1303d]
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.
180316 14:12:59 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:12:59 [Note] Plugin 'FEDERATED' is disabled.
180316 14:12:59 InnoDB: The InnoDB memory heap is disabled
180316 14:12:59 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:12:59 InnoDB: Compressed tables use zlib 1.2.8
180316 14:12:59 InnoDB: Using Linux native AIO
180316 14:12:59 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:12:59 InnoDB: Completed initialization of buffer pool
180316 14:12:59 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:12:59  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 44763280113
180316 14:12:59  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:12:59  InnoDB: Waiting for the background threads to start
180316 14:13:00 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:13:00 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:13:00 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:13:00 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:13:00 [Note] Event Scheduler: Loaded 0 events
180316 14:13:00 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:13:00  InnoDB: Assertion failure in thread 140437672601344 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:13:00 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x562403290e90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x562403179cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fba64fcd330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fba64613c37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fba64617028]
/usr/sbin/mysqld(+0x538b45)[0x5624032d3b45]
/usr/sbin/mysqld(+0x5395bb)[0x5624032d45bb]
/usr/sbin/mysqld(+0x5fb27f)[0x56240339627f]
/usr/sbin/mysqld(+0x5f1b15)[0x56240338cb15]
/usr/sbin/mysqld(+0x53b3e5)[0x5624032d63e5]
/usr/sbin/mysqld(+0x52d10c)[0x5624032c810c]
/usr/sbin/mysqld(+0x5311d3)[0x5624032cc1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fba64fc5184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fba646db03d]
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.
180316 14:13:01 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:13:01 [Note] Plugin 'FEDERATED' is disabled.
180316 14:13:01 InnoDB: The InnoDB memory heap is disabled
180316 14:13:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:13:01 InnoDB: Compressed tables use zlib 1.2.8
180316 14:13:01 InnoDB: Using Linux native AIO
180316 14:13:01 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:13:01 InnoDB: Completed initialization of buffer pool
180316 14:13:01 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:13:01  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 44763280113
180316 14:13:01  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:13:01  InnoDB: Waiting for the background threads to start
180316 14:13:02 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:13:02 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:13:02 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:13:02 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:13:02 [Note] Event Scheduler: Loaded 0 events
180316 14:13:02 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:13:02  InnoDB: Assertion failure in thread 140675278436096 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:13:02 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x562b145bee90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x562b144a7cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7ff1c3d55330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7ff1c339bc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7ff1c339f028]
/usr/sbin/mysqld(+0x538b45)[0x562b14601b45]
/usr/sbin/mysqld(+0x5395bb)[0x562b146025bb]
/usr/sbin/mysqld(+0x5fb27f)[0x562b146c427f]
/usr/sbin/mysqld(+0x5f1b15)[0x562b146bab15]
/usr/sbin/mysqld(+0x53b3e5)[0x562b146043e5]
/usr/sbin/mysqld(+0x52d10c)[0x562b145f610c]
/usr/sbin/mysqld(+0x5311d3)[0x562b145fa1d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7ff1c3d4d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7ff1c346303d]
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.
180316 14:13:03 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
180316 14:13:03 [Note] Plugin 'FEDERATED' is disabled.
180316 14:13:03 InnoDB: The InnoDB memory heap is disabled
180316 14:13:03 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180316 14:13:03 InnoDB: Compressed tables use zlib 1.2.8
180316 14:13:03 InnoDB: Using Linux native AIO
180316 14:13:03 InnoDB: Initializing buffer pool, size = 512.0M
180316 14:13:03 InnoDB: Completed initialization of buffer pool
180316 14:13:03 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 44761436890
180316 14:13:03  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 44763280113
180316 14:13:03  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
180316 14:13:03  InnoDB: Waiting for the background threads to start
180316 14:13:04 InnoDB: 5.5.59 started; log sequence number 44763280113
180316 14:13:04 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180316 14:13:04 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180316 14:13:04 [Note] Server socket created on IP: '0.0.0.0'.
180316 14:13:04 [Note] Event Scheduler: Loaded 0 events
180316 14:13:04 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.59-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
180316 14:13:04  InnoDB: Assertion failure in thread 140570773149440 in file trx0purge.c line 843
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:13:04 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=4194304
read_buffer_size=65536
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 = 324749 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...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x20)[0x5573671cbe90]
/usr/sbin/mysqld(handle_fatal_signal+0x3d5)[0x5573670b4cd5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x7fd96e675330]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7fd96dcbbc37]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7fd96dcbf028]
/usr/sbin/mysqld(+0x538b45)[0x55736720eb45]
/usr/sbin/mysqld(+0x5395bb)[0x55736720f5bb]
/usr/sbin/mysqld(+0x5fb27f)[0x5573672d127f]
/usr/sbin/mysqld(+0x5f1b15)[0x5573672c7b15]
/usr/sbin/mysqld(+0x53b3e5)[0x5573672113e5]
/usr/sbin/mysqld(+0x52d10c)[0x55736720310c]
/usr/sbin/mysqld(+0x5311d3)[0x5573672071d3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fd96e66d184]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fd96dd8303d]
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.