偶然发现 go 已经提供了一个用于 profile 的 pprof label，可以在 goroutine 中携带一些数据。不过这个东西既然是用于 pprof 的，随意往里塞太多东西显然也不适合，还会对 pprof 产生干扰。所以，想办法只用其中一个 label，用一些黑科技把一个 map 放了进去，将影响降到最小。同时，pprof 包中已经有一些基于 context 访问处理 label 的逻辑，所以还要做一些兼容处理，避免被其覆盖。

    我们有一个 java 应用，启动的时候要初始化连接池，在连接一堆 sharding 过的 DB 时，经常会有一部分连接超时失败的，集中在一两台后端机器上，但每次失败的后端服务器却又不固定，也并不是每次启动都能遇到。超时时间设为了 50ms，看起来有点短但是对局域网，和压力并不算大的 DB 来说，这个时间已经长得匪夷所思了。后来尝试调大成 100ms，还是有失败的。但是如果启动成功后，却没再记录到过连接超时的情况。

    有时候，我们希望将 MySQL 的 relay log 多保留一段时间，比如用于高可用切换后的数据补齐，于是就会设置 relay_log_purge=0，禁止 SQL 线程在执行完一个 relay log 后自动将其删除。但是在官方文档关于这个设置有这么一句话： Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe. 究竟是什么样的风险呢？

    默认情况下，*nix 命令的 stdout 和 stdin 如果是在终端中是行缓冲，stderr 则是无缓冲。而这些标准输入输出如果是在管道中或重定向文件则是全缓冲。有时候使用管道处理数据的时候，并不希望管道后面的命令一直阻塞等待前一个的输出填满缓冲区刷新的时候才能处理，而是希望能即时看到数据。

     对于一般进程，要让进程崩溃时能生成 core file 用于调试，只需要设置 rlimit 的 core file size > 0 即可。比如，用在 ulimit -c unlimited 时启动程序。 对 MySQL 来说，由于 core file 中会包含表空间的数据，所以默认情况下为了安全，mysqld 捕获了 SEGV 等信号，崩溃时并不会生成 core file，需要在 my.cnf 或启动参数中加上 core-file。 但是即使做到了以上两点，在 mysqld crash 时还是可能无法 core dump。还有一些系统参数会影响 core dump。