bash99

@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 开始，慢慢全局推广。