问题出现
在学习后端开发的过程中，今天突然发现自己在docker上部署的mysql突然连不上了，
通过docker ps -a 命令查看发现mysql一直出于Restarting状态，重启了mysql容器，也还是没解决问题（下图中hm-mysql处于Restarting状态），于是小小的记录一下解决的方法：
解决过程
当Docker部署的MySQL一直处于Restarting状态时，这通常意味着MySQL容器在启动过程中遇到了问题。这可能是由于配置错误、端口冲突或其他原因导致的。为了解决这个问题，我们需要查看Docker日志以获取更多详细信息，并检查MySQL容器的配置。
通过docker logs -f hm-mysql 命令来查看日志：
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.
2024-07-12 10:59:02+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started.
2024-07-12 10:59:02+08:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2024-07-12 10:59:02+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.0-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2024-07-12T02:59:03.120616Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2024-07-12T02:59:03.338524Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.0) starting as process 1
2024-07-12T02:59:03.350277Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-07-12T02:59:05.197985Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-07-12T02:59:05.440020Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2024-07-12T02:59:05.467112Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
2024-07-12T02:59:05.507320Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: trx0types.h:542:m_rsegs_n < 2 thread 140279654897216
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/8.4/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-07-12T02:59:05Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=353ae40c5329277f3033302aee25ef64367c8a66
Thread pointer: 0x7f9570000df0
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 = 7f9566ffcb00 thread_stack 0x100000
2024-07-12T02:59:05.600161Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-07-12T02:59:05.600219Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-07-12T02:59:05.616580Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
在日志中发现，日志显示了一个问题：
2024-07-12T02:59:05.507320Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: trx0types.h:542:m_rsegs_n < 2 thread 140279654897216
InnoDB 出现了断言失败。这可能是软件错误或者硬件故障导致的。
具体来说，在 InnoDB 中检测到一个违反断言的情况（trx0types.h:542:m_rsegs_n < 2），并提示可能存在表空间损坏，建议参考相关文档进行强制恢复等操作。同时，还提到可能遇到了一个错误，也可能是硬件故障引起的。
于是上网开始查找资料
文章地址：http://www.linuxeye.com/database/2830.html （MySQL意外断电，InnoDB数据库恢复）
分析日志后发现，数据库无法重启的原因是因为ibdata1文件损坏，重启后无法正常恢复。
现在我们就需要跳过恢复步骤，修改my.cnf文件，在my.cnf中的[mysqld]中添加innodb_force_recovery = 6 innodb_purge_threads = 0innodbforcerecovery可以设置为1-6,大的数字包含前面所有数字的影响。
\1. (SRVFORCEIGNORECORRUPT):忽略检查到的corrupt页。
\2. (SRVFORCENOBACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
\3. (SRVFORCENOTRXUNDO):不执行事务回滚操作。
\4. (SRVFORCENOIBUFMERGE):不执行插入缓冲的合并操作。
\5. (SRVFORCENOUNDOLOGSCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
\6. (SRVFORCENOLOG_REDO):不执行前滚的操作。
于是我修改挂载在本地目录mysql/conf下的hm.cnf配置文件，加上上述配置，重启mysql容器后，发现能远程连接上我的mysql容器了，问题解决。
总结
后来回想问题发生的原因，是我之前虚拟机没关闭的情况下就把电脑关机了，导致mysql容器意外断电导致了Innodb的文件损坏，出现了此次问题。
如果后续出现读写问题，数据库需要恢复可以参考个人下面这篇文章：
http://t.csdnimg.cn/SPLV2