WordPress 迁移记录

背景

最近aliyun 200M的香港轻量云要到期了，考虑到其限速比较频繁，打算整体迁移到 tencentcloud 的竞品上，后者目前为止没碰见过限速问题。

考虑到可预见的未来里，可能还会经历几次迁移，所以记录下迁移步骤。

目前来看整体可分为 4 部分：

最近重装软路由的系统，把openwrt从21升到了最新的23.05。很多脚本需要更新，例如iptables升级到了nftables。

同时最近阿里云和腾讯云不约而同的推出了200M不限流量的轻量云服务器，所以Server部分也需要重装。

重装过程发现很多细节都忘了，果然好记性不如烂笔头。还是搞文档体系的记录一下。

配件	名称	价格	备注
CPU	i7 8700t es	899	qn8j, 淘宝
主板	Asrock z370m itx/ac	869	京东
机箱	Jonsbo c2	144	京东
散热	Thermalright le grand macho rt rev.b	320	咸鱼
硬盘	~~pm963 960g~~	~~695.7~~	淘宝
硬盘	950pro 256g	0	旧机淘汰件
内存	~~Kingston ddr4 3200 8g x 2~~	~~798~~	~~CJR颗粒，京东~~
内存	海盗船 ddr4 2400 8g x 2	0	旧机淘汰件
DC-ATX	联达DC-ATX250W	113	淘宝
电源	台达 12v 20a 电源适配器	100	淘宝
其他	ATX电源挡板	44.55	淘宝

长久以来，登录跳板机都要忍受二步验证，工作效率大打折扣。忍无可忍，爆发了。

在网上搜到一篇讲模拟二步验证的博文《两步验证的使用和TOTP在Python中的基本实现》，示例代码简单可用，比github上动辄几百行靠谱的多。此文是模拟二步验证的基础，在此感谢原作者。

公司线上项目一个库的cpu使用率总是偏高，经同事点拨，发现一处索引使用不当。

首先观察下面的表结构。

CREATE TABLE `live_calc_1b` (
  `vid` varchar(100) NOT NULL,
  ...
  PRIMARY KEY (`vid`)
)

再看下面的这个sql。

select * from live_calc_1b where vid = 14635808219671833713;

看似很普通的使用场景却暗藏隐患，发现了没？

今天在公司调试业务接口，发现一个会引发408的场景。记录一下。

起因是charles的一个bug，用edit功能编辑请求，会导致请求原文中丢失post body。

这样造成的后果就是content-length非0，但body为空，nginx对于该请求会一直处于阻塞状态，等待客户端发body，最终超时。

今早到公司，发现很多人反馈测试环境接口500了。查了下fpm的错误日志，发现数据库连接不上了。

按照配置手动执行mysql -h localhost毫无问题。但是通过fpm就是会抛出connot connect database的异常。

把项目代码中的数据库配置地址由localhost改成127.0.0.1就奇迹般的没问题了。

最终，发现数据库的mysql.sock文件位置被移动了。

另外，经过google，发现fpm连接mysql时，配置为localhost与127.0.0.1的连接方式是不同的。