@ns2250225 不是，一个 cpu 核分成 1000m 　单位，如果你一个 pod 只需要 10m(1/100 core), 那就能跑 100 　个 pod. 内存按Ｍ为单位同理.

如果起 pod 时候不指定 request resource,　理论上可以一直加 pod 直到 OOM

1. kubelet 启动的时候有没有指定 --max-pods
2. 取决于 node 的 cpu, ram, 和你要创建的 pod request 的 cpu 和 ram

这人和冯大辉一票的，物以类聚很有道理

我反而觉得是漫威改编里最棒的一部, 这部的确比较粉丝向.

你业务代码 /db 慢和 nginx/apache 有啥关系...

用过 airflow, 但后来发现内部 task 的依赖关系没那么复杂, 也没分布式和可视化的需求, 想维护成本少点, 最后还是自己写了个简单的. 业务复杂的话 airflow 挺够用的.

还有目前的 binlog 并不能实现断电恢复, binlog 可以做 point-in-time recovery 这个一般是写坏数据了用来修数据的.

有点钻牛角尖了额, 你先做了个假设: 把 binlog 提前到 commit 之前写,然后就能用 binlog 来做 crash recover.

问题是目前 binlog 和 redo log 的实现格式完全不同(binlog 根据你需求可选三种呢). 刷盘机制也完全不同. 虽然我不了解这块代码的实现, 但工程上硬用 binlog 来实现 crash recovery 感觉是不行的.(你想想还有 semi sync 的同步方式呢, 同步这块相当复杂)

binlog 的设计目的是为了让外部系统获取数据库内的数据变更,可以理解成一个 expose 的接口.

redo 是 innodb 为了达成 acid, crash recovery 的一种内部实现手段.

存储引擎的确不能控制 binlog, 也不应该关心 binlog, 这不算妥协, 是 by design.

@cc959798 大概明白你的意思了, MySQL 支持不只一种存储引擎, 各种不同的存储引擎都能开 binlog (用于获取 ongoing change, master/slave), 但 redo/undo log 是 innodb 专属的. 它们工作在不同层面上.

如果设计一个 innodb 专属的 MySQL, 的确可以只保留一种 log, 比如 aws 的 aurora db, master/slave 之间就是通过 redo log 同步的( 当然 binlog 也可以开)

楼主应该是认为 MySQL 每次写入数据的时候直接写入磁盘(ibd 文件), 但实际上写的是 WAL(write ahead log), 然后客户端就收到成功的返回了, 因为数据真正落地是随机写, 写 WAL 是顺序写, 要快得多. binlog 的生成应该在数据正真落地之后.

crash 重启后, ibd 文件不一定是最新的, 需要用 WAL 里的 redo log 来恢复数据.

翻译后反而看不懂了......

以前租的房子就很奇葩,我 5 楼,楼下老太有神经衰落,一直认为我屋里在拖拉椅子, 但那声音我也能听到, 后来椅子都套上脚套了,老太还是不依不饶认为是我,被烦的受不了搬家了,搬家当天在楼道里发现是 3 楼的声音....老太态度太差,我也懒得告诉她了.

最好和其他楼层的邻居都确认下,方向真不一定是听起来那样.

把两个 dict 分别 dumps, 然后用 \n 拼起来就行了, ndjson 就是 Newline delimited JSON

16 年买的一块红盘快过保前挂了,换了块新的

如果你公司有 hadoop, spark 的基础设施的话，日志存成 parquet 格式, 可以按 column 选择不同的压缩算法, web access log 这种可以达到很高的压缩比, spark 就能直接查了.

只有 MySQL 你试试 innodb 默认的压缩,看看压缩之后的大小能不能达到你的预期.

如果用的是 MariaDB, 可以试试 ColumnStore 存储引擎, 也是列式压缩的.

设置 policy, 权限只设计在 policy, policy 可以加在用户或组上, 在组内的用户自动继承组的 policy