浅念
601451f22b
Overlay ~150 upstream items onto our V8.12 base, preserving trade-pro
theme, registry tests, and design docs. Re-applied our patch set
(discovery/env_for/blocks.css/type-mapping/theme_color/frontend entries,
test_theme_pro_v3 mods) — all anchors survived upstream evolution.
New platform enhancement (fixes upgrade-introduced regression):
multilingual.site_locale now honors settings_json.locale, plus
PUT /api/i18n/sites/{id}/locale — standalone English sites get
<html lang='en'> under the V8.15 locale-rewrite pipeline.
compose: adopt V8.21.3 (image 8.21.3-dev.1, /api/ready probes, MySQL/S3
env) with project name pinned to siteforge-v8-10 (data volumes).
Tests: 356 passed / 11 failed — all 11 confirmed pre-existing in
pristine V8.21.3 on this host (10 upstream Windows env + our build test
now green after locale fix). Patch registry updated in plan doc.
Co-Authored-By: Claude Code <noreply@anthropic.com>
66 lines
6.0 KiB
Markdown
66 lines
6.0 KiB
Markdown
# SiteForge Enterprise V8.18 — 企业底座实现与验收说明
|
||
|
||
> 2026-10-23 · 版本 `8.18.0-dev.1` · **开发集成版（不是生产上线批准）**
|
||
|
||
## 本轮已实施代码
|
||
|
||
1. **PostgreSQL 灾备误操作保护**：当 `SITEFORGE_DATABASE_URL` 指向 PostgreSQL，原 SQLite `python -m app.backup` 立即拒绝执行，不会错误创建一份空 SQLite 备份。
|
||
2. **PostgreSQL 专属离线灾备**：`app.pg_disaster_recovery` + `scripts/pg_disaster_recovery.py` 使用客户端 `pg_dump` custom 格式、`pg_restore --list`、媒体/构建文件清单和 SHA-256 校验，最后原子更名 ZIP；离线校验无需数据库。恢复仅允许**空 PostgreSQL 数据库 + 不存在的数据目录**，使用单事务 `pg_restore`，不覆盖线上站点。机密信息不会放在子进程命令行参数中。
|
||
3. **SQLite→PostgreSQL 内容迁移**：`app.sqlite_pg_transfer` + `scripts/migrate_sqlite_to_postgres.py`：SQLite 在线备份 API 制作快照（前提仍要求业务停写），按外键顺序处理当前 51 张表，检查列覆盖和目标表为空（迁移登记表例外、必须 checksum 匹配），单 PostgreSQL 事务写入，逐表行数与 SHA-256 对账。目标库必须在停机维护期间运行全套初始化。
|
||
4. **发布状态不确定时防重复执行**：`remote_deploy`/`remote_rollback` 在 Worker 租约过期、网络失败、超时或运行中取消后标记失败并要求管理员核对远端指针，禁止自动重试外部副作用。普通构建仍保留原有重试能力。
|
||
5. **CI 验收扩充**：新增隔离 PostgreSQL 数据迁移端到端验证脚本；本地测试使用模拟 PG 协议和工具进程，并且严格区分模拟与真实 PG 证据。
|
||
|
||
## 一、禁止直接更新生产卷
|
||
|
||
新建独立测试环境，备份 V8.17 的数据库和共享存储。切换 SQLite→PG 是**运维迁移**而非自动覆盖 `.env`：不能仅把 SQLite 环境变量指向 PostgreSQL 后直接运行现有容器。系统代码、数据库、媒体目录和 `published` 卷是不同组件，必须统一维护窗口。
|
||
|
||
## 二、PostgreSQL 备份（维护窗口）
|
||
|
||
以下命令在有 `pg_dump`、`pg_restore`、`psql` 的管理主机执行；客户端版本应不低于数据库服务器主版本（示例 PG 16）。须先停 Web 和所有 Worker，阻止数据库写入与媒体上传。
|
||
|
||
```bash
|
||
export SITEFORGE_DATABASE_URL='postgresql://backup_user:***@db-host:5432/siteforge?sslmode=verify-full&sslrootcert=/secure/ca.pem'
|
||
python scripts/pg_disaster_recovery.py backup --data /path/to/siteforge-data --output /external/backup-20261023.zip --confirmed-offline
|
||
python scripts/pg_disaster_recovery.py verify /external/backup-20261023.zip
|
||
```
|
||
|
||
不要把真实密码写到共享日志或 shell 历史；上例为占位符。建议使用安全的环境注入或管理员端凭据文件。`manifest.json` 的 SHA-256 证明读取后的完整性，**不证明备份来自可信发布者，也不代表进行了加密**。备份需转移到其他设备，配置保留策略和访问限制；`published` 独立卷还需要独立备份。
|
||
|
||
恢复必须**事先创建空 PostgreSQL 目标库**和**不存在的共享数据目录**，并使用新测试实例恢复验证：
|
||
|
||
```bash
|
||
python scripts/pg_disaster_recovery.py restore-new /external/backup-20261023.zip --data /path/to/new-storage --confirmed-offline
|
||
```
|
||
|
||
不会自动切换服务或覆盖目标数据库。恢复后需再跑 `/api/ready`、内容/媒体、构建和发布链路的 E2E。数据库恢复和文件重命名跨系统不属于一个原子事务，失败时目标必须保持隔离，直到人工对账完成。
|
||
|
||
## 三、SQLite 数据升级到 PostgreSQL（数据库部分）
|
||
|
||
1. **停站**：关闭 Web、所有 Worker、文件上传与计划任务，确保 SQLite 和媒体不再变动。
|
||
2. **双重备份**：运行既有 SQLite 备份与源文件目录副本；将外部备份单独存储。
|
||
3. **全新 PostgreSQL 库**：使用独立新库运行完整 SiteForge schema 初始化；允许 ledger 的既定行，其他业务表必须为空。
|
||
4. **迁移数据**：
|
||
|
||
```bash
|
||
export SITEFORGE_DATABASE_URL='postgresql://migration_user:***@db-host:5432/siteforge_stage?sslmode=require'
|
||
python scripts/migrate_sqlite_to_postgres.py --source /path/to/old/siteforge.sqlite3 --confirmed-offline --report /external/migration-evidence.json
|
||
```
|
||
|
||
5. **同步外部文件**：`/data/media`、`legacy`、`builds`、`archives` 与 `published` 卷独立同步/校验（迁移工具**不会**代替 rsync/对象存储迁移）；不要把两个新旧服务同时指向可写目录。
|
||
6. **验证**：逐表行数/哈希、媒体 URL、静态质量报告和线上正式域名一致性；如有失败保持旧站继续服务。
|
||
7. **切换**：预生产全部通过后再人工批准业务切换，保留源库与可回滚路径。
|
||
|
||
工具对旧 SQLite 数据库进行**只读备份快照**；向新 PostgreSQL 写入是显式 `--confirmed-offline` 才能执行的操作。导入使用单事务；建表（初始化）先于该事务，不等于整个目标库已经过生产级迁移验收。
|
||
|
||
## 四、多 Worker / Redis
|
||
|
||
PostgreSQL 是权威任务队列，Redis 只负责唤醒通知；Redis 不可用时 Worker 回退数据库轮询，不能把 Redis 看作持久化任务存储。V8.18 对发布任务加上“结果不确定则不重试”防护，但**未获得真实 Docker 2+ Worker 并发、断电、丢包和故障切换证明**，不能宣布多实例高可用。
|
||
|
||
## 五、本轮验收证据限制
|
||
|
||
本地环境未安装 Docker Engine、PostgreSQL 客户端或 psycopg，无法声称完成真实 PG/Redis Docker 验收。新增脚本和自动化测试提供代码及 CI 入口；应在 GitHub Actions 隔离 postgres 服务上实际运行 `scripts/verify_pg_bootstrap.py` 和 `scripts/verify_sqlite_pg_transfer.py`，保存日志，然后在运维侧完成正式恢复演练。
|
||
|
||
## 六、尚未关闭的 V9.0 要求
|
||
|
||
Art Design Pro 官方前端完整工程编译集成、复杂 WordPress 插件迁移、企业 SSO/MFA、长期容灾、同域路径多语言、真实服务器发布验收，以及完整移动端体验均仍在后续工作范围内。
|