一 redo undo binlog
第一点
redo是记录数据页变更操作的物理日志
undo是记录数据版本历史快照的逻辑日志
binlog 是记录事务语句的逻辑日志
第二点 当要修改数据时
1 undo生成目标数据的历史快照版本
分类 insert_undo,update_undo
格式 <事务,column,old_value>
redo记录针对目标数据页的操作和undo本身的操作
提供历史版本读取和事务回滚
2 二阶段提交
redo进行刷新->prepare
redo_buffer->redo_file->redo_disk(参数决定是否经过redofile flush操作)
binlog生成相应binlog_event并写入binlog_buffer-commit
binlog刷新,（参数不同是否决定文件刷新到磁盘 sync操作）
binlog_buffer->binlog_disk
3 数据页进行修改
4 数据页写入double write,double write进行刷新
5 数据页刷新到磁盘
二 mvcc机制
1 先形成一个活跃会话列表,其中最小事务ID和最大事务ID+1构成一个范围(read_view),接下来进行比较
2 如果会话本身小于最小事务ID,那么可以直接读取数据本身,证明目标数据没有被操作
3 如果会话本身大于最大事务ID+1(下一个可申请的事务ID),那么读取相应的快照,证明目标数据肯定被操作
4 如果会话本身处于这个范围,就进行循环匹配,如果会话事务ID匹配命中,则代表数据在被使用,读取数据快照,否正就直接读取数据本身
小case
核心思想就是取得目标行数据的当前版本号,进行比较判断,确认是否被使用.事实上,事务号会被随时更新,如果事务在被新事务使用,行数据存储的事务号也会同步更新.事务号是正序增长的, rr和rc都有mvcc,机制不同的地方就在于rr模式下只会生成一次read_view 所以是可以实现可重复读的
三 SSD优化策略
1 关闭double-write 双写是为了实现原子写出现的,先刷数据页到ibdata1,再刷脏页到数据文件中..而SSD本身实现了原子写,所以不再需要
2 关闭邻页刷脏 邻页刷脏是代表每次不光要刷脏页自己,还要查找相邻的符合要求(源码是一个去间)的脏页,目的是为了减少随机IO,但是消耗了时间,而随机IO在SSD并不存在,所以关闭
3 调整io-capation,每次刷新的脏页数量 来源于fio针对磁盘的压测 设置为磁盘的IOPS
4 调整innodb_flush_method为 o_dircet 数据文件的写入不再经过OS CACHE,记住这里是数据文件
5 增大redologfile单个大小,(适合初始化实例),减少针对单位置的反复重写
6 调整linux的IO调度算法为noop-noop是FIFO算法的优化版,还会对相邻IO进行合并,本身不区分IO请求种类,默认IO性能不存在问题
四 mysql锁机制
从锁粒度来说 分为 全局锁 表级锁 和 行锁
表级锁 又分为
表锁
元数据锁(关键字-升级)
非DDL
MDL_SHARED_WRITE/MDL_SHARED_READ
DDL阶段
MDL_SHARED_UPGRADABLE 禁止写,其他事务可以读取(共享锁) 升级到下一个锁
MDL_SHARED_NO_WRITE 禁止写,其他事务可以读取(共享锁) 非in-place的copy阶段 升级到下个锁,in-place等待
MDL_EXCLUSIVE 禁止读写->排他锁->rename-table
未提交事务和查询事务阻塞MDL就是在rename阶段无法申请到MDL排他锁导致串行化等待
行锁又分为 row-lock 锁定索引记录本身
gap lock 锁定索引记录间隙
next-key lock 锁定索引记录的间隙和记录本身,总结就是左开右闭
加索基本单位是nklock,
如果唯一索引会退化成row-lock,
如果是等值的非唯一索引 针对不唯一索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候 会都会按照正常的GAP LOCK锁定上下区间
如果是不存在记录的等值查询, 不论唯一/不唯一的索引 都会按照正常的GAP LOCK锁定上下区间
判断锁定范围的口诀:没有相等的范围值,直接比较辅助索引的锁定范围 有相等的范围值,再进一步进行辅助索引对应的主键进行二次判定
五 AHI-自适应HASH索引
目的:能够根据SQL的条件快速的定位到叶子节点的热点数据页.而并非需要通过B+树从root节点定位
结构: hash表,索引的前缀索引hash值-热点数据页形成k-v对应关系
构建: 收集 search_info(前缀索引) & block info(成功次数) 符合条件(次数和条数)的成功利用AHI检索的情况才会考虑构建AHI缓存
应用: SQL语句为唯一性索引(存在多列唯一性索引情况)简单条件查询,并且记录本身并不包含大字段
与change_buffer刚好相反,一个对应唯一性索引 一个对应非唯一性索引
六 char varchar
对于varchar mysql在内存空间申请大小取决于定义的字符数,但是在磁盘占用取决的是数据实际占用的空间.
对于 char 在内存空间申请和在磁盘占用就取决于定义的字符串,属于固定值的空间
对于char varchar的索引长度计算方式 是 (3utf8/4mb4)*定义字符+1(如果是null) + 2(varchar需要存储额外信息)
七 rdb与aof
rdb 二进制快照文件
1 bgsave/save 和设置单位时间内keys的变化数量
2 cow 技术 会fork一个子进程,针对数据页进行跟踪,当数据页发生变化时,才会申请空间进行拷贝副本. 大大节省了内存空间的占用,和父进程共享内存空间用来备份数据页不变的数据.
3 备份有效期是开始生成rdb的时候,可以理解成一个定时mysqldump增量备份,
4 恢复优先级是低于aof
aof 操作日志快照文件
1 持久化参数设置: 每秒同步,由操作系统同步.每次都同步
2 会根据持久化的参数设置来缓存命令,再执行相关命令
3 恢复优先级高于rdb
4 bgrewriteaof 触发rewrite, rewrite会遍历所有的数据进行记录和优化合并处理,写入临时aof文件中(期间的改变都会进行记录应用到临时aof文件中).最后再覆盖原aof文件,实现aof的重写功能
八 MHA切换流程
1 主检测线程进行mysql-master探测 如果三次探测失败 就进行下一步探测
2 第二检测脚本会从指定的从节点向主发生探测,如果也失败则执行切换任务
3 切换开始
1 首先获取所有从节点中最新的master binlog file和postion.然后尝试从原主进行binlog保存,如果能登录服务器的话
2 选择新的master,并对比最新从节点生成差异relay-log
3 针对新的master进行差异的relay-log和binlog数据补偿
4 新的master 绑定VIP 打开读写,对外提供服务
5 其他从节点进行差异的relay-log和binlog数据补偿
6 其他从节点change master to 新的master
九 MONGO整体同步流程
1) 全量同步开始，获取同步源上的最新时间戳t1 2) 全量同步集合数据，建立索引（比较耗时） 3) 获取同步源上最新的时间戳t2 4) 重放t1到t2之间所有的oplog 5) 全量同步结束
简而言之 全量拷贝数据+建立索引的过程中也会重放oplog,之后才是增量同步
全量同步数据的时候，会不会源数据的oplog被覆盖了导致全量同步失败？在3.4之后拷贝途中会将oplog缓存到本地进行应用 在3.4之前可能会
十 mongo的数据备份与恢复
全量备份方式
1 LVM快照需要开jonural日志 2 mongodump 3 ECS快照模式(云环境) 4 从节点冷备模式-(加锁,直接拷贝数据目录,解锁)
数据恢复方式
1 mongo延时库(参与投票但不参与选举) 2 全备抽取数据(如果有的话) 3 事先做人工备份(常见于线上数据人为发起的变更) 4 采用全量+oplog增量方式
备份恢复
全量备份还原
mongodump --port $port --oplog -o $backup_dir
mongorestore --port $port --oplogReplay --drop $backup_dir
增加备份还原
mongordump --port $port -d local -c oplog.rs -o $backup_dir
mongorestore --port $port --oplogReplay $backup_dir/local/oplog.rs.bson
十一 mongodb的选举机制
1 mongodb的每个节点成员都会同其他节点进行周期性的节点检测 如果超过一定的阈值没有反馈,就认为其他节点不可用
2 当主挂掉后.mongodb的所有从节点会进行选举
当选成新主的条件
0 原主已经挂掉
1 optime必须是所有成员中最新的,也即是数据是最新的
2 本身具备当选成新主的必备条件 优先级不为0 不属于冲裁节点
3 收获超过集群所有成员超过一半以上的投票数
3 当选择新主后 其他从节点会指向新主
4 mongodb是类raft协议 但是不是raft协议
十二 mongodb的磁盘空间
3.2之前是repairdatabase 全局锁 3.2 是DB锁级别的compact,针对DB级别不能读写
十三 WT引擎对比MMAP引擎的优势
1 能够有效的控制内存占用
2 更细粒度的锁 基于collection 级别
3 能够进行数据和索引压缩,减少磁盘占用,但是会消耗cpu
4 能够进行DB级别的磁盘回收而不是阻塞全局repairdatabase
5 针对多核cpu有更好的发挥表现,能提升性能