Some Notes

1. ulimit -t 引起的kill血案


2. 本机Linux下IO测试过程记录


3. @hellodba ：iostat中的 %util 代表一秒内 IO 操作所占的比例，计算公式是 (r/s+w/s)*(svctm/1000)，对于一块磁盘，因为没有并发 IO 的概念，所以这个公式是正确的，但是对于 RAID 磁盘组或者 SSD 来说，这个计算公式就有问题了，就算这个值超过 100%，也不代表存储有瓶颈，容易产生误导。


4. 
   
   • @何_登成：#数据库内核分享# TPS1： InnoDB/Oracle 在数据文件头中记录有 Flush_LSN/Media Recovery CP SCN，二者均是用来标识当前数据文件对应的日志文件位置，但是维护与功能上有极大地不同。维护上：InnoDB Flush LSN 仅仅在 MySQL 数据库正常关闭时才更新；Oracle 的 MR SCN 是在日志文件切换后逐步更新。
   
   
   • @何_登成: 想到一个让 InnoDB 也支持 Media Recovery Checkpoint 的方案，让 InnoDB 在日志文件切换后，进行 MRC，并将新日志文件的 First LSN 作为 Flush LSN 写入每个 Data Files 的第一个 Page 中。如此做的优势，任何时候直接 Copy InnoDB 的数据文件，均可找到 Redo 的恢复起点。
   
   


5. @stvchu ：存储相关(数据库，文件存储)的工程师必须知道的 3 个计算公式。。。特别是第三个。。。知道为什么一般 I/O 利用率要保持在 60%~70% 以下了吧。。。PS: 图中红色数字参考希捷 300G SAS 15KRPM 的规格。
   
   
   
   


6. 
   
   • @hellodba：昨天团队又出现个 case，MySQL 复制一切正常，但是实际数据并没有复制过去，IO 和 SQL 线程都正常，relaylog 也有，原因还在进一步查。幸好发现了，如果主备切换就惨了，另外监控也要加强，不能只看状态，还要检测心跳的时间才行。
   
   
   • @hellodba：解析 binlog 发现主库 tableid 发生变化，备库复制时被忽略掉，原因不明，坑爹啊。
   
   
   • @AlibabaDBA：实际案例：MySQL 空表加字段，因为 BP(Buffer Pool) 比较大，Innodb 会多次遍历 BP 作清理，导致每个操作需要 1s，期间持有 LOCK_open 全局锁，造成其他查询均等待 Opening tables，实际操作中连续作了 64 个 DDL，造成整个系统 hang 了接近 1 分钟。结论：MySQL作大量 create, alter, drop操作必须 sleep。分析人：@希羽hickey
   
   
   • @hellodba：原因在此，宝贵经验。
   
   


7. Ext4 data corruption trouble


8. SystemTap，Linux 内核诊断工具，提供从运行中的 Linux 内核获取信息。


9. Google Data Center


10. Line，简短介绍，相当于微信，但比微信强大。