以下是笔者看网上并结合自己的经历整理所得。真真切切的发生的事情。希望能帮助到你 这是一个真实的生产问题，经过长时间的排查和多次寻求 DBA 的帮助，最终我自己花了一个月的时间才定位到这个问题。问题非常有意思，值得大家关注。 问题现象 某天晚上，同事正在发布时，突然线上出现大量报警，其中很多是关于数据库死锁的。报警提示信息如下： {"errorCode":"SYSTEM_ERROR","errorM

大家好，我是煎鱼。 前几天看 Reddit 社区里的讨论，发现 Go 这一门编程语言，错误处理永远是讨论的议题之一。本着追踪网友脑洞 Proposal 的基础上，周末看到个被反对比较多的 Go2 错误处理提案。 图片 今天结合分享给大家，好的坏的都可以看看别人的想法。 问题背景 在 Go 这门编程语言中，错误处理机制主要是依赖于 if err != nil 的方式。因此在对函数做一定的封装后。 代

导读 今天遇到一个离谱的问题, mysql的error日志mysql.err文件 大小会变化, 偶尔猛增, 然后过一会又降下来… 过一会又猛涨, 每次涨的幅度都是一样的. 然后过大概1个月, 涨幅又翻倍. 过3个月又降下来,重新开始涨, 每月1周期,3月1轮回 环境 x86 rhel 8.6 multipath mysql 5.7.41 从库 MTS 未配置日志轮转等 详情 生产环境,不方便放截图

学习golang不久，在定义全局变量的时候遇见了坑。写个小例子，增强记忆。 错误版本 var p int func main() { p, err := test(4) if err != nil { log.Fatal(err) } } func test(i int) (int, error) { return i + 1, nil } 编译一直不通过，p declared and not u

1. 缘起 这周，一个产品团队内进行Go代码评审时，得到了一个结论：所有的if err != nil的地方都应该输出错误日志。然而，这种做法并不是最佳实践，它存在一些问题。 首先，打印过多的错误日志会导致日志文件变得冗长和难以阅读。其次，重复的错误信息会增加冗余。此外，每一层都打印错误日志，一旦错误信息设计不当，可能会导致上下文信息的丢失。 让我们来看一个示例，说明为什么同时输出错误日志和返回错误