服务器坏了，恢复后换了一个目录，重新启动发现mysql启动失败，求指导已解决 悬赏5积分

之前的服务器坏了，将服务器恢复后，把安装目录换了一个路径，直接重启后，提示mysql重启失败，请问如何解决

报错日志如下：

2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: The InnoDB memory heap is disabled
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Compressed tables use zlib 1.2.3.4
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Using SSE crc32 instructions
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Completed initialization of buffer pool
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: Highest supported file format is Barracuda.
2018-06-21  9:34:24 139830307174208 [Note] InnoDB: The log sequence numbers 2115533 and 2115533 in ibdata files do not match the log sequence number 2115543 in the ib_logfiles!
2018-06-21  9:34:24 139830307174208 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: ./mysql/innodb_table_stats.ibd. Cannot open tablespace semaphore/migrations which uses space ID: 1 at filepath: ./semaphore/migrations.ibd
2018-06-21 09:34:24 7f2cc7c9b740  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: Error: could not open single-table tablespace file ./semaphore/migrations.ibd
InnoDB: We do not continue the crash recovery, because the table may become
InnoDB: corrupt if we cannot apply the log records in the InnoDB log to it.
InnoDB: To fix the problem and start mysqld:
InnoDB: 1) If there is a permission problem in the file and mysqld cannot
InnoDB: open the file, you should modify the permissions.
InnoDB: 2) If the table is not needed, or you can restore it from a backup,
InnoDB: then you can remove the .ibd file, and InnoDB will do a normal
InnoDB: crash recovery and ignore that table.
InnoDB: 3) If the file system or the disk is broken, and you cannot remove
InnoDB: the .ibd file, you can set innodb_force_recovery > 0 in my.cnf
InnoDB: and force InnoDB to continue crash recovery here.
180621  9:34:24 [ERROR] 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.

To report this bug, see https://mariadb.com/kb/en/reporting-bugs

We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

Server version: 10.1.22-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 137009 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...