nchebrov/AzerothCore-RealmMaster
1
0
Fork 0
mirror of https://github.com/uprightbass360/AzerothCore-RealmMaster.git synced 2026-02-03 10:53:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

module setup process

Browse Source
This commit is contained in:
uprightbass360
2025-11-17 02:23:53 -05:00
parent ea908dbbcf
commit d3484a3aea
30 changed files with 7685 additions and 430 deletions
Download Patch File Download Diff File Expand all files Collapse all files

57
docs/TROUBLESHOOTING.md
View File

@@ -41,10 +41,67 @@ ls storage/config/mod_*.conf*
# Verify MySQL is running and responsive
docker exec ac-mysql mysql -u root -p -e "SELECT 1;"
# Starting with the 2025-11-17 release the import job checks if
# the runtime tables exist before trusting restoration markers. If you see
# "Restoration marker found, but databases are empty - forcing re-import" in
# `docker logs ac-db-import`, just let the container finish; it will automatically
# clear stale markers and replay the latest backup so the services never boot
# against an empty tmpfs volume. See docs/DATABASE_MANAGEMENT.md#restore-safety-checks--sentinels
# for full details.
# Forcing a fresh import (if schema missing/invalid)
# 1. Stop the stack
docker compose down
# 2. Remove the sentinel created after a successful restore
sudo rm -f local-storage/mysql-data/.restore-completed
# 3. Re-run the import pipeline (either stand-alone or via stage-modules)
docker compose run --rm ac-db-import
# or
./scripts/bash/stage-modules.sh --yes
#
# See docs/ADVANCED.md#database-hardening for details on the sentinel workflow and why it's required.
# Check database initialization
docker logs ac-db-init
docker logs ac-db-import
```
> Need more context on why the sentinel exists or how the restore-aware SQL stage cooperates with backups? See [docs/ADVANCED.md#database-hardening](ADVANCED.md#database-hardening) for the full architecture notes.
**Worldserver restart loop (duplicate module SQL)**
> After a backup restore the ledger snapshot is synced and `.restore-prestaged` is set so the next `./scripts/bash/stage-modules.sh` run recopies EVERY module SQL file into `/azerothcore/data/sql/updates/*` with deterministic names. Check `docker logs ac-worldserver` to confirm it sees those files; the `updates` table still prevents reapplication, but the files remain on disk so the server never complains about missing history.
```bash
# 1. Inspect the worldserver log for errors like
# "Duplicate entry ... MODULE_<module_name>_<file>"
docker logs ac-worldserver
# 2. Remove the staged SQL file that keeps replaying:
docker exec ac-worldserver rm /azerothcore/data/sql/updates/<db>/<filename>.sql
# 3. (Optional) Clean the module SQL ledger so staging rehashes everything
rm -f storage/modules/.modules-meta/module-sql-ledger.txt
# 4. Re-run the staging workflow
./scripts/bash/stage-modules.sh --yes
# 5. Restart the worldserver container
docker compose restart ac-worldserver-playerbots # or the profile you use
# See docs/DATABASE_MANAGEMENT.md#module-sql-management for details on the ledger
# and docs/ADVANCED.md#restore-aware-module-sql for the import workflow.
```
**Legacy backup missing module SQL snapshot**
New backups include `module-sql-ledger.txt` which lets `ac-db-import` automatically restage only the SQL that didn’t ship with the backup. If you restored an older backup you’ll see `No module SQL snapshot found ...` in the import logs and no extra SQL will be staged. That’s intentional to avoid duplicate inserts.
1. Decide if you really need to restage modules (for example you know new modules were added after the backup was taken).
2. Remove the host ledger so the next run copies every SQL file:
```bash
rm -f storage/modules/.modules-meta/module-sql-ledger.txt
```
3. Rerun `./scripts/bash/stage-modules.sh --yes` to restage and restart the stack.
After you take a new backup the snapshot will exist and future restores won’t need this manual step.
**Source rebuild issues**
```bash