@aec4d 我的理解是限定了大致范围（比如 host 和时间），就之间变成并行 grep 去查询了

可能没有没有全文索引那么快，但是很多时候传统日志 host 加时间限制后也就 100M~1G 的范围，不见得不行。

Loki 我们这边 DevOPS （我搞别的没参与）试用下来的问题是“没法根据具体 pod 做批量规则配置，需要手工做大量规则”
@wsgzao

CoreDns 方案，核心就是利用有人放出来 dnsmasq 的 accelerated-domains.china.conf 列表（包含了绝大部分有 cdn 的国内域名）
原始思路参考这个 https://blog.minidump.info/2019/07/coredns-no-dns-poisoning/
现在我国内用阿里的 dot，极端情况 failback 到 dnspod 和 114
.:5305 {
bind 127.0.0.1
forward . tls://223.5.5.5 tls://223.6.6.6 {
tls_servername dns.alidns.com
}
fallback REFUSED . 119.29.29.29 114.114.114.114
fallback SERVFAIL . 119.29.29.29 114.114.114.114
}
国外用 CF 和 google 的 dot，暂时还能直通。配了个 opendns 的 5353 tcp 应急。

Linux 下全 c 方案
dnsmasq -> chinadns-ng -> https_dns_proxy (4 个分别指向 opendns cf ali 360 的 doh，google 的 doh 是不通的)
dnsmasq 负责缓存和少量内网域名
chinadns-ng 根据列表负责分流，以及高可用（这样国内的 360 也可以用了）
https_dns_proxy 负责转发 doh

列表是参考了 https://github.com/wongsyrone/domain-block-list 去整合了两个来源的列表

@CloudRaft 我当时还是被 ZFS zealot 忽悠了，SLOG 模式的 ZiL （单独 ssd 设备）解决的仅仅是一个日志型文件系统的 double write 问题，实质上和 ext4 的 log 单设备也是一样的。

它只能做到加速有同步写需求的软件（同步写是为了断电不丢的安全性，比如邮件服务、数据库服务），同时这个加速主要还是在即时的延时上，最后的 IOPS 加速很有限（也就是随机写的块能内存里面稍微排排序 - TXG ；效果和 io 特征有关，也就机械盘开了 command queue 的水平）。

对于你们这种如果是大吞吐计算的，不太可能是同步写，加速会很不明显或者说几乎没有。

这篇文章解释得很清楚。
https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/

@dazhangpan 如果用来测试的 workload 足够通用，比如这个 pgo 之后对类 tpcc 的负载也有提升（ https://github.com/Percona-Lab/tpcc-mysql ），当然你可以自行测试。

这是最垃圾的几个啊？ do 的 60 刀（如果没充值优惠）到超售四熊之间有好多档次可选啊。

@wweir 说的比较对，keepalived 这玩意没法用来做有状态的高可用。

MGR 之前，要么就是 MHA ；我们现在自用 Orchestrator

“ For replication, take a look at MHA and MySQL Orchestrator. Both are great tools to perform failover of a Replica.”
引自 https://www.percona.com/blog/2016/06/07/choosing-mysql-high-availability-solutions/
参考 https://www.percona.com/blog/2016/03/08/orchestrator-mysql-replication-topology-manager/

此外做了半同步，没处理物理 fence 防止脑裂。
自己做些点简单脚本切换 ip 以及 切换 readonly。

raw socket 也不行，起码 kcpraw 测试不通

这一波和人多的地方有关。

但是从年初开始，本地 ISP，obfs-simple 的 http/tls 跑 1 个小时封端口是很明确的（有完整 fallback+let's crypt 证书）。
墙的很多测试都是小 ISP 开始，慢慢全局推广。

@GoTop 就是打 ipv6.google.com 访问

恭喜。
HTAP 这边，数据频繁跨节点的话，有多大的性能影响，能否定制 shard 逻辑？

说个在小 team 里面实现得还过得去的模式（当时 docker 还不够流行）

前提：
1. 强大的测试能力或者说自动化测试
我们的测试哥们工资很高，能指导开发数据库设计不合理，能写自动化测试
2. 较好的线上环境重建能力；包含标准测试数据库依赖的环境 5 分钟（也就是不管因为测试把数据库弄得怎么样了，5 分钟全套回复到标准环境）；线上数据库脱敏重建 30 分钟；
3. 变更管理较完备，数据库变动版本化进入代码。

做法：
敏捷模式，每周 release，但是每 2 ～ 4 周为一个 sprint，每个 sprint 里面程序员手头 3 ～ 6 个功能 /Fix，每个功能一个分支。少数情况 2 ～ 3 人工作在一个分支上
hotfix/紧急变动在测试通过后会迅速合并到 master
分支提测前，会保证合并了当前 master （普通 merge 模式；不 rebase -- 当时大家 rebase 用得实在不熟，否则 rebase 应该也行）。会要求程序员做基本自测。
自动化测试通过后，该分支会被合并到一个测试环境（代码包括所有提测的分支），合并有冲突会打回让程序员自己去兼容其它分支（这个情况比较少，可能也是比较麻烦的，基本上让他们本地拿测试分支 merge 找问题）；这个测试环境会再来一轮自动化，有问题也打回，然后 revert （这两步后期是土法脚本化了）；
然后在这个环境上做对应的新功能测试，有问题也是 revert 掉这个分支带来的改动。
周五下午会决定哪些功能在上述环境上已经稳定并且准备上线，所有待上线分支都冻结，然后单个分支 squash merge 到 master。对这个 master 做一些最后测试并确认。
周一上线。（只有脚本自动化，有回退，但是没有灰度发布，有数据库变动且不兼容回退也碰到过，这个没完美解决好）
之后删除已上线两周的老分支（少数重要分支打 tag 后删除）。

优势是 master 上都是干净的一个个功能 commit 和部分 hotfix。

另外，如果分支跨了 sprint，基本上也是很烦的，和其他分支冲突几率大大增加；通常我们在回顾会上检讨是产品经理粒度不合适还是开发没做好。

现在有 docker 了按说可以把上面的自动化测试和环境重建做得更好方便。我仍然觉得 CI 流程做好了是基础，git 只是更灵活更能适应各种的 CI 流程而已。

@changkong 数字键盘这玩意用在笔记本上，那种不对称感真是逼死强迫症啊；我觉得没有还是优点。

再推 play framework 神教，akka 和 scala 系的底层，新版基本上 java api 全开。

reactive stream 真正的启动倡导者，几年前就完备的异步调用原语，等 java8 completestage 处理又再次做了兼容。

akka-persistence 已经成熟，作为 CQRS 及 Event Source 方案简洁优雅。

ebean 作为 ORM 选项之一，我觉得设计得恰到好处(简单 1vsN map，无 session)，喜欢 jpa 及 spring-jpa 也可以用。

除了模板系统强制 scala 系导致模板编译有点慢之外无缺点。

pv
管道看实时流量
cstream
管道限流

default_storage_engine = MyISAM
...
key_buffer_size = 2048M
default_storage_engine = InnoDB
...
innodb_buffer_pool_size = 1024M

这是干啥呢？用的 engine 定了没？
数据库版本？

innodb_flush_log_at_trx_commit = 1
sync_binlog = ?
没 SSD 没带电池 raid 还上这个参数？

补充一个情况，ubuntu 16.04，6626432 字节的 liblkl-hijack_patched.so，直接 python 运行永远是 resource busy, 用 haproxy 运行就正常。