前面有一篇文章提到硬盘使用率达到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多了。
Year: 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/
常见的数据访问的写法大概有以下几种： Native SQL JPQL Criteria API Spring Data JPA 其他框架(jooq、MyBatis等) Native SQL Native SQL 算是最简单，也最直观的使用方法了。EntityManger是JSR标准里面提供的，所以不需要依托任何框架就可以使用。 JPQL JPQL跟Native SQL相比，其实也是大同小异。只是把select部分省略了。 Criteria API Criteria API 其实功能很强大，但是就是写起来太复杂。理解起来也比较费劲。在项目中实际使用的其实很少。 Spring Data
前两天面试一个remote职位，一个技术型的面试官，问的特别细致。还记得其中一个是关于Github action的安全措施的。这个考官也十分新奇，问的都很抽象。他就问我在Github action中，都采用了什么样的安全措施。我当时也是有点蒙，细节部分当时确实不是很清楚，直接说了句把重要信息都存在了Parameter Store来敷衍了过去。所以也是为了给自己补补课，打算重新再认真总结下WEB系统常见的安全措施。 WEB安全，主要分为两个大块。一个是Application层面，一个是Network层面。Network的话，我自己也还不是特别熟悉，这次先主要总结下Application层面常见的应对措施。 账号安全 CORS Cross Site Scripting SQL Injection ClickJacking POST、GET等Request Method的正确使用 系统信息的加密，hash化 账号安全 主要包含账号注册，login，logout相关部分的处理。账号注册方面：・要注意不能使用太简单的密码，密码要经过加密处理・为了避免恶意注册，要添加2段认证，比如通过email注册login：・页面里的auto complete最好关闭・如果使用java的session管理功能的话，login前后的JSESSIONID务必要刷新・为了防止暴力破解，要加入login尝试次数限制的机制logout：・logout不只是页面的迁移，之前的认证key也需要进行invalidate处理 CORS 使用API时有时会需要跨域，最好通过ALB的设置解决，商业环境ajax的跨域设置最好要关闭。Spring的话可以设置某些指定环境才打开CORS。 Cross Site Scripting 通过往数据库里写入script，然后在画面显示的时候去执行这些script。以用来窃取用户本地的信息。
Github action：主要用来做CI/CD整体的控制，包括何时build、何时test、何时deploy到相对应环境中去 ECS：用来用来管理docker image 的repository，以及自动发布 解读下上面这段代码。1. 开头的 on 部分这里是指定GitHub action的trigger，可以是push，可以是merge，也可以是publish。 2. Maven Build在GitHub的虚拟环境中执行build的相关指令。 3. Configure AWS Credentials设置AWS的访问密钥。因为yml文件是需要进行版本控制的，为了更加安全起，就将密钥信息写在了GitHub的Secrets里面，这样就避免了在代码里的明文。 4. Deploy docker image这步是将build完了jar文件上传到ECR中，发布在ECS上面的，其实就是一个个的image。 5. Render Amazon ECS
2020年的NISA还有一定的额度，然后最近Softbank的股票比较低迷。之前肺炎严重的时候，全部股票都在跌，就只有通信股相对稳定。尤其是NTT，当时更是创了历史新高。所以就想着在通信股里再选一选，看入手那个比较好一些。然后，我在YouTube上找了一些分析通信股的视频，大部分都看好KDDI，先简单总结下大家的思路，然后再说下自己的。说KDDI比较稳定的，大概可以看上面的这张图就可以。通信三社里，NTT这次营收额减少了，而且并不是因为投资5G之类的，更多的原因是面向普通用户的plan的营业没做好，然后KDDI跟软银的话，相对稳中有升。売上和利益的话，KDDI表现最好，甚至超过了NTT。分红方面，KDDI跟NTT差不多。虽然Softbank利率最高，但是他的配当性向(从利润中拿出来用来分红的钱的比例)相对较高，市场分析这个情况还是不太健康，或者这种高分红的情况不能维持长久。还有就是自己資本率、KDDI虽然比不过NTT，但是比Softbank做的好一些。Softbank虽然ROE高一些，但是自己資本率太低，导致ROE不太有参考性。所以结论大概可以这样总结为：NTT最近营收不太好，接下来仍旧可能会被Softbank跟KDDI抢夺市场，前景不太明朗。Softbank的话，债务稍微有些问题，营收或许看上去不错，但是应对危机的能力较弱。KDDI，5G方面已经进行了跟NTT一样足够规模的投资，营收方面表现也不错，债务处理也很好，稳定中又有发展前景。所以，如果从三家中选择的话，还是KDDI相对好一些。 然后下面说下我自己的看法。我个人其实是更看好Softbank的。原因大概有这么几点：1. Softbank的财报本身其实还是不错的。前景也比较不错。尤其是跟其他两家相比，Softbank的营收里还包含了Yahoo，这部分的增长率是比通信部分更高一些的。孙正义玩转日本国内的市场其实已经驾轻就熟，一旦出现机会，能马上迅速作出决断，抢占市场。2018年成立的Paypay就是一个很好的例子。仅仅两年时间，已经做到头号品牌了。加上去年跟LINE合并，还是对他比较有信心的。5G投资方面，软银虽然较弱一些，但是晚一些时间，回报比未必会差很多。也不能仅仅根据投资金额去判断好坏。2. 孙正义这次跌了一个大跟头，Uber跟Wework估值下降，上市不成功等等，导致营收减少1个兆。关于这件事，可能有些太过于主观的判断。我觉得，对于62岁的他来说，这未必是一件好事。通过变卖20%左右的资产，算是把现金流跟债务问题解决了。公司尚没有到生死存亡的时刻。孙正义是个聪明人，以后他或许还会跌跟头，但是我觉得10年以内，他再次作出成绩之前，应该不会再同样的地方再跌跟头了吧。所以就是我个人对这个经营者比较有信心，觉得他能把Softbank经营好。3.Softbank的股价当前偏低。从利回り和历史股价就可以看出来。所以如果打算长期持有的话，现在算是个好时机。 当然，KDDI也是不错的一支，但是感觉当前股价稍高，等过段时间稳一下再入手吧。同样，NTT也是，因为营收减少，预测股价还会跌。将来的趋势还不太明朗。
下次预感到危机要来的时候，要不要止损？ 如何判断是经济不景气，还是泡沫？ 上周的跌幅又是历史级别的，之前一直认为长期投资，不要去考虑这些欺负什么的，只要股票可以带来分红就OK了。而且，如果挣钱了就卖掉，套现出来，钱又不能生钱，不还是要再进股市。但是，这两天突然感觉自己是不是忘记考虑了一点就是，当你对一只股票的中短期不太看好，然后当时股票又有capital gain的时候，是不是应该考虑卖掉，持有一段时间的现金，等它跌回去以后，再考虑重新购入呢？比如「インヴィンシブル」，1月底的时候其实已经看到疫情对inbound事业，对旅游业的影响了，但是当时并没有抛售，如果当时能看清楚中短期的影响，应该就能作出更加正确的选择了。抛售了股票，诚然会少拿部分分红，但是，比起股价下跌10%以上的风险，尤其还在赚钱的情况下，先把capital gain拿到手以后，静观一段时间的市场变化在做决策才更加明智一些。所以，下次务必要尝试下提前止损的操作。 https://www.nli-research.co.jp/report/detail/id=64017?site=nli
