问题：
我正在尝试将 44gb 的 SQL 文件导入 Homestead 上的本地计算机（一个 vagrant box，虚拟机）。它一直失败！我导入了同一数据库的 22gb 版本（来自较早的日期），导入正常！
每次我尝试这个 44gb sql 导入时，我都必须销毁/删除 vagrant box 并重新创建它，因为失败后我无法再启动 mysql，而且我绞尽脑汁想找出问题所在。
完整错误日志输出：/var/log/mysql/error.log
> 2020-07-02T06:25:03.951672Z 0 [Warning] TIMESTAMP with implicit
> DEFAULT value is deprecated. Please use
> --explicit_defaults_for_timestamp server option (see documentation for more details). 2020-07-02T06:25:03.952782Z 0 [Note] /usr/sbin/mysqld
> (mysqld 5.7.28-0ubuntu0.18.04.4) starting as process 6756 ...
> 2020-07-02T06:25:03.957298Z 0 [Note] InnoDB: PUNCH HOLE support
> available 2020-07-02T06:25:03.957320Z 0 [Note] InnoDB: Mutexes and
> rw_locks use GCC atomic builtins 2020-07-02T06:25:03.957325Z 0 [Note]
> InnoDB: Uses event mutexes 2020-07-02T06:25:03.957330Z 0 [Note]
> InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
> 2020-07-02T06:25:03.957334Z 0 [Note] InnoDB: Compressed tables use
> zlib 1.2.11 2020-07-02T06:25:03.957339Z 0 [Note] InnoDB: Using Linux
> native AIO 2020-07-02T06:25:03.957536Z 0 [Note] InnoDB: Number of
> pools: 1 2020-07-02T06:25:03.957612Z 0 [Note] InnoDB: Using CPU crc32
> instructions 2020-07-02T06:25:03.960176Z 0 [Note] InnoDB: Initializing
> buffer pool, total size = 128M, instances = 1, chunk size = 128M
> 2020-07-02T06:25:03.972578Z 0 [Note] InnoDB: Completed initialization
> of buffer pool 2020-07-02T06:25:03.973957Z 0 [Note] InnoDB: If the
> mysqld execution user is authorized, page cleaner thread priority can
> be changed. See the man page of setpriority().
> 2020-07-02T06:25:03.985243Z 0 [Note] InnoDB: Highest supported file
> format is Barracuda. 2020-07-02T06:25:03.986077Z 0 [Note] InnoDB: Log
> scan progressed past the checkpoint lsn 81243507772
> 2020-07-02T06:25:04.323062Z 0 [Note] InnoDB: Doing recovery: scanned
> up to log sequence number 81248750592 2020-07-02T06:25:04.698384Z 0
> [Note] InnoDB: Doing recovery: scanned up to log sequence number
> 81253993472 2020-07-02T06:25:05.077431Z 0 [Note] InnoDB: Doing
> recovery: scanned up to log sequence number 81259236352
> 2020-07-02T06:25:05.383167Z 0 [Note] InnoDB: Doing recovery: scanned
> up to log sequence number 81264479232 2020-07-02T06:25:05.720469Z 0
> [Note] InnoDB: Doing recovery: scanned up to log sequence number
> 81269722112 2020-07-02T06:25:06.050976Z 0 [Note] InnoDB: Doing
> recovery: scanned up to log sequence number 81274964992
> 2020-07-02T06:25:06.137325Z 0 [Note] InnoDB: Doing recovery: scanned
> up to log sequence number 81276158388 2020-07-02T06:25:06.140561Z 0
> [Note] InnoDB: Database was not shutdown normally!
> 2020-07-02T06:25:06.140574Z 0 [Note] InnoDB: Starting crash recovery.
> 2020-07-02T06:25:06.160188Z 0 [Note] InnoDB: 1 transaction(s) which
> must be rolled back or cleaned up in total 444 row operations to undo
> 2020-07-02T06:25:06.160206Z 0 [Note] InnoDB: Trx id counter is 47616
> 2020-07-02T06:25:06.160217Z 0 [Note] InnoDB: Starting an apply batch
> of log records to the database... InnoDB: Progress in percent: 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$2020-07-02T06:25:06.770581Z 0 [Note]
> InnoDB: Apply batch completed 2020-07-02T06:25:08.680788Z 0 [Note]
> InnoDB: Removed temporary tablespace data file: "ibtmp1"
> 2020-07-02T06:25:08.680888Z 0 [Note] InnoDB: Creating shared
> tablespace for temporary tables 2020-07-02T06:25:08.681013Z 0 [Note]
> InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the
> file full; Please wait ... 2020-07-02T06:25:08.687079Z 0 [Note]
> InnoDB: Starting in background the rollback of uncommitted
> transactions 2020-07-02T06:25:08.687182Z 0 [Note] InnoDB: Rolling back
> trx with id 47167, 444 rows to undo 2020-07-02T06:25:08.746977Z 0
> [ERROR] [FATAL] InnoDB: fsync() returned EIO, aborting. 2020-07-02
> 06:25:08 0x7fa9926de740 InnoDB: Assertion failure in thread
> 140366282876736 in file ut0ut.cc line 918 InnoDB: We intentionally
> generate a memory trap. InnoDB: Submit a detailed bug report to
> http://bugs.mysql.com. InnoDB: If you get repeated assertion failures
> or crashes, even InnoDB: immediately after the mysqld startup, there
> may be InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB:
> http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery. 06:25:08 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. Attempting to collect some information that
> could help diagnose the problem. As this is a crash and something is
> definitely wrong, the information collection process might fail.
>
> key_buffer_size=16777216 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 =
> 76388 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+0x3b)[0xeaddfb]
如果尝试连接到 mysql：
root@homestead:/etc/mysql/conf.d# mysql -uhomestead -p****
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
我在尝试启动 mysql 时收到的错误：
root@homestead:/etc/mysql/conf.d# service mysql start
Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xe" for details.
root@homestead:/etc/mysql/conf.d# journalctl -xe
Jul 02 09:35:49 homestead kernel: Buffer I/O error on device dm-6, logical block 36059143
Jul 02 09:35:49 homestead kernel: Buffer I/O error on device dm-6, logical block 36059144
Jul 02 09:35:49 homestead kernel: Buffer I/O error on device dm-6, logical block 36059145
Jul 02 09:35:49 homestead kernel: EXT4-fs warning (device dm-6): ext4_end_bio:323: I/O error 3 writing to inode 18 (offset 0 size 4198400 starting block 36060152)
Jul 02 09:35:49 homestead kernel: EXT4-fs warning (device dm-6): ext4_end_bio:323: I/O error 3 writing to inode 18 (offset 0 size 6295552 starting block 36060664)
Jul 02 09:35:49 homestead kernel: EXT4-fs warning (device dm-6): ext4_end_bio:323: I/O error 3 writing to inode 18 (offset 0 size 8388608 starting block 36061176)
Jul 02 09:35:49 homestead kernel: EXT4-fs warning (device dm-6): ext4_end_bio:323: I/O error 3 writing to inode 18 (offset 8388608 size 2101248 starting block 36061688)
Jul 02 09:35:49 homestead kernel: EXT4-fs warning (device dm-6): ext4_end_bio:323: I/O error 3 writing to inode 18 (offset 8388608 size 4194304 starting block 36062200)
Jul 02 09:35:49 homestead mysqld[1012]: Unable to determine if daemon is running: No such file or directory
Jul 02 09:35:49 homestead systemd[1]: mysql.service: Control process exited, code=exited status=1
Jul 02 09:35:49 homestead systemd[1]: mysql.service: Failed with result 'exit-code'.
Jul 02 09:35:49 homestead systemd[1]: Failed to start MySQL Community Server.
MYSQL 配置文件 -/etc/mysql/conf.d 内容：
[mysql] innodb_buffer_pool_size = 4G innodb_log_buffer_size = 256M innodb_log_file_size = 1G innodb_write_io_threads = 16 innodb_flush_log_at_trx_commit = 0
我检查了日志并特别发现这一行可能表明发生了什么，尽管我不知道它意味着什么： [错误] [严重] InnoDB：fsync() 返回 EIO，中止。
我的问题是：
- 什么原因导致 SQL 导入失败？
- 什么原因导致MYSQL服务无法启动？
请注意：
- 我尝试在不同级别运行 innodb 恢复模式，每次“service start mysql”都会出现与上面相同的响应（启动失败）。
- 虚拟机上的 mysql 磁盘驱动器中有足够的磁盘空间
如果你能帮忙，请帮忙！我多次遇到过这个问题。上次我干脆放弃了，但我真的需要一个解决方案，因为我不知道如何恢复我较大的数据库文件备份，因为这种情况一直在发生！
答案1
解决此问题的方法是使用 mysqldump 导出数据库时使用 --hex-blog 标志。只是想发布此信息以防它对其他人有帮助。Blob 字段可能会有问题！