Bitnami MySQL Helm Chart启动探针失败容器无有效日志退出问题求助

• 初始化文件权限异常：你配置init容器以root用户（runAsUser:0）运行，从S3下载的backup.sql文件所有者为root，而Bitnami MySQL容器默认以UID 1001的用户运行，无权限读取/docker-entrypoint-initdb.d目录下的root所有文件，导致初始化流程中断，mysqld进程根本没有启动，自然不会生成socket文件，触发启动探针报错。
• 备份文件存在Aurora专属不兼容内容：Aurora MySQL 5.7虽然核心版本和社区版一致，但自带大量专属系统表、内置账户（如rdsadmin）、专属存储过程，导出的sql中如果包含这些内容，社区版MySQL执行时会直接报错终止初始化，导致mysqld启动失败。
• 启动探针超时：如果你的backup.sql文件体积较大，初始化执行时长超过了Bitnami MySQL Helm Chart默认的启动探针阈值，kubelet会提前杀掉未完成初始化的容器，导致日志输出不完整。

• 修复初始化文件权限：在init容器的执行命令末尾添加权限修正指令，保证MySQL运行用户可读取sql文件，修改后的args配置参考：

args:
- echo "Loading the backup snapshot from S3 ..." &&
  aws s3 cp s3://${BUCKET_NAME}/backup.sql /workdir/backup.sql &&
  chmod 644 /workdir/backup.sql &&
  chown 1001:1001 /workdir/backup.sql

• 清理不兼容的Aurora专属内容：导出备份时添加参数过滤Aurora系统表，避免导入到社区版时报错，导出命令参考：
  mysqldump -h <Aurora访问地址> -u <用户名> -p <数据库名> --ignore-table=mysql.rds_configuration --ignore-table=mysql.rds_heartbeat2 --ignore-table=mysql.rds_global_status_history > backup.sql
  如果已经导出了备份文件，可以手动删除sql文件中所有rdsadmin相关的用户、权限、存储过程语句。
• 调大启动探针阈值：在values.yaml的primary配置下添加探针参数，延长初始化等待时长，适配大文件导入场景，参考配置：

primary:
  startupProbe:
    enabled: true
    initialDelaySeconds: 60
    periodSeconds: 10
    failureThreshold: 30

• 开启调试日志定位问题：如果修改后仍然启动失败，可以添加MySQL参数输出更详细的运行日志，快速定位具体报错：

primary:
  extraFlags: "--log-error-verbosity=3"

内容的提问来源于stack exchange，提问作者Phil Chae