❓ 常见问题
没有其他服务器使用相同的 server-id，为什么还提示 ID 重复并关服？
server-id lobby 已被集群中的其他在线服务器占用，正在关闭服务器。请修改本服 server.yml，为共用数据库的每台服务器设置不同的 server-id
如果确认同步组里没有第二台服务器在使用这个 server-id，那么绝大多数情况下，是这台服务器上一次宕机之后，旧的服务端进程没有被彻底结束，仍然留在后台运行。
插件启动时会向这个 ID 发送探测并等待 3 秒，无人应答就接管残留身份，有进程应答则判定为冲突并关服。而应答探测和续期心跳都不经过 Minecraft 主线程，因此一台主线程已经卡死、控制台不再滚动、在你看来已经崩溃的服务器，只要 JVM 进程还活着，就会照常应答。
换一个新 ID 确实能让服务器启动，但这台服务器会以全新身份加入同步组，上一次运行残留的会话锁不会跟着转移，反而更容易引出数据问题。请先确认进程。
1. 确认是否还有旧进程
心跳每 3 秒续期一次，存活 9 秒。连续查询几次剩余时间，如果不断跳回 9000 附近，说明确实有进程在后台续期；返回 -2 表示键不存在，请直接看最后一节。命令中的数据库编号取自 config.yml 里 redis.url 末尾的 /0：
redis-cli -n 0 PTTL sparrow-sync:server:lobby
再用 ps -ef | grep java（Windows 下用 jps -l）找出多余的那个进程。
Minecraft 的停服流程是先禁用插件，再释放监听端口，之后还要保存世界、等待区块系统和 I/O 线程池收尾。收尾一旦卡住，进程就会在端口早已释放的情况下继续存活。同样，关闭 screen、tmux 窗口或者终端，也不一定会结束 JVM 进程。
2. 结束残留进程并重新启动
先用 kill <PID> 给它一次正常收尾的机会，等待 30 秒左右再检查。如果进程仍在，并且服务端日志已经长时间没有新的输出，再用 kill -9 <PID>（Windows 下为 taskkill /PID <PID> /F）强制结束，注意强制结束不会保存世界和玩家数据。
进程结束后，心跳键会在 9 秒内自动过期，稍等十几秒再启动服务器。成功接管时，插件会在日志目录（默认为 plugins/SparrowSync/logs/）写入一条已接管残留身份的记录。
确认没有残留进程后仍然报错
这种情况下确实存在配置重复。请检查同步组内每台服务器的 plugins/SparrowSync/server.yml，确保 server-id 两两不同。最常见的原因是复制整个服务端目录后忘记修改。
如何在数据库之间迁移数据？
如果想更换 Sparrow Sync 使用的数据库，可以先用 dump_all 导出数据，修改存储配置后，再用 import_all 导入。更换存储类型时也可以这样操作，例如从 MySQL 迁移到 PostgreSQL。
建议为同一同步组的所有服务器开启白名单，并让在线玩家退出后再导出。白名单不会自动踢出已经在线的玩家。迁移完成前保持进入限制，避免玩家继续游玩产生新存档，使导出的数据落后于实际进度。
1. 从原数据库导出
先保留原来的数据库配置，选择一台连接原数据库的服务器，在控制台执行：
/sparrow-sync data dump_all database-migration.zip
等待控制台提示导出完成。文件会保存在 plugins/SparrowSync/snapshot/dump/database-migration.zip，建议先复制一份留作备份，再进行下一步。
2. 切换到新数据库
关闭同一同步组的服务器，修改 config.yml 中的持久化存储类型和连接信息，使其指向新数据库。具体配置方式见安装插件。
同一同步组的服务器都需要一起修改，使用相同的新数据库及表前缀或集合前缀，同时保留各自的 server-id。
3. 向新数据库导入
先启动一台已修改配置的服务器，保持白名单开启，并确认数据库连接成功。将导出的 ZIP 放入这台服务器的 plugins/SparrowSync/snapshot/dump/ 目录，然后在控制台执行：
/sparrow-sync data import_all database-migration.zip
等待控制台输出导入结果。同一同步组共用一个数据库，导入一次即可，不需要每台服务器重复执行。
4. 检查数据并放行玩家
导入成功后，检查玩家的快照列表，再使用测试账号登录，确认数据能够正常加载。确认无误后，启动其余已切换配置的服务器，解除限制并放行玩家。
在完成检查之前，先保留原数据库和导出的 ZIP。如果控制台报告导入失败，请保持进入限制，先根据报错排查问题。