近日接报某实例一个datetime字段主从数据不一致,其它数据暂未发现异常。第一反应可能是人为修改,如果用户有高权限帐号,是可以做到的,但检查所有帐号权限排除了这种可能。难道有黑客入侵?神经一下绷紧,仔细排查各种系统状态,很快也排除了这种可能。同时分析业务类型,有问题的值都是从机都是比主机少一秒,时间戳被改小一秒不能带来任何收益,被非法篡改的可能性基本排除。
近期,线上有个重要Mysql客户的表在从5.6升级到5.7后master上插入过程中出现"Duplicate key"的错误,而且是在主备及RO实例上都出现。以其中一个表为例,迁移前通过“show create table” 命令查看的auto increment id为1758609, 迁移后变成了1758598,实际对迁移生成的新表的自增列用max求最大值为1758609。用户采用的是Innodb引擎,而且据运维同学介绍,之前碰到过类似问题,重启即可恢复正常。
某业务CDB实例,每天在特地时间段内( 00:07:00 - 00:08:00左右)机器对应IO监控出现写入尖刺,且主从实例都有类似现象,从机器监控可以看到,问题确实存在。
数据字典(Data Dictionary)中存储了诸多数据库的元数据信息如图1所示,包括基本Database, table, index, column, function, trigger, procedure,privilege等;以及与存储引擎相关的元数据,如InnoDB的tablespace, table_id, index_id等。MySQL-8.0在数据字典上进行了诸多优化,本文将对其进行逐一介绍。
redo_log的作用设计初衷为了提高写入性能同时解决ACID中Duration。MySQL 8.0对redo_log进行了无锁化设计,去除了redo_log性能的瓶颈,从而在数据库整体性能上有了较大提升。本文将结合已有资料和最新MySQL release代码,介绍MySQL redo log优化,主要设计模块包括redo_log、mtr和一部分buffer/flush lists。
MySQL的执行过程包括多个子阶段:语法分析、语义检查、逻辑优化、物理优化和执行。其中逻辑优化和物理优化统称为查询优化。一个查询优化器的输入是查询树,输出是查询执行计划。
最近,腾讯云某内部系统不定期出现数据库访问行更新慢,数据库用户线程大量堆积的现象。从slow log中观察,大量update执行时间超过10秒,甚至个别update执行时间超过百秒,这已经严重影响该系统的正常运行。运维同学不得不采取杀死运行session的方式解决该问题,由于访问数据库的任务是离线后台批处理任务,因此会选择业务压力小的时候运行该任务,比如半夜12点,因此,运维同学必须半夜采取紧急措施,这给线上运行造成极大的负担。
数据库管理系统中,最重要的模块包括SQL优化器、SQL执行器、事务管理器等。SQL语句处理流程为:SQL输入->语法分析->语义检查->逻辑优化->物理优化->执行。其中SQL执行器就是按照SQL优化器生成的执行计划,有机的调用存储、索引、并发等模块,实现各种计划结点算法来完成数据的读取或者修改过程。在MySQL8.0中执行器部分代码发生了较大改变,新的执行器向经典的Iterator模型更接近了一步,我们暂时叫它iterator执行器。接下来我们分析一下这个新的执行器。
innodb的物理文件包括系统表空间文件ibdata,用户表空间文件ibd,日志文件ib_logfile,临时表空间文件ibtmp,undo独立表空间等。
InnoDB支持MVCC(Multi-Version Concurrency Control), undo日志中保存了多版本的记录,undo支持事务回滚的同时,也支持数据的一致性读。undo日志保存在回滚段中,undo日志的回收由purge操作进行。