主从复制
Mysql的主从复制主要有三个线程:master(binlog dump thread)、slave(I/O thread
、 SQL thread),master一条线程和salve中的两条线程。
- 主节点binlog,主从复制的基础是主库距离数据库的所有变更记录到binlog,binlog是数据库服务器启动的那一刻起,保存所有修改数据库结构或内容的一个文件;
- 主节点log dump线程,当binlog有变动时,log dump线程读取其内容并发送给从节点;
- 从节点I/O线程接收binlog内容,并将其写入到relay log文件中;
- 从节点的sql线程读取relay log文件内容对数据更新进行重放,最终保证主从数据的一致性。
注:主从节点使用binlog文件+position皮一两来定位主从同步的位置,从节点会保存其已接收到的皮一两,如果从节点发生宕机重启,则会自动从position的位置发起同步。
由于mysql默认的复制方式是异步的,主库把日志发送给从库后不关心从库是否已经处理,这样会产生一个问题就是假设主库挂了,从库处理失败了,这时候从库升为主库后,日志就丢失率。由此产生两个概念:
全同步复制
主库写入binlog后强制同步日志到从库,所有的从库都执行完成后才返回给客户端,但是很显然这个方式性能会受到严重影响。
半同步复制
从库写入日志成功后返回ACK确认给主库,主库收到至少一个从库的确认就认为写操作完成。
Buffer Pool
Buffer pool,128M的内存空间,Buffer pool是加快读的过程,加载数据的时候先从磁盘加载到缓冲池,再读change buffer是方便写的过程,目的是为了减少写操作的磁盘IO。如果需要修改的数据当前不在buffer pool,就先将修改保存到change buffer,未来读取到对应数据页的时候再merge到原数据里面去。
free链表:记录Buffer pool当中的空白页;
flush链表:判断一页是不是脏页。Buffer Pool当中的页如果被修改(update)就成为脏页,后台有一个线程会定时将这些脏页持久化到磁盘当中。
lru链表:Buffer pool的淘汰机制。分热数据和冷数据区域,优先淘汰冷数据区域的尾部,新的页加入到冷数据区域的头部。假设某页第一次加入到链表的时间节点为t1,第二次为t2,如果t2-t1>1s,那么就把这一页加入到热数据区域的头部。
update语句流程
- 首先执行器先找通过存储引擎找到这一行。如果这个字段有索引会通过索引来找;
- 如果这一行的数据在buffer pool里,可以直接修改buffer pool中的数据,否则从磁盘中加载该数据页到buffer pool再修改;
- 修改之后将更新操作同步到redo log;
- 执行器生成操作的bin log,并把bin log写入磁盘;
- 事务提交的时候,会对buffer pool中的数据刷脏(数据持久化)
日志
redo log | bin log | |
---|---|---|
级别 | 存储引擎级别 | Server级别 |
日志类型 | 物理日志,记录数据页面更新的内容 | 逻辑日志,记录sql语句 |
写方式 | 循环写,日志空间大小固定 | 追加写,不限大小 |
功能 | 用作宕机后的数据修复 | 主从复制 |