前面有一篇文章提到硬盘使用率达到100%导致服务无法启动的问题。最后查出来是数据库的问题。但是当时没有做详细调查。这里简单写一下后续是如何解决这个问题的。 首先通过phpmyadmin打开数据库。具体如何访问phpmyadmin这篇文章有写。然后看了下bitnami_wordpress数据库，发现唯有wp_options这个表如此之巨大。有66G之多。 wp_options这个表，只有option_value是longtext，查看了下容量最大的前10条，并没有发现什么异样。 这就有点不知所措了。所以去网上搜了以下，确实也发现有碰到同样问题的。网上的处理一般有两个步骤：1. 安装 WP-Optimize 进行优化2. 删除 option_name like ‘%_transient_%’ 行 两个方法都尝试了以下。都没有成效。尤其是删除_transient_行，删除以后5分钟就又自动生成了(貌似类似于cache的东西)。最后没有办法，把wp_options表进行手动备份，发现只有1M多。mysql的具体存储机制尚不太清楚，估计是wp_options已经申请了太多的tablespace。所以干脆就drop掉table，然后把刚才手动备份的wp_options重新导入。这样wp_options的表空间就恢复到2M多了。
Day: October 29, 2020
第一步找到以下文件 第二步修改文件，加入本地机器的global ip address到白名单中 第三部确认phpmyadmin的登陆密码 第四步通过 http://[パブリックIP]/phpmyadmin 地址登陆 参考：https://note.com/ryutakimuravc/n/nf41e6932ad8f
拿lightsail搭建的wordpress最近十分的不稳定。动不动就503错误。开始以为是某些plugin作妖。就尝试了一下隔断时间重启instance。通过lambda脚本跟定义cloudwatch上的rule可以简单的实现。lambda脚本如下： 刚开始的两天这个还算好用，可是又没过几天，连重启instance都不管用了。一直503状况不断。登陆进去查看了一下。打算重启下service来着。 但是重启不成功。disk usage 100% error。硬盘容量不够了。df -h 查看了一下，确实 / 路径下可用已经为0了。 然后，又打算sort head查下使用最多的路径。无奈du也不能用了。 这可怎么办才好。要不要尝试着增加个disk吧。但是查了几篇文章。发现新增disk必须新建目录。单是问题是我现在 / 目录下的东西还是100%。所以这个方案就放弃了。 剩下就是看删点什么东西了吧。尝试了数次，最后找到了apche存放log的地方。sudo rm -rf *.gz 删除了所有log的备份。这下解放了1个多G的空间。 然后重启service，一切就回复正常了。service重启完以后，又重新看了下最费硬盘容量的几个路径。发现这个mysql/data/bitnami_wordpress 自己就占据了67G。这应该就是罪魁祸首了。但是具体为什么占了这么多容量还不太清楚，下次有时间再继续分析。 参考：https://dev.classmethod.jp/articles/add-storage-to-lightsail/
