Mysql - Error 2002 after a failed import - mysql

Question

On friday, I stupidly closed my lid when I was doing a large (3gb) database import.
This morning, I opened my mac and it never booted. I had to force a restart. Now, mysql no longer works. I am getting the following error: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Does anyone know a possible solution? I can't access mysql command prompt.
When I try to perform a restart/stop/start of the service, I get the following (thanks!):
**rmason202-> mysqld restart
2014-06-02 10:03:03 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-06-02 10:03:03 9772 [Warning] Setting lower_case_table_names=2 because file system for /usr/local/var/mysql/ is case insensitive
2014-06-02 10:03:03 9772 [Note] Plugin 'FEDERATED' is disabled.
2014-06-02 10:03:03 9772 [Note] InnoDB: The InnoDB memory heap is disabled
2014-06-02 10:03:03 9772 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-06-02 10:03:03 9772 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-06-02 10:03:03 9772 [Note] InnoDB: Using CPU crc32 instructions
2014-06-02 10:03:03 9772 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-06-02 10:03:03 9772 [Note] InnoDB: Completed initialization of buffer pool
2014-06-02 10:03:03 9772 [Note] InnoDB: Highest supported file format is Barracuda.
2014-06-02 10:03:03 9772 [Note] InnoDB: Log scan progressed past the checkpoint lsn 30416376018
2014-06-02 10:03:03 9772 [Note] InnoDB: Database was not shutdown normally!
2014-06-02 10:03:03 9772 [Note] InnoDB: Starting crash recovery.
2014-06-02 10:03:03 9772 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-06-02 10:03:03 9772 [Note] InnoDB: Restoring possible half-written data pages
2014-06-02 10:03:03 9772 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 30421618688
InnoDB: Doing recovery: scanned up to log sequence number 30426861568
InnoDB: Doing recovery: scanned up to log sequence number 30432104448
InnoDB: Doing recovery: scanned up to log sequence number 30437347328
InnoDB: Doing recovery: scanned up to log sequence number 30442590208
InnoDB: Doing recovery: scanned up to log sequence number 30447800979
2014-06-02 10:03:05 9772 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: InnoDB: Error: trying to access page number 480 in space 193870,
InnoDB: space name itrc_dev/interface_ip_addrs,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10.
InnoDB: If you get this error at mysqld startup, please check that
InnoDB: your my.cnf matches the ibdata files that you have in the
InnoDB: MySQL server.
2014-06-02 10:03:05 7fff7c945310 InnoDB: Assertion failure in thread 140735283483408 in file fil0fil.cc line 5423
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
14:03: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=8388608
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 = 68235 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 0x40000
0 mysqld 0x0000000103581769 my_print_stacktrace + 61
1 mysqld 0x00000001033df38e handle_fatal_signal + 696
2 libsystem_platform.dylib 0x00007fff998465aa _sigtramp + 26
3 ??? 0x747265737341203a 0x0 + 8390880602273947706
4 libsystem_c.dylib 0x00007fff99441bba abort + 125
5 mysqld 0x00000001035ff96f _Z6fil_iombmmmmmPvS_ + 1765
6 mysqld 0x00000001035d4bb3 _ZL17buf_read_page_lowP7dberr_tbmmmmxm + 427
7 mysqld 0x00000001035d59d7 _Z19buf_read_recv_pagesmmmPKmm + 403
8 mysqld 0x000000010366299f _Z26recv_apply_hashed_log_recsm + 919
9 mysqld** 0x0000000103664afc _Z36recv_recovery_from_checkpoint_finishv + 40
10 mysqld 0x00000001036c9ef4 _Z34innobase_start_or_create_for_mysqlv + 8969
11 mysqld 0x00000001036359ca _ZL13innobase_initPv + 1983
12 mysqld 0x0000000103326b32 _Z24ha_initialize_handlertonP13st_plugin_int + 75
13 mysqld 0x00000001034858a9 _ZL17plugin_initializeP13st_plugin_int + 92
14 mysqld 0x0000000103485397 _Z11plugin_initPiPPci + 3926
15 mysqld 0x00000001035175b1 _Z11mysqld_mainiPPc + 2655
16 libdyld.dylib 0x00007fff9257b5fd start + 1
17 ??? 0x0000000000000002 0x0 + 2
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.