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

feat: upgrade

Browse Source
This commit is contained in:
uprightbass360
2025-11-20 02:11:24 -05:00
parent 9deff01441
commit 5f7bdcb7e7
25 changed files with 1502 additions and 777 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
docs/TROUBLESHOOTING.md
View File

@@ -52,8 +52,8 @@ docker exec ac-mysql mysql -u root -p -e "SELECT 1;"
# 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
# 2. Remove the sentinel created after a successful restore (inside the docker volume)
docker run --rm -v mysql-data:/var/lib/mysql-persistent alpine sh -c 'rm -f /var/lib/mysql-persistent/.restore-completed'
# 3. Re-run the import pipeline (either stand-alone or via stage-modules)
docker compose run --rm ac-db-import
# or
@@ -61,6 +61,16 @@ docker compose run --rm ac-db-import
#
# See docs/ADVANCED.md#database-hardening for details on the sentinel workflow and why it's required.
**Permission denied writing to local-storage or storage**
```bash
# Reset ownership/permissions on the shared directories
./scripts/bash/repair-storage-permissions.sh
```
> This script reuses the same helper container as the staging workflow to `chown`
> `storage/`, `local-storage/`, and module metadata paths back to the current
> host UID/GID so tools like `scripts/python/modules.py` can regenerate
> `modules.env` without manual intervention.
# Check database initialization
docker logs ac-db-init
docker logs ac-db-import
@@ -77,31 +87,18 @@ 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
# 3. Re-run the staging workflow
./scripts/bash/stage-modules.sh --yes
# 5. Restart the worldserver container
# 4. 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.
# See docs/DATABASE_MANAGEMENT.md#module-sql-management for details on the 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.
Legacy backups behave the same as new ones now—just rerun `./scripts/bash/stage-modules.sh --yes` after a restore and the updater will apply whatever the database still needs.
**Source rebuild issues**
```bash