本文记录于 2021 年 9 月。
| 升级前 | 期望（最新正式版） | 最终选择 | |
| 操作系统 | CentOS 6.5 | Alibaba Cloud Linux 3 | Alibaba Cloud Linux 3 |
| 管理面板 | lnmp | 宝塔面板 Linux 版 7.7.0 | 宝塔面板 Linux 版 7.7.0 |
| Web 服务 | nginx 1.6 | nginx 1.21 | nginx 1.21 |
| 脚本语言 | PHP 5.6 | PHP 8.0 | PHP 7.4 |
| 数据库 | RDS MySQL 5.6 | RDS MySQL 8.0 | RDS MySQL 5.6 |
| 论坛程序 | Discuz! X3.2 GBK | Discuz! X3.5 UTF-8（即将发布） | Discuz! X3.4 GBK |
版本选择原因：
Alibaba Cloud Linux 完全兼容 CentOS，相比于 CentOS 较短的生命周期，Alibaba Cloud Linux 3 将于 2029 年 4 月 30 日结束生命周期。
Discuz! X3.4 不支持 PHP 8.0，安装时即报错，打开页面时一片空白。
MySQL 8.0 和阿里云 RDS 的 MySQL 7.5 不支持 MyISAM，而数据表 pre_common_member_grouppm 和 pre_forum_post 使用联合主键且自动递增字段不是第一主键，使用 InnoDB 引擎创建表时会报“1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key”错误，而擅自更改主键次序会影响业务逻辑。因此，在必须选择阿里云 RDS 的情况下，只能选择 MySQL 5.6。（2023年8月注：查看如何更改为 InnoDB）
Discuz! X3.5 正式版尚未发布（截止发稿），即便发布，插件也可能不能得到及时更新。相比之下，X3.4 首个版本发布距今已有 4 年，相关第三方插件已经非常成熟。
完整升级步骤：
备份原网站程序、RDS 数据库；
购买新的 ECS、RDS，挂载磁盘，安装云监控；
迁移（或还原）数据库到新的 RDS；
安装宝塔面板并配置；
安装 nginx 及 PHP；
创建网站、配置 SSL、伪静态、防盗链、可写目录禁执行等（.conf）；
配置 hosts；
上传原网站程序到新的站点目录下；
按 Discuz! X 升级文档升级 X3.2 至 X3.4；详情见下文 ↓；
配置 OSS、Redis、更新缓存等；
测试论坛基本功能是否正常；检查附件是否正常显示；全面检查控制台配置；
逐个开启插件并检查兼容性；
按二开备忘录逐个按需进行二开；
逐个修改调用论坛接口的项目及直接调用论坛数据库的项目；
调试 MAGAPP 接口；
尝试强制 https 访问；
将以上所有修改后的程序保留备份；发布升级公告并关闭论坛；重复以上步骤；修改域名解析；开启论坛；
配置 IP 封禁、定时器、日志、自动备份、配置其它 ECS 的 hosts 等；
查看搜索引擎中收录的地址，是否有无法访问的情况；
尝试将历史遗留的本地附件全部转移到 OSS；
Discuz! X 升级步骤及注意点：
升级前务必先修改 ./config/ 目录下的数据库/缓存连接信息，以防出现新站连接老库的情况；
按官方文档进行升级；
【问题】运行到 ./install/update.php?step=data&op=notification 时白屏。
【排查】尝试切换到 PHP 5.6 后成功（但该版本过于陈旧不能使用）；尝试升级 CPU 和内存 PHP 7.4 上升级仍不成功。
【原因】DB::result_first() 方法不对 SQL 语句追加“limit 1”，而是 SELECT 所有记录后在 PHP 端取第一条数据；
【解决】打开文件 update.php，查找 elseif($_GET['op'] == 'notification')，该节点的功能是在表 home_notification 中查找 category <= 0 的数据并修复它，如果数据库中所有 category 都大于 0，直接注释其内部 if 代码段继续升级即可（或改为 if(false && ...)）。
【问题】发布主题遇到错误：(1062) Duplicate entry '*' for key 'pid'
【原因】forum_post 中的 pid 不是自动增长的，而是由表 forum_post_tableid 中自动增长的 pid 生成的。如果生成的 pid 值已在 forum_post 表中存在，则会出现此错误。
【解决】迁移数据库时应关闭论坛，以防止 forum_post 表有新数据插入。
【问题】打开帖子页面 ./thread-***-1-1.html 显示 404 Not Found，而 ./forum.php?mod=viewthread&tid=*** 可以正常打开
【原因】未配置伪静态（可在宝塔面板中选择）
【问题】打开 UCenter 时报错：UCenter info: MySQL Query Error SQL:SELECT value FROM [Table]vars WHERE name='noteexists'
【解决】打开文件 ./uc_server/data/config.inc.php 配置数据库连接
【问题】打开登录 UCenter 后一片空白
【解决】将目录 ./uc_server/data/ 设为可写
需要将原来安装的插件文件移回 ./source/plugin/ 目录，并设置可写；
界面-表情管理，界面-编辑器设置-Discuz!代码
后续 Discuz! X3.4 R 小版本升级注意事项：
确认插件是否支持新版本（如短信通）
先创建一个新网站测试二开代码
保留 /config/、/data/、/uc_client/data/、/uc_server/data/、/source/plugin/，其它移入 old
上传文件
移回其它需要的文件，如：
-- 勋章/loading/logo/nv 等：/static/image/common/
-- 表情：/static/image/smiley/
-- 水印：/static/image/common/watermark.*
-- 风格：/template/default/style/t2/nv.png 等
-- 默认头像：/uc_server/images/noavatar_***.gif
-- 根目录 favicon.ico 等
-- 及其它非 DZ 文件
再次检查可写目录的写入权限和禁止运行 PHP 效果。
1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key
在 MyISAM 转 InnoDB 时出现。
原因：这个表有联合主键，且自增的字段不是第一个主键。
解决方法一，取消自增字段的自动递增，改为在程序中实现；
解决方法二，单独给自增字段单独添加一个索引。
以 Disucz! X3.4 为例，方法一改程序代码显然困难比较大，所以选择方法二。
表 pre_forum_post 中，tid 为第1主键，position 为第2主键且自增。
tid 表示主题，position 表示该帖在该主题中的位置（类似于楼层的概念）。
所以在原来 MyISAM 中可以方便地实现 position 在各自的主题下自增。
给 position 单独添加索引后可以将引擎改为 InnoDB，但是 position 在全表范围内自增了。
也就是说，如果发布一个新主题，那么这个主题帖的 position 就不是1，而是整个数据库中最大的 position 再加 1。
虽然不影响页面中帖子的排序和楼层号显示，但不知道会不会有其它问题，所以最好把它改过来。
给表 pre_forum_post 添加一个触发器，在插入前（BEFORE INSERT）
BEGIN
DECLARE max_position INT;
SELECT MAX(position) INTO max_position FROM pre_forum_post WHERE tid = NEW.tid;
IF max_position IS NULL THEN
SET max_position = 0;
END IF;
SET NEW.position = max_position + 1;
END在上面触发器的定义中，NEW 指即将要插件的一条记录，在新插入的帖子所在主题中寻找最大的 position 赋值给一个 INT 变量，如果找不到就赋值 0，然后 +1 赋值给新的 position。
这样就实现了与原来相同的效果。
用同样的方法给表 pre_common_member_grouppm 添加触发器。
如果帖子有分表，给每个分表添加触发器，下次有新的分表也要记得添加。
在 Discuz! 论坛中，帖子的楼层号是从主题开始计的，即“楼主”是 1#，“沙发”是 2#，“板凳”是 3#，“地板”是 4#，从 5# 开始直接以数字显示，所以我们在计算中奖楼层时，应排除主题帖所在的 1#。以活动截止时的最大楼层号 1000# 为例，允许中奖的楼层数应为 999。据此设计了以下中奖算法：
1、将****年*月*日的上证指数收盘价（含两位小数）×100
2、将得到的 6 位数字按倒序排列
3、用这个新的 6 位数除以总的回复楼层数（即活动截止时的最大楼层号－1），得到余数
4、将余数＋2 即为中奖楼层
以2020年9月30日上证指数收盘价为例：3218.05×100=321805，倒序后是 508123，若截止时间前的最大楼层号为 1000，那么 508123÷(1000－1)=508 余 631，则中奖楼层号为：631＋2=633。
注：
股市 15:00 收盘，但更新收盘价会延迟若干秒，因此稍候查看收盘价更为准确。
论坛发帖会有延时，特别是在抢楼这种高并发的情况下，在“抢楼主题”类型中设置了结束时间后，实际结束时的最终一个回帖的时间仍然可能超过活动截止时间（比如超过 1 秒），所以应在活动说明中明确具体以哪一个楼层结束。
其它活动说明：如不按规定回复中奖无效，不重复中奖的顺延方案，中奖楼层不存在的顺延方案等。
上证指数实时获取接口：http://hq.sinajs.cn/list=sh000001
返回结果例：var hq_str_sh000001="上证指数,开盘价,昨收价,最新价,最高价,最低价,0,0,总手,金额,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,日期,时间,00,";
特别注意，传入不同股票代码返回结果数据中的保留小数位数不同，上证指数保留了四位小数，应四舍五入保留两位小数后参与计算。
原标题：为什么Discuz论坛新注册会员不能发帖
1、后台 -> 用户 -> 用户组 -> 新手上路 -> 详情 -> 帖子相关 -> 允许发新话题：是
2、后台 -> 全局 -> 注册与访问 -> 访问控制 -> 新手见习期限(分钟): 0
删除主题时，会变更主题表 pre_forum_thread：
displayorder = -1
moderated = 1
帖子表（或分表） pre_forum_post* 该主题的所有帖子的
invisible = -1
同时 pre_forum_threadmod 会新增一条 DEL 记录，用于显示到 Discuz! 控制面板 - 内容 - 主题回收站。
删除回帖时，会变更回帖表 pre_forum_post（或分表）：
invisible = -5
屏蔽回复时，会变更回复表 pre_forum_post（或分表）：
status = 1
本文不定时更新！
A： MySQL 执行 SHOW FULL PROCESSLIST
Q： 查看连接数和慢查询，适用于 MySQL 数据库无法连接 1040
A： iftop -i eth0
Q： 查看占用带宽的IP。不显示已知IP段：iftop -i eth0 -F ip/24
A： goaccess -f xxx.log
Q： 实时分析网站日志，查看请求最多的IP
A： net.xoyozo.weblog 日志分析工具
Q： 自制的 Web 日志分析工具，可按多种方式排序，纠出可疑访问
A： 重启 web 服务器
Q： 有时候能解决 CPU 和内存消耗的问题，如果一会儿又升高，则需要找另外的原因
Q： 500 服务器内部错误
502 Bad Gateway
504 Gateway Time-out
A： 查看 php 日志，可能的路径：/usr/local/php/var/log/php-fpm.log
Q： RDS MySQL IOPS 使用率高的原因和处理
A： 根据时间点查看慢查询
Q： Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等
A： 进入管理中心 - 工具 - 更新缓存，能解决大部分问题
Q： Discuz! 浏览帖子提示“没有找到帖子”
A： 进入数据库，修复表 pre_forum_post 或分表
Q： CPU 100% 或内存 100%，负载100+
A： 原因有很多，以下是一些建议：
Windows 在任务管理器中查看进程
当前是否有正常的大流量访问（譬如民生类论坛的某个帖子突然火了）特别是重启无效的情况
对比网站日志大小可大致确定哪个网站被大量恶意请求。
观察：命令 top
排查：通过关闭网站来确定是某网站的问题，通过关闭功能确定是某功能的问题，如果 nginx 崩溃请参下条
案例：通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的，更新插件和 mobcent 包解决问题。
如果都是正常访问，top 看到很多 php-fpm，而且个个占用 CPU 还不小，那么根据服务器硬件配置来修改 php 的并发量，如宝塔面板在 php 设置 - 性能调整 页，300 并发方案的推荐配置是：
max_children：300
start_servers：30
min_spare_servers：30
max_spare_servers：180另外，memcached 或 redis 的配置也可以进行相应的修改。
另一个案例是 kswapd0 进程占满 CPU，原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。
也可以通过 iftop 来查询占用带宽较多的 IP 并封禁（出方向），如果 CPU 能降下来，那这个 IP 就是罪魁祸首。
Q： 阿里云 ECS 的 CPU 突然达到 100%，并持续到次日 0:00 左右
A： 可能 ECS 是 t5 规格，受 CPU 积分制度限制，积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。
Q： ASP.NET 所在服务器 CPU 突然达到 50% 或 100%，并持续
A： 首先确定哪个网站，再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。
Q： nginx 服务停止
A： 查看 nginx 日志
WDCP 路径：/www/wdlinux/nginx-1.0.15/logs/error.log
Q： 公网出带宽 100%，其它指标正常
A： Windows 在任务管理器-性能-资源监视器-网络 查看占用带宽的进程PID，然后在任务管理器-详细信息中的找到对应的用户（如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽）；如果是被 PID 为 4 的 System 占用大部分带宽，也可以尝试重启 IIS 来解决。
CentOS 使用 nethogs 查看占用带宽的进程PID和USER，如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽，否则只能一个个关闭网站来判断，不知道大家有没有好的方法？当然还可以直接用 iftop 命令查看占用带宽的 IP。另外，查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。
A： Linux 显示每个用户会话的登入和登出信息
utmpdump /var/log/wtmp
参考：http://www.tulaoshi.com/n/20160331/2050641.html
Q： RDS 的 CPU 100%
A： 如果是突然持续占满（同时伴随 ECS 资源使用率下降，页面出现 502），很大可能是受攻击（或社交网站推送突发事件等），查看“慢查询”，添加相关索引；如果是 Discuz! 论坛，可尝试修复优化表 pre_common_session。
如果是数日缓步上升，或新项目上线，考虑 SQL 慢查询，思路：MySQL / SQL Server。
MySQL：SHOW FULL PROCESSLIST
SQL Server：sp_who
Q： php 网站的服务器，内存在数天内缓慢上升
A： 大概是 php-fpm 占用过多，或进程数太多
更改 php 的配置（如 max_spare_servers），执行：service php-fpm reload
Q： 进程 cloudfs 占用内存过多
A： 参：https://xoyozo.net/Blog/Details/cloudfs-cache
Q： RDS 磁盘占用过大
A： 参：https://xoyozo.net/Blog/Details/how-to-use-rds
Q： ECS 受到 DDoS 攻击怎么办？
A： 参：https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp
Q： 如果 ECS 和 RDS 各项指标都没有异常，但网页打开慢或打不开，TTFB 时间很长，是什么原因？
A： 数据库有坏表，尝试优化/修复表（慢 SQL 日志中锁等待时间较长的表？），或主备切换。
论坛使用阿里云的 ECS + RDS + OSS 搭建，最近经常隔三差五出现 RDS 的 CPU 和连接数突然满负荷的情况，导致数据库无法连接。这种情况一般会认为是受到了攻击，因为如果是访问量大或者是哪里有慢查询，应该是资源消耗逐步上升直至崩溃的，沿着这个思路去查 Web 日志封 IP，但效果不大，关闭功能、卸载插件也没用。
开启阿里云后台的 SQL 审计，能看到 SQL 查询日志，但是很难找有问题的 SQL。
最终在重启 RDS 后执行以下语句列出所有正在执行或阻塞的语句：
show full processlist在结果列中，Command 为 Query 是正在执行查询操作的语句，发现几乎所有的 SQL 都是：
SELECT * FROM pre_forum_thread WHERE tid>0 AND fid IN('42','95','247','41','567','62','149','229','37','230','93','190','284','75','38','568') AND `fid`<>'546' AND replies > 0 AND displayorder>=0 ORDER BY lastpost DESC LIMIT 10再加上之前出现的情况是，论坛帖子列表和详情页面能正常打开时，论坛首页也不一定能打开，所以基本定位到是“首页四格”的数据库查询导致的。
进入论坛后台首页四格设置，对比了版块 id 后确认了这个 bug。
单独执行该语句大约耗时 5s（主题帖 200 万），设置的缓存时间 10 分钟。
processlist 中看到这些语句的 state 都是 Creating sort index，尝试去掉 ORDER BY 后执行果然只需要 16ms。
5s 内的访客都是从数据库读取的，能处理完就正常，否则累积就导致 RDS 崩溃，每 10 分钟都会重现一次风险。
当然这个问题可以通过添加索引来解决。
今天在逛汽车之家论坛时偶然发现，当选中帖子内容时，部分文字被空缺出来，没有被选中，一开始以为是把部分文字使用图片来代替了，审查元素发现是常见文字使用伪元素来输出，比如“大”字：
<span class="hs_kw10_mainuD"></span>.hs_kw10_mainuD 样式：
.hs_kw10_mainuD::before {
content: "大";
}这样肉眼根本无法察觉，因为不管字体大小、颜色等等都与普通文字一样，这是区别于用图片代替的最大优势，其次还能减少请求数，减少带宽消耗等。
对于大型站点，庞大的主题和帖子数据，分表放到一个主题表和一个帖子表中，已经成为影响性能的一个因素。因此，急需进行分表操作来避免 MySQL 对于大数据表的频繁操作。
1、后台分表
Disucz! X2 后台重新调整了分表的机制，使得分表效率和后期站点性能得到提升。具体分表设置在 后台 -> 站长 -> 主题分表（帖子分表）。
1）主题分表
主题分表分为两种类型，一种为主表，一种为存档表。主表只有一个，存档表可以有多个。我们进行分表操作，首先进行创建存档表的操作，然后进行主题移动，将指定条件的主题移动到存档表中。
a、创建存档表
打开 source/admincp/admincp_threadsplit.php 文件，找到创建存档表的条件分支
- elseif($operation == 'addnewtable')
复制代码
首先获取当前最大的主题表 id ，然后根据 forum_thread 的建表语句，生成新的存档表（id + 1），最后更新缓存。
b、主题移动
存档表建好后，下一步就是将主题移动到这个存档表中。在选择主题的时候，可以根据提供的搜索条件，特别是“更多选项”中的搜索条件，来转移符合条件的主题。这里主要是一个搜索的过程，转移数据的过程使用 REPLACE INTO … SELECT...FROM... 语句，比较简单。
2）帖子分表
帖子分表也是要分成两步，第一步先创建帖子分表，第二步转移数据。
打开 source/admincp/admincp_postsplit.php 文件，找到帖子分表的条件分支
- elseif($operation == 'split')
复制代码
如果是对主表进行分表操作，主表必须要大于400M，见下面的条件判断
- if($status && ((!$tableid && $status['Data_length'] > 400 * 1048576) || ($tableid && $status['Data_length'])))
复制代码
在站长提交分表表单后，程序会先根据 getmaxposttableid 函数获取当前帖子表最大的 id ，然后根据已有的帖子表结构，创建新分表，并更新缓存等信息。创建成功后，开始转移数据的操作。找到条件分支
- elseif($operation == 'movepost')
复制代码
，开始转移数据的操作。当从主表中转移数据时，是根据主题表中最后回复时间正序排列的主题 tid 来获取帖子数据的。
- $query = DB::query("SELECT tid FROM ".DB::table($table)." WHERE posttableid='0' AND displayorder>='0' ORDER BY lastpost LIMIT 0, 1000");
复制代码
然后，利用 movedate 函数进行转移数据。
当从从表中转移数据时，是根据给定帖子表的 id，获取此表中first=1的帖子所属 tid，
- $query = DB::query("SELECT tid FROM ".DB::table(getposttable($fromtableid))." WHERE `first`='1' LIMIT 0, 1000")
复制代码
然后利用 movedate 函数进行转移数据。
在 movedate 函数中，根据获取到的 tid ，将属于此 tid 的帖子，利用 INSERT INTO … SELECT … FROM ...来转移数据。在此过程中，更新主题表中 posttableid 这个字段，来标识帖子的存储表。
2、主题列表页分表读取
在主题列表页，只能看到主题主表中的主题。存档表中的主题都在存档区。
在这部分的代码（source/module/forum/forum_forumdisplay.php）中，所有涉及到的主题表都以 $threadtable 这个变量代替，$threadtable 这个变量的获取，又是根据用户是否查看存档区的标识 archiveid 来判定。
- $threadtable = $_G['gp_archiveid'] && in_array($_G['gp_archiveid'], $threadtableids) ? "forum_thread_{$_G['gp_archiveid']}" : 'forum_thread';
复制代码
当用户选择非存档内容时，archiveid = 0 或者不存在，这时，直接从 forum_thread 主表来读取主题列表。当用户选择存档内容时，archiveid = 1（1 表示存档表的 id，如果查看 id 为 2 的存档表，archiveid = 2），程序会根据 archiveid 来判断从哪个存档表中去获取主题列表。
3、帖子内容页分表读取
当用户浏览帖子内容页时，程序首先利用 loadforum 函数来获取当前的主题信息。在 loadforum 函数中，
- $_G['thread'] = get_thread_by_tid($tid, '*', $addcondiction, $archiveid);
复制代码
根据提供的 tid，get_thread_by_tid 函数到主表和存档表中分表去查找，直到找到对应的主题信息。
在 source/module/forum/forum_viewthread.php 文件中，根据
- $thread = & $_G['forum_thread'];
复制代码
- $threadtable = $thread['threadtable'];
- $posttableid = $thread['posttableid'];
- $posttable = $thread['posttable'];
复制代码
这两句来判定该主题应该去哪个帖子表中去获取帖子内容列表。
4、发新主题
发表新主题时，直接往主题主表中插入数据，对应的 posttableid = 0。然后，当插入帖子数据时，通过 insertpost 函数将数据插入帖子表中。
在 insertpost 函数中，会先去判断所属主题的 posttableid 值，得到目标帖子表，然后再往该帖子表中插入帖子数据。
5、发新回复
只有在主表的主题才能回复，因此，直接根据传递的tid去获取目标帖子表，然后插入数据。这个跟发新主题时，插入帖子内容过程相同。
6、编辑帖子
同样，只有在主表中的主题的帖子才能被编辑，因此，主题都在 forum_thread 表中。需要获取的是该主题的帖子在哪个帖子表中。打开 source/include/post/post_editpost.php 文件，找到
- $posttable = getposttablebytid($_G['tid']);
复制代码
程序在开始，通过这条语句来获取目标帖子表。在 getposttablebytid 函数中，程序根据 tid ，逐个主题表进行查找，找到对应的主题信息，获取目标帖子表，然后指向后续的编辑帖子操作。
8、取消存档
存在存档区的主题，如果想取消存档，可以通过页面底部的“取消存档”来执行。
打开 source/include/topicadmin/topicadmin_restore.php 文件，可以看到取消存档，实际上仅是将放在存档表中的主题移动到了主表中。同样，存档表的获取还是通过 archiveid 这个参数来决定的。
- $threadtable = $archiveid ? "forum_thread_$archiveid" : 'forum_thread';
复制代码
从这可以看出，存档的概念仅限于主题，帖子无所谓存档的概念。