《叶问》第3期

  1. 云栖社区>
  2. 博客>
  3. 正文

《叶问》第3期

tplinux 2018-11-29 20:03:24 浏览507
展开阅读全文

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,官档解释:

1、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也有它,但最后没被选中,可能的原因有哪些?

一、执行计划如下:

1、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。所以表面上看起来没有延迟,但实际上已经产生了延迟。

网友评论

登录后评论
0/500
评论
tplinux
+ 关注