【TiDBer 唠嗑茶话会 37】各种数据库的血泪史(之一),这期我们不聊别的,就来一次吐槽大会吧!

某拉OS,默认配置,mysql默认安装。sysbench简单测试了下,性能是CentOS7.9的一半。

1 个赞

上周末客户还给我打电话 大周末 说什么oracle 回收站满了能不能清理 我去 管我毛事 我又不用

太难了 建议他谁用谁去搞~

pt-kill可以的

我们是程序每天0点定时任务,alter table add partition 方式加分区的。

1 个赞

确实,有时候还是辅助节点导致主节点的阻塞异常,很难发现

最烦不懂行的领导,还事事怪数据库的问题,不从根本解决问题,就喜欢事从简单,当前应付!

1 个赞

又想起一个,用业务测试tidb性能。从业务侧看qps不高,就说数据库慢。
这就扯淡了,从广州发个快递到北京,好几天不到,怪北京处理慢吗?
好在tidb有监控,每条sql处理了多久都看得到。甩锅利器!

PG: 事务id 32位,导致事务回卷问题。还有表膨胀问题,都值得吐槽一下。
MySQL:某分布式(中间件),drop了一个不需要的database,直接hang死。
Oracle:吐槽下RAC,动不动就要业务隔离,隔离不了各种gc等待,卡的用都用不了。
TiDB:OOM问题,热点问题。

和领导关系最硬的才是最好的数据库

学习的数据库太多太杂,多而不精,算熟悉的sql server在国内应用不多

1 个赞

各种不规范操作,各种OOM

小道消息~ 最近在攻坚 oom 的问题~

脑裂让我脑裂

1 个赞

mysql8 ndb cluster,重启要半天

1 个赞

国产数据库:eyes:谁用谁懂

2 个赞

国产数据库的发展需要大家检验与测试,然后推动官方不断改进,奈何"领导"不愿意做出改变,支持数据库改革!对自己前面的小领导失望。

什么数据库都需要了解

2 个赞

这个结果挺不可思议的,是否查找过原因?mysql的主要代码不是运行在内核层,而内核层的操作系统代码所占用的总体CPU通常不会超过10%,所以内核再差劲也不可能让应用层损失一半的性能。我没用过某拉OS,但这锅让某拉OS来背却不一定合理。

1 个赞

sql server配置实在是太繁琐了

1 个赞