解决Docker 二次重启 MySQL 8 遇到的一些问题
发布网友
发布时间:10小时前
我来回答
共1个回答
热心网友
时间:2024-12-05 03:48
前些天,因为服务器扩容需求,我们不得不进行断电操作,导致 Docker 需要关闭。今天尝试重启 MySQL 8 的容器时,遇到了一些问题,我特地记录了这一过程,希望能帮助到有类似困扰的读者。
在启动 MySQL 容器时,我们使用了相关指令,看起来启动似乎成功了,然而通过 docker ps 命令查看,却发现并未成功启动 MySQL 容器。我们决定查看日志,以排查问题。在查看了 docker logs 6dc8fa34ff7...e3ed12a1b2f6e0edbc8e6 的输出后,我们发现了问题所在。
从日志中,我们可以看到:lower_case_table_names 参数的设置导致了问题的发生。根据官方文档的理解,如果设置为 0,则表名在磁盘上以原样存储,并进行大小写敏感的比较;如果设置为 1,则表名在磁盘上以小写形式存储,并进行不区分大小写的比较;如果设置为 2,则表名在磁盘上以给定的形式存储,但比较时使用小写形式。这一参数也适用于数据库名称和表别名。详细信息请参见“Identifier Case Sensitivity”部分。在 Linux 和其他类 Unix 系统上,其默认值为 0。在 Windows 系统上,默认值为 1。在 macOS 上,默认值为 2。在 Linux(以及其他类 Unix 系统)上,若设置为 2,则服务器会将其强制为 0。在运行 MySQL 的系统上,若数据目录位于不区分大小写的文件系统(如 Windows 或 macOS)上,不应设置 lower_case_table_names 为 0。这是因为这与组合不支持,在运行 INSERT INTO ... SELECT ... FROM tbl_name 操作时,如果 tbl_name 的大小写不正确,可能会导致挂起状态。使用 MyISAM 时,使用不同大小写的表名可能会导致索引损坏。尝试在 case-insensitive 文件系统上以 --lower_case_table_names=0 启动服务器会打印错误消息并退出。此变量的设置影响了复制过滤选项的大小写敏感性。更多信息请参见“服务器如何评估复制过滤规则”部分。启动服务器时,必须使用与初始化服务器时相同的 lower_case_table_names 设置。因为各种数据字典表字段所使用的连接是由初始化时定义的设置确定的,使用不同的设置重新启动服务器会导致标识符的顺序和比较不一致。因此,在初始化服务器之前,应将 lower_case_table_names 设置为所需的设置。
根据官方文档的说明,我们在 Linux 和其他类 Unix 系统上,其默认值为 0。由于我们在 Linux 系统上运行 MySQL,因此我们需要更改 lower_case_table_names 的设置,使其与数据字典一致,即将其设置为 1。
在解决问题后,我们注意到远程连接时仍然存在问题。在使用 pymysql 连接时,我们也遇到了连接超时的问题。我们首先怀疑 3306 端口是否没有对外开放,于是直接打开了 3306 端口,但发现 3306 端口始终处于开放状态。我们进一步查看了其占用情况,发现并非问题所在。然而,在启动容器时,我们注意到存在一个警告。查阅资料后得知,我们需要开启 IPv4 转发。网络桥接配置完成后,需要开启转发,否则容器启动后将没有网络连接。我们执行了相应的操作,问题得以解决。使用远程连接后,我们成功连接到了 MySQL 容器。