《叶问》第10期

2018年11月6日,周二

Show proceslist时发现大量的sleep,有什么风险吗,该如何处理?

答:(一)可能的风险有:

1、大量sleep线程会占用连接数,当超过max_connections后,新连接无法再建立,业务不可用;
2、这些sleep线程中,有些可能有未提交事务,可能还伴随着行锁未释放,有可能会造成严重锁等待;
3、这些sleep线程中,可能仍有一些内存未释放,数量太多的话,是会消耗大量无谓的内存的,影响性能。

(二)建议应对措施:

1、升级到5.7及以上版本,连接性能有所提升;
2、采用MariaDB/Percona版本,根据情况决定是否启用thread pool功能;
3、适当调低wait_timeout/interactive_timeout值,例如只比java连接池的timeout时间略高些即可;
4、利用pt-kill或辅助脚本/工具巡查并杀掉无用sleep进程;
5、利用5.7的新特性,适当设置max_execution_time阈值,消除长时间执行的SQL;
6、定期检查show processlist的结果,找到长时间sleep的线程,根据host&port反推找到相关应用负责人,协商优化

2018年11月16日,周五

MySQL如何对只对个别列授权?

答:其实挺简单的,用GRANT授权即可,例如:

GRANT SELECT (c1), INSERT (c1, c2) ON zhishutang.yewen TO 'yewen'@'zhishutang.com';

2018年11月20日,周二

如何正确监控MySQL主从复制延迟(请考虑5.6版本前后区别,即并行复制及GTID等因素)?

1、通过观察io线程减去sql线程对比的方式对比: Master_Log_File == Relay_Master_Log_File && Read_Master_Log_Pos == Exec_Master_Log_Pos。

基于GTID复制

2、通过接受事务数减去已经执行事务数对比:Retrieved_Gtid_Set == Executed_Gtid_Set。

基于并行复制

3、先通过P_S库replication_applier_status_by_coordinator和replication_applier_status_by_worker表来观察每个复制线程的状态,后配合postion复制或GTID复制方法来监控复制延迟。
4、可以采用pt-heartbeat工具。

大家不要再相信Seconds_Behind_Master。至于为什么,先卖个关子,关注下期叶问哦。

上一篇:tidb开发规范


下一篇:初探TiDB-TiFlash