XenForo论坛如何消除单点故障：数据库复制、自动切换与恢复目标设计

XenForo论坛出现“数据库连接失败”、发帖长时间无响应，或者数据库主机故障后必须人工修改 src/config.php 才能恢复时，故障点通常不只是数据库进程。即使已经部署 MySQL 副本，只要数据库写入口、代理、故障检测器、切换控制器或附件存储仍是单实例，论坛依然存在单点故障。复制只能保留另一份数据，不能自动完成故障判断、旧主隔离、角色提升和流量切换。

处理顺序应由外到内、由低风险到高风险：先确认用户侧影响范围，再核对 XenForo 使用的数据库入口及网络连通性，随后确认主从角色、复制进度和数据一致性，最后才考虑提升副本或重建复制。任何自动切换方案都必须同时满足五个条件：唯一写入口、可判断的复制状态、可靠的旧主隔离、可自动更新的访问路由，以及经过演练的 RPO 与 RTO。

先用现象界定故障范围

同样是“论坛打不开”，对应的故障层可能完全不同。开始操作前，应记录故障时间、当前数据库入口、各节点角色和最近一次变更；涉及数据库角色或复制配置调整时，还应确认备份及二进制日志可用。

先从用户入口检查 HTTP 状态。以下命令适用于可使用 curl 的 Linux 或运维终端，只发起读取请求，不会修改论坛数据：

curl -sS -o /dev/null \
  -w 'HTTP=%{http_code} connect=%{time_connect} total=%{time_total}\n' \
  https://forum.example.com/

结果可按以下方式判断：

• 502 或 504：先检查反向代理、PHP-FPM 和应用节点，不要直接切换数据库。
• 500 且页面显示数据库错误：继续检查数据库入口和 XenForo 错误日志。
• 首页正常，但登录或发帖失败：重点检查写节点角色、数据库权限和只读状态。
• 请求持续超时：可能是数据库连接超时、锁等待或后端资源耗尽，不能仅凭 HTTP 状态决定提升副本。

XenForo仍能访问数据库时，可以从管理后台查看服务器错误日志；数据库已经不可用时，应查看 Web 服务器和 PHP-FPM 日志。服务名和日志位置取决于发行版及部署方式，可先执行只读查询：

systemctl list-units --type=service | grep -E 'nginx|apache|httpd|php.*fpm|mysql|mysqld|mariadb'

再按实际服务名读取日志，例如：

journalctl -u php-fpm --since "30 minutes ago"
journalctl -u nginx --since "30 minutes ago"

不要在尚未保存日志和状态信息时同时重启所有服务。重启可能暂时清除连接问题，也可能破坏判断切换过程所需的线索。

按优先级检查数据库入口、连通性和节点角色

以下检查以 Linux、XenForo 2.x 和 MySQL 8 为参考。MariaDB及较旧 MySQL 的命令名称、状态字段和服务名可能不同，应先执行 SELECT VERSION(); 并核对对应版本文档。

1. 确认XenForo实际连接到哪里

XenForo数据库配置通常位于安装目录下的 src/config.php。检查 host 和 port，但不要把包含密码的完整文件复制到工单或聊天记录。

高可用环境应让 XenForo 指向稳定的逻辑写入口，而不是某台数据库主机的固定 IP，例如：

$config['db']['host'] = 'db-writer.internal';
$config['db']['port'] = 3306;

这个入口可以由冗余数据库代理、虚拟地址或经过验证的服务发现机制提供。如果配置仍指向旧主库 IP，即使副本已经提升，XenForo论坛也不会自动恢复。使用 DNS 切换时，还要评估客户端缓存和 PHP 长连接对恢复时间的影响。

修改生产配置前，应备份原文件并记录原值；修改后如果连接失败，应立即恢复原配置，而不是同时变更数据库权限和网络策略。

2. 从应用节点验证解析和端口

以下命令只检查名称解析、TCP 端口和数据库响应，不修改系统：

getent hosts db-writer.internal
nc -vz -w 3 db-writer.internal 3306
mysqladmin --protocol=tcp -h db-writer.internal ping

不要把密码直接写入命令行。可使用 mysql_config_editor 创建的登录路径，或让客户端交互式提示密码。

不同结果代表不同处理方向：

• 域名仍解析到旧地址：检查服务发现、代理配置或 DNS 缓存。
• 3306 端口不通：检查数据库进程、监听地址、防火墙及网络路径。
• 端口可达但数据库认证失败：检查账户来源限制、密码和 TLS 配置。
• 数据库响应正常但 XenForo 仍报错：继续检查应用配置、数据库角色、连接数和锁等待。

3. 确认哪个节点有权写入

在每个候选节点上使用只读 SQL 查询版本、身份和角色：

SELECT VERSION();

SELECT
    @@hostname,
    @@server_uuid,
    @@read_only,
    @@super_read_only,
    @@gtid_mode,
    @@binlog_format;

SHOW REPLICA STATUS\G

较旧 MySQL 可能需要使用 SHOW SLAVE STATUS\G；MariaDB应以对应版本支持的语法和字段为准。

检查重点包括：

• 当前唯一写节点的 read_only 和 super_read_only 不应保持开启。
• 普通副本应保持只读，避免应用或管理员绕过复制直接写入。
• Replica_IO_Running 与 Replica_SQL_Running 应处于正常状态。
• Last_IO_Error 表示副本无法从源端接收日志。
• Last_SQL_Error 表示复制回放遇到冲突、缺表或数据不一致。
• Retrieved_Gtid_Set 与 Executed_Gtid_Set 的差距反映日志已接收但尚未执行的范围。

Seconds_Behind_Source 只能作为辅助信号。复制线程停止、网络中断或缺少可比时间点时，该字段可能为空或产生误导，不能单独作为提升副本的依据。

4. 排除磁盘故障和脑裂

磁盘空间、inode 或文件系统异常可能同时导致业务写入和复制停止：

df -h
df -i
ss -lntp | grep ':3306'

根据实际服务名查看数据库日志：

journalctl -u mysql --since "30 minutes ago"
journalctl -u mysqld --since "30 minutes ago"
journalctl -u mariadb --since "30 minutes ago"

若日志出现磁盘已满、InnoDB恢复失败或表空间损坏，不应直接提升一个状态未知的副本。应先保护现有数据目录和日志，再核验副本完整性及备份可恢复性。

如果发现两个节点均可写，处理优先级高于恢复论坛访问：

1. 暂停 XenForo 写流量，必要时显示维护页面。
2. 通过宿主机管理、平台接口、STONITH或网络隔离手段封锁旧主库。
3. 确认旧主库无法继续接受任何应用连接。
4. 比较候选副本的 GTID、复制线程和事务执行状态。
5. 只提升一个满足条件的候选节点。
6. 更新逻辑写入口，再逐步开放论坛写入。

不要在节点身份不明确时批量关闭只读状态或修改复制源。角色变更前应保存数据库配置、复制状态和可用备份；需要回滚时，应先恢复唯一写入口和隔离关系，不能让旧主直接重新提供写服务。

数据库复制、自动切换和一致性必须一起设计

数据库复制解决的是“其他节点是否保留了可接管的数据”；高可用解决的是“故障后由谁接管，以及 XenForo 如何找到它”。较完整的写路径应避免任何关键组件只有一个实例：

用户请求
   |
负载均衡或反向代理
   |
多个XenForo应用节点
   |
冗余数据库写入口
   |
当前唯一主库  --->  副本A
               --->  副本B或备份链路
   |
共享或受支持的统一文件存储

常见的新单点包括：只有一台数据库代理、只有一个故障检测器、两个数据库节点之间没有见证或隔离机制，以及附件只保存在单台应用服务器本地。复制副本也不能代替备份，因为误删除、错误更新和部分逻辑损坏同样会被复制。

对 XenForo论坛，默认应保持单写模型：所有正常业务写入当前主库，副本用于接管、备份或经过验证的只读任务。将帖子列表、权限判断或登录后的即时查询直接分流到延迟副本，可能造成“写入成功但马上读取不到”的一致性问题。

复制模式决定了切换时的数据边界：

半同步中的“已收到”不一定表示事务已经执行并可查询，具体语义取决于 MySQL 版本和插件配置。组复制也不是在现有异步复制上直接开启一个选项即可完成；XenForo及其插件涉及的表结构、事务模式和维护流程，应先在预发布环境验证。

无论采用哪种复制方式，都要坚持三个条件：正常状态只有一个业务写入口，切换前可靠隔离旧主库，切换后重新确认所有节点角色。

用RPO和RTO决定能否自动切换

RPO表示故障后最多允许丢失多少已经产生的数据，RTO表示从故障发生到论坛恢复可用所允许的时间。两者不能通过“平时复制延迟很低”来推断，必须通过故障演练验证。

RTO可以拆分为：

RTO = 故障检测时间
    + 仲裁与旧主隔离时间
    + 副本提升时间
    + 数据库入口切换时间
    + XenForo验证与开放写入时间

如果要求不丢失已经确认的帖子，仅部署异步复制通常不足以作出保证，还需要综合评估复制确认语义、日志持久化、附件一致性和应用写入验证。

MySQL副本常见基础参数如下，但不能未经测试直接覆盖生产配置：

[mysqld]
server_id = 102
log_bin = mysql-bin
binlog_format = ROW
gtid_mode = ON
enforce_gtid_consistency = ON
log_replica_updates = ON
relay_log_recovery = ON
read_only = ON
super_read_only = ON
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

server_id 必须唯一；示例中的 read_only 和 super_read_only 适用于副本，不应原样用于当前写节点。持久化参数会影响性能和故障后的事务保留边界。变更前应备份数据库及配置、记录原值，并确认参数能否动态修改或需要重启；回滚时按原参数恢复，不要在未验证复制状态时同时变更多个节点。

自动切换应是一段带条件的状态机，而不是简单关闭副本只读：

1. 从多个位置检查 TCP、数据库查询、复制状态和主机可达性，避免单次超时触发误切换。
2. 通过多数节点或独立见证取得仲裁结果。
3. 隔离旧主库，确认其不能继续接收 XenForo 写入。
4. 根据 GTID、事务执行状态和节点健康度选择最新候选副本。
5. 提升唯一写节点，并让其他副本改为跟随新主库。
6. 通过冗余代理、虚拟地址或服务发现更新写入口。
7. 使用受控账号验证登录、发帖、编辑和附件读取。
8. 隔离并重建旧主库；存在事务分叉时，应从新主库或可信备份重新初始化。

只有两台数据库且没有可靠见证和隔离机制时，自动切换存在明显脑裂风险。网络分区期间暂停写入，通常比允许两个节点同时接收论坛数据更安全。

根据检查结果选择修复路径

如果日志已经接收但 SQL 回放缓慢，应重点检查副本磁盘、长事务和锁等待；如果 XenForo 写入正常但立即读取不到，应检查是否把即时查询错误分流到了副本。

权限调整应限定数据库、账户和来源地址，并保留原授权用于回滚。旧主库重新加入前，必须证明其数据没有分叉；无法证明时，从新主库或可信备份重建通常比强行接回复制链更安全。

修复后验证唯一写节点和恢复能力

首页能够打开，只能说明读取路径部分恢复，不能证明切换正确。修复后应依次完成以下验证：

1. 通过 XenForo 使用的逻辑入口查询数据库主机名、UUID和只读状态，确认流量到达新主库。
2. 检查全部副本的接收线程、执行线程、GTID和错误字段。
3. 从网络和数据库权限两方面确认旧主库已被隔离。
4. 使用授权测试账号，在非公开测试区域完成登录、发帖、编辑和再次读取。
5. 上传测试附件，确认切换后的所有应用节点均可读取。
6. 检查 XenForo后台、PHP-FPM、数据库和代理日志，确认没有持续连接错误。
7. 验证数据库备份及二进制日志能够执行时间点恢复，而不只是确认备份文件存在。
8. 持续观察复制积压、数据库连接数、代理后端状态和应用错误率，覆盖至少一个正常业务周期。

正式启用自动切换前，还应分别演练主库进程故障、整机失联、网络分区、代理故障和候选副本延迟。只有故障检测、仲裁、旧主隔离、数据接管、XenForo写入及附件读取都通过复测，数据库副本才真正转化为可恢复、可验证的高可用能力。