mongodb 集群崩溃问题
2020-08-28 13:44-13:45 某mongodb分片集群、路由服务是三个节点mongos进程几乎同时coredump运行崩溃。
查看系统日志发现mongos进程coredump的信息、由于操作系统默认没有打开保存coredump文件开关无法进行具体的原因分析。
```
Aug 28 01:44:54 xxx-mongodb-xxx-p-l-1 abrt-hook-ccpp: Process 24066 (mongos) of user 800 killed by SIGABRT - dumping core
Aug 28 01:44:55 xxx-mongodb-xxx-p-l-1 abrt-hook-ccpp: Failed to create core_backtrace: waitpid failed: No child processes
Aug 28 01:44:55 xxx-mongodb-xxx-p-l-1 abrt-server: Executable '/xxx/bin/mongos' doesn't belong to any package and P...
2020-08-31 03:09
NTP 服务导致的 dubbo 服务停止后无法摘除节点
2020-06-30 晚上 22:40左右出现大量的dubbo接口超时。
原因是NTP服务出现时间差，与真实的北京时间差了正好8小时，开始出问题的时间段，NTP服务由VM虚拟机切换到PVE虚拟机，但是切换机器之后没有调整好时间，导致所有机器节点的时间全部出现问题。
2020-06-30 22:45左右，将PVE虚拟机NTP服务回切至VM虚拟机，NTP服务正常；
NTP异常后，应用服务器同步时间出错，容器应用调用异常、超时，重启应用，生成新节点，但因新节点未同步到正确时间，ZK又注册到原来旧节点，即ZK中同时存在新旧不同节点，导致提供服务异常。
此时此刻，所有进行了时间同步的机器节点全部出现DUBBO接口调用失败，zk的时间偏差会导致节点数据无法被正确的删除，很多旧的节点也出现了类似的问题。
可以参考类似问题的文章：
https://blog.csdn.net/liujunzxcv/article/details/91670951
这种情况要解决有两个办法。
方案一：
手动去ZooKeeper删除旧节点的数据，这个非常繁琐。
方案二：
搭建一套新的ZooKeeper，把dubbo注...
2020-07-08 08:39
野路子走法 - shell 脚本管道命令捞日志有感
> 捞日志和日志过滤分析几乎是家常便饭，但是因为shell脚本的命令每次都是用完就扔，没有在脑子里做过停留，所以想写个博客记录下，免得下次用又得查使用的正确姿势。
运营人员想要一批数据，这批数据正好又没有做落地存储，只打印了日志，大致的需求是这样的：
从海量的日志里找出某天某快递公司接口没有返回手机号或者手机号为空的数据个数。
上面这个需求大致可以拆分成如下步骤：
1. 从日志里过滤出原单号校验接口的日志。
2. 过滤出包含xx快递公司的。
3. 过滤出包含用户手机号clientPhone字符的日志。
4. 对该日志包含的字符 clientPhone 进行分割成数组块，取第二个块。
5. 之后对数据进行逗号分割成数组块，对第一个块的字符长度大于10的进行输出第一块的内容。
6. 对输出结果进行次数统计。
```
zcat /app/logs/*/xxxService/info.2020-06-17*log.gz | grep -a 'XXXXController.expressIdValid'| grep -a 'YTO' | grep -a 'clientPhone' | ...
2020-06-22 10:51
shardingJdbc3.x 版本的分页问题
shardingJdbc 改名为 shardingsphere ，同时项目也已经毕业并成为 Apache 顶级项目，但是这是发现它的第二个重大BUG，说明还是有很大的进步空间。
上次发现的重大BUG可以看我的博客： [shardingsphered 的线程安全问题](https://yuxianghe.net/blog/64)
BUG的表象是在使用 shardingJdbc3.1.0 进行分页查询的时候存在问题，一般情况下sql是这样的格式 `limit x,y ` ，但是不管怎么翻页查询，x的值一直都是0，这会导致查询出来的结果，每一次翻页的数据会越来越多，都包含了前一页的数据。
首先，使用 shardingJdbc 的情况下，理论上就不应该存在分页查询。
原因可以想象使用 shardingJdbc 是为了分表，既然是分表了那么这种查询必然会通过条件查询所有涉及到的表来得出结果，然后聚合到内存来进行分页，这会使得机器的压力是巨大的。
所以如果不涉及到分表的情况下，不应该是用 shardingJdbc，如果使用了分表就不应该这样搞分页查询。
前提条件是理想的情况下，但是在某些情况下，...
2020-06-18 11:38
ES某节点CPU增长至100%的诡异问题
> 这是一个从事发到目前为止我没有从根本上解决的技术问题，也是我心中的一个非常大的疑惑。 写于： 2020-06-14 周日，下午14：00
### 问题已解决，解决过程和方案可以看文章最末尾，解决方案写于 2020-06-20 15:26
问题一： 2020年6月4号上午10点左右（高峰期），A集群某节点，我们姑且称之为37号节点，CPU增长至100%居高不下，导致查询队列积压，大量查询请求被拒绝，扩容后问题解决（我们之后新增了五个节点），但是扩容之后的集群里，37号节点平时的CPU占用还是要远远高于其他节点，
相差10倍左右，也就是说其它节点在闲置着看戏，但是扩容后至少不会出现CPU占满的情况。
问题二： 2020年6月12号上午10点左右（高峰期），B集群某节点，我们姑且称之为2号节点，CPU增长至100%居高不下，导致查询队列积压，大量查询请求被拒绝，扩容后问题解决，但是2号节点平时的CPU占用要远远高于其他节点，
相差10倍左右。 我们排查出第三方接口查询量突增非常多的量，因为时间紧急，我们熔断了第三方的查询接口，超过N的QPS直接返回错误信息，2号节点的CPU直线下跌至正常状态...
2020-06-14 07:20