《叶问》第3期

本文转自【知数堂】：https://mp.weixin.qq.com/s/9Wiiw6UWTeARoLllFwUFkA

2018年6月24日，周日

MySQL 8.0相对于5.7的复制改进，都有哪些呢？

宋利兵老师：《MySQL 8.0相对于5.7的复制改进》的公开课也讨论了这个命题，简单概括主要有两部分：

一、普通复制功能改进 

1. 新增WRITESET并行复制模式，提高并行度，降低延迟 

2. 在多源复制中，可在线动态修改每个channel的filter rule，并且能在P_S中查看/监控 

3. Binary Log中存储更多元数据，并支持毫秒级别的延迟监控 

4. 对JSON Documents的复制效率更高了 

5. 支持DDL Crashsafe 

6. 增加caching_sha2_password安全策略，提高复制安全性

二、MGR功能改进:

1. 支持设置节点权重，且权重最大的在线节点将被选举为主 

2. 每个节点中存储更多的状态信息，如版本、角色等 

3. 可根据从节点的事务状态，自动化流控 

4. 离开集群的服务器自动被设置为read only，避免被误操作更新数据 

5. 可监控MGR的内存使用情况

2018年6月25日，周一

跑truncate table，4亿条数据会不会造成长时间锁表呢?有什么更好的方法吗?

最好是create新表，然后交叉rename对调，再drop/truncate table或其他方式清除数据。 

一、可操作步骤： 

1. 创建新的 tmp 表，正式表与tmp表表名交换（注意在一个SQL里完成，并锁表） 

2. 对 tmp 表创建硬链接 ln tmp.ibd tmp.ibd.hdlk 

3. mysql中删除表tmp（truncate / drop 都行）

4. 然后找个业务不繁忙的时间删除数据文件或者用coreutils 的truncate慢慢搞 

二、关于truncate table，官档解释：

Logically, TRUNCATE TABLE is similar to a DELETE statement that deletes all rows, or a sequence of DROP TABLE and CREATE TABLE statements 
When a table is truncated, it is dropped and re-created in a new .ibd file, and the freed space is returned to the operating system

2018年6月26日，周二

明明有个索引“感觉”应该被选中，EXPLAIN时在possible_keys也有它，但最后没被选中，可能的原因有哪些？ 

一、执行计划如下：

desc select * from t1 where c2 >= 2; 
key: NULL 
key_len: NULL 
rows: 14 
filtered: 92.86 
Extra: Using where

二、可能的原因如下： 

1. 隐式转换

2. 表碎片，因为表的碎片率过高

3. 根据索引读取到的数据在整个表中的数据占比超过30%

4. 统计信息没有及时更新

三、上述执行计划的结果是：

预计扫描的行数为14行，filtered（是指返回结果的行占需要读到的行的百分比）的值为92%。

当前执行计划中filtered值92% 说明根据索引查询获取的结果占整张表的92%，在MySQL中根据索引查询的结果占整张表的数据30%则不会走索，所以不会走索引。 
另外，也有可能是表的碎片率过高或隐式转换导致的。

2018年6月27日，周三

主从复制线程均正常（为Yes，也没报错），Master的binlog已到binlog.000100，但slave上看到Master_Log_File却只到binlog.000090，可能的原因有哪些?

首先要注意，这是Master_Log_File IO线程延迟，并不是Relay_Master_Log_File SQL线程延迟。

一、可能的原因如下： 

1. 由于sync_relay_log值过低，导致Slave频繁刷新relay_log文件，使 Slave的硬盘资源消耗过高，所以导致SlaveIO Thread很慢。 

2. Master/Slave压力过大导致Slave IO Thread不能及时响应， 无法及时获得Master的event。 

3. 网络丢包严重。小包可以连接并且保持连接不断，但是大包就无法发送。可能是Master和Slave关于TCP MTU值设置不一致导致。 

4. Master和Slave网络链接已经断开。但slave_net_timeout值等于0（表示完全禁用心跳）或者slave_net_timeout和Slave_heartbeat_period非常大（表示检测主从心跳的时间）。 

5. Master的binlog非常大，io线程的file很长时间都在读同一个。 

二、总结 
本次案例是在主库进行压力测试，在压力测试的过程中，因为Master本身的压力就很大Master来不及把binlog发送给Slave。所以表面上看起来没有延迟，但实际上已经产生了延迟。