我之前折腾SonarQube Docker部署时也碰到过一模一样的Lucene索引损坏错误，结合你已经换过全新实例和服务器的情况，基本可以排除硬件问题，大概率是Docker环境配置或者镜像/卷的初始化问题，给你梳理几个可行的排查方向和解决办法：

可能的原因及对应解决步骤 #

1. Docker卷残留损坏数据（最常见） #

即使是全新服务器，第一次启动SonarQube时如果容器意外退出（比如内存不足导致崩溃），会导致sonarqube_data卷里的Elasticsearch索引文件损坏，后续启动就会触发校验和错误。

解决办法：彻底清理所有相关卷后重新启动

# 停止并删除容器，同时删除关联的卷
docker-compose down -v
# 拉取最新的镜像（或者指定稳定版本，避免latest镜像的临时bug）
docker-compose pull
# 重新启动
docker-compose up -d

2. 使用了不稳定的SonarQube镜像版本 #

sonarqube:community标签默认拉取latest版本，有时候最新版本可能存在Elasticsearch初始化的bug，导致索引文件生成异常。

解决办法：指定一个经过验证的稳定版本
修改你的docker-compose.yml中SonarQube的镜像为稳定版本，比如9.9.0-community（这个版本我自己用着很稳定）：

services:
  sonarqube:
    image: sonarqube:9.9.0-community # 替换原有的community标签
    # ...其他配置保持不变

3. 内存不足导致Elasticsearch写入异常 #

SonarQube和内置的Elasticsearch需要足够的内存才能稳定运行，默认的JVM堆内存配置可能不足以支撑初始化过程，导致写入索引时崩溃，进而出现校验和错误。

解决办法：增加JVM内存配置
在docker-compose.yml的sonarqube服务环境变量中添加内存参数：

services:
  sonarqube:
    # ...其他配置
    environment:
      # ...原有JDBC配置
      SONAR_JAVA_OPTS: "-Xmx2G -Xms2G" # 设置堆内存为2G，根据服务器配置调整，至少1G以上
    # 同时添加Elasticsearch需要的文件描述符限制
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

4. 文件系统兼容性问题 #

如果你的服务器使用了非POSIX兼容的文件系统（比如某些网络存储、NTFS挂载等），可能会导致Elasticsearch写入索引文件时出现数据不一致，触发校验和错误。

解决办法：确保使用本地的ext4/XFS等兼容文件系统
检查Docker卷所在的宿主机目录是否使用了兼容的文件系统，尽量避免用网络存储挂载Docker数据目录。

验证步骤 #

按照上述方法修改配置后，启动容器并查看日志：

docker-compose logs -f sonarqube

如果看到SonarQube is up的日志，说明启动成功，问题解决。

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