乐趣区

mysql及proxy

整体架构 / 流程
主流程:主函数在 sql/amin.cc 中调用 Mysqld.cc 中 mysqld_main

首先载入篇日志,信号注册,plugin_register(mysql 是插件式存储引擎设计,innodb,myisam 等都是插件,在这里注册),核心为 mysqld_socket_acceptor->connection_event_loop();
监听处理循环 poll。process_new_connection 处理 handler 有三种,线程池方式只用于商业,一个线程处理所有请求,一个连接一个线程(大多数选择 Per_thread_connection_handler)。
若 thread_cache 中有空闲直接获取,否则创建新的用户线程。进入用户线程的 handle_connection 3.1 mysql 网络通信一共有这几层:THD | Protocol | NET | VIO | SOCKET,protocol 对数据的协议格式化,NET 封装了 net buf 读写刷到网络的操作,VIO 是对所有连接类型网络操作的一层封装(TCP/IP, Socket, Name Pipe, SSL, SHARED MEMORY),handle_connection 初始化 THD(线程),开始 do_command(关于 THD,有个很好的图:http://mysql.taobao.org/month…)3.2.do_command=>dispatch_comand=>mysql_parse=》【检查 query_cache 有缓存直接返回否则 =》】parse_sql=》mysql_execute_cmd 判断 insert 等调用 mysql_insert,每条记录调用 write_record,这个是各个引擎的基类,根据操作表类型调用引擎层的函数 =》写 binlog 日志 =》提交 / 回滚。注意大家可能都以为是有 query_cache 的。但是从 8.0 开启废弃了 query_cache。第二正会讲一下
除了用户线程和主线程,在启动时,还创建了 timer_notify 线程。由于为了解决 DDL 无法做到 atomic 等,从 MySQL8.0 开始取消了 FRM 文件及其他 server 层的元数据文件(frm, par, trn, trg, isl,db.opt),所有的元数据都用 InnoDB 引擎进行存储, 另外一些诸如权限表之类的系统表也改用 InnoDB 引擎。因此在加载这些表时,创建了 innodb 用到的一系列线程。

从插入流程开始

外层 handle_connection=>do_commannd=>dispatch_command=>mysql_parse=>mysql_execute_commannd=>sql_cmd_dml::execute=> execute_inner while{对每条记录执行 write_record} =>ha_write_row【返回到这里不出错记录 binlog】, 调用引擎 table->file->ha_write_row(table->record[0])
引擎层:row_insert_for_mysql_using_ins_graph 开始,有开启事务的操作,trx_start_low。首先,需要分配回滚段,因为会修改数据,就需要找地方把老版本的数据给记录下来,其次,需要通过全局事务 id 产生器产生一个事务 id,最后,把读写事务加入到全局读写事务链表 (trx_sys->rw_trx_list),把事务 id 加入到活跃读写事务数组中(trx_sys->descriptors) 在 InnoDB 看来所有的事务在启动时候都是只读状态,只有接受到修改数据的 SQL 后 (InnoDB 接收到才行。因为在 start transaction read only 模式下,DML/DDL 都被 Serve 层挡掉了) 才调用 trx_set_rw_mode 函数把只读事务提升为读写事务。

整体流程图如下:
必须有这些步骤的原因:[1]为了快,所有数据先写入内存,再刷脏 [2] 为了防止数据页写过程中崩溃数据的持久性 =》先写 redo 保证重启后可以恢复。日志写不成功不操作,日志是顺序写,内容少,可以同步等。(最好是物理重做)。[3]异常回滚 =》物理回滚反解复杂,需要一个逻辑日志。基于 undo log 又实现了 MVCC unlog 等也要保证操作持久化原子化。[4]为了删除不每次整理页,只标记,为了真正删除 /undo 不需要的清除 =》purge[5]flush 对一个 pageid 多次操作合并在一起减少随机操作 =》二级索引非唯一 change buff[6]Flush 过程中一个页部分写成功就崩溃,无法正确后恢复 =》二次写 [7] 为完整的主链路。[8]为异步的刷盘链路
性能
磁盘,B+ 树
先来个准确的 B + 比 B 为何更适合:区别两点,一个是 B 树搜索是可以止于非页节点的,包含数据(包含数据在磁盘中页的位置),且数据只出现在树中一次。另一点是叶子节点有双向链表。第一点使得节点可以包含更多路(因为不存数据在磁盘中页的位置,只包含下一层的指针页位置,B 树这两个都要包含),层高会更少;只能到页节点搜索结束,性能稳定。第二点为了扫描和范围索引。

内存 buffer
所有数据页。都走这套。包括 undo 等所有的数据页都存储在一个 LRU 链表上,修改过的 block 被加到 flush_list 上,解压的数据页被放到 unzip_LRU 链表上。

name
desc

buf_pool_t::page_hash
page_hash 用于存储已经或正在读入内存的 page。根据 <space_id, page_no> 快速查找。当不在 page hash 时,才会去尝试从文件读取

buf_pool_t::LRU
LRU 上维持了所有从磁盘读入的数据页,该 LRU 上又在链表尾部开始大约 3 / 8 处将链表划分为两部分,新读入的 page 被加入到这个位置;当我们设置了 innodb_old_blocks_time,若两次访问 page 的时间超过该阀值,则将其挪动到 LRU 头部;这就避免了类似一次性的全表扫描操作导致 buffer pool 污染

buf_pool_t::free
存储了当前空闲可分配的 block

buf_pool_t::flush_list
存储了被修改过的 page,根据 oldest_modification(即载入内存后第一次修改该 page 时的 Redo LSN)排序

buf_pool_t::flush_rbt
在崩溃恢复阶段在 flush list 上建立的红黑数,用于将 apply redo 后的 page 快速的插入到 flush list 上,以保证其有序

buf_pool_t::unzip_LRU
压缩表上解压后的 page 被存储到 unzip_LRU。buf_block_t::frame 存储解压后的数据,buf_block_t::page->zip.data 指向原始压缩数据。

buf_pool_t::zip_free[BUF_BUDDY_SIZES_MAX]
用于管理压缩页产生的空闲碎片 page。压缩页占用的内存采用 buddy allocator 算法进行分配。

page_hash 查找。LRU 只是用于淘汰。一份 block。指针保存在 hash 和 lru 上
当另外一个线程也想请求相同 page 时,首先根据 space id 和 page no 找到对应的 buffer pool instance。然后查询 page hash。如果看到 page hash 中已经有对应的 block 了,说明 page 已经或正在被读入 buffer pool,如果 io_fix 为 BUF_IO_READ,说明正在进行 IO,就通过加 X 锁的方式做一次 sync(buf_wait_for_read),确保 IO 完成。
如果没有则表示需要从磁盘读取。在读盘前首先我们需要为即将读入内存的数据页分配一个空闲的 block。当 free list 上存在空闲的 block 时,可以直接从 free list 上摘取;如果没有,就需要从 unzip_lru 或者 lru 上驱逐 page。先 unzip lru。再 lru 是否有可替换 page, 直接释放,否则可能是脏页多,再线程在 LRU 上做脏页刷新。后台线程也会定期做脏页刷新。
一个流程对 buffer 的操作步骤:
索引:聚簇索引
见上
二级索引 change buffer
对非唯一二级索引页,delete_mark,delete,insert 顺序插入缓冲区,合并减少随机 IO。

物理:ibdata 第 4 个 page B+ Tree(key:spaceid,offset,counter)
内存:ibuf,B+ 树
内容:space,offset, 发生 change 的数据
写入:1 不会导致空 page:delete 时只有一条记录 拒绝 2 不会导致分裂,insert 时检查 IBUF BITMAP 标识剩余空间大小,超出触发 merge 拒绝
merge:(在很多情况都需要把 ibuf 里的页进行合并)1. 辅助索引页被读取到缓冲池时 2. 插入时预估 page no 空间不足 3.ibuf 空间不足 4. 插入 ibuf 可能产生 ibuf Tree 的索引分裂 5.Master(IDLE ,ACTIVE,SHUTDOWN)……
Purge 操作和 insert 在 ibuf 并发问题在 purge 模式下,用 ibuf 同时将 watch 插入到 hash table 中, 如果都在内存里,会给同一份 page 加锁,没问题,但是要两个线程都写入 ibuf_insert 时,是没办法控制顺序的(本来就允许这种无序,因为非唯一)。所以需要一个进入后,另一个就放弃,不能都写入 ibuf。在 purge 模式下,用 ibuf 同时将 watch 插入到 hash table 中,insert 就不会再放入 ibuf 中了其他读取清除这个 buf.

功能——事务

A undolog
C(一个事务中间状态可见性)MVCC
I (多个事物之间可见性 / 操作不干扰) MVCC
D redolog

内存总体流程

undolog

物理:回滚段,rseg0 在 ibdata 第 6 个 page,1~32 临时表空间,33~128 独立表空间或 ibdata, 存储在 ibdata,临时表空间或单独表空间。每个表空间可以包含若干个段。每个段有 1024 个控制页 slot 和历史表。每个 slot 对应一个 undo log 对象,有一个 undo log header.
内存:全局 trx_sys->rseg_array。每个事务 trx->rsegs
内容:逻辑日志 Insert undo 日志记录插入的唯一键值的 len 和 value。Update undo 日志在 insert undo 基础上,同时记录了旧记录事务 id,以及被更新字段的旧数据
写入 入口函数:btr_cur_ins_lock_and_undoa) 从 chached_list 或分配一个空闲 slot 创建 undo 页 b) 顺序写 undo log header 和记录 c) 在事务提交阶段,加入到 history list 或释放【见事务提交】Undo log 的写入在一个单独的 mtr 中,受 redo log 的保护,先讲一个子事务 mtr。Mtr 是 InnoDB 对物理数据文件操作的最小原子单元,保证持久性, 用于管理对 Page 加锁、修改、释放、以及日志提交到公共 buffer 等工作。开启时初始化 m_impl,比如 mlog 用于存储 redo log 记录 提交时需要将本地产生的日志拷贝到公共缓冲区,将修改的脏页放到 flush list 上。
回滚:入口函数:row_indo_step 解析老版本记录,做逆向操作
事务提交时 undolog 入口函数:trx_commit_low–>trx_write_serialisation_history 事务提交整体流程,注意看下大概顺序,后面会具体讲

写完 redo 就可以提交了。
生成事务 no。如果有 update 类的 undo 日志。加入到 purge_queue(清理垃圾),history 链表(维护历史版本)
子事务提交。Redo log 写到公共缓存
释放 MVCC 的 readview;insert 的 undo 日志释放(可 cache 重用,否则全部释放包括 page 页)
刷日志

在该函数中,需要将该事务包含的 Undo 都设置为完成状态,先设置 insert undo,再设置 update undo(trx_undo_set_state_at_finish),完成状态包含三种:
如果当前的 undo log 只占一个 page,且占用的 header page 大小使用不足其 3 / 4 时(TRX_UNDO_PAGE_REUSE_LIMIT),则状态设置为 TRX_UNDO_CACHED,该 undo 对象会随后加入到 undo cache list 上;
如果是 Insert_undo(undo 类型为 TRX_UNDO_INSERT),则状态设置为 TRX_UNDO_TO_FREE;
如果不满足 a 和 b,则表明该 undo 可能需要 Purge 线程去执行清理操作,状态设置为 TRX_UNDO_TO_PURGE。

对于 undate undo 需要调用 trx_undo_update_cleanup 进行清理操作。
注意上面只清理了 update_undo,insert_undo 直到事务释放记录锁、从读写事务链表清除、以及关闭 read view 后才进行,
这里的 slot,undo page ,history 关系:
每个 rseg 控制页有 1024 个 slot 和 history。undo page 释放后或者移到 history list 后,就可以把 slot 清空、undo page 转为 cache 不释放则不动 slot

purge: 删除(更新数据的真正删除),清除过期 undo。入口函数 srv_do_purge 作用: 对于用户删除的数据,InnoDB 并不是立刻删除,而是标记一下,后台线程批量的真正删除。类似的还有 InnoDB 的二级索引的更新操作,不是直接对索引进行更新,而是标记一下,然后产生一条新的。这个线程就是后台的 Purge 线程。此外,清除过期的 undo,histroy list,指的是 undo 不需要被用来构建之前的版本,也不需要用来回滚事务。我们先来分析一下 Purge Coordinator 的流程。启动线程后,会进入一个大的循环,循环的终止条件是数据库关闭。在循环内部,首先是自适应的 sleep,然后才会进入核心 Purge 逻辑。sleep 时间与全局历史链表有关系,如果历史链表没有增长,且总数小于 5000,则进入 sleep,等待事务提交的时候被唤醒(srv_purge_coordinator_suspend)。退出循环后,也就是数据库进入关闭的流程,这个时候就需要依据参数 innodb_fast_shutdown 来确定在关闭前是否需要把所有记录给清除。接下来,介绍一下核心 Purge 逻辑。srv_do_purge

1)首先依据当前的系统负载来确定需要使用的 Purge 线程数(srv_do_purge),即如果压力小,只用一个 Purge Cooridinator 线程就可以了。如果压力大,就多唤醒几个线程一起做清理记录的操作。如果全局历史链表在增加,或者全局历史链表已经超过 innodb_max_purge_lag,则认为压力大,需要增加处理的线程数。如果数据库处于不活跃状态(srv_check_activity),则减少处理的线程数。
2)如果历史链表很长,超过 innodb_max_purge_lag,则需要重新计算 delay 时间(不超过 innodb_max_purge_lag_delay)。如果计算结果大于 0,则在后续的 DML 中需要先 sleep,保证不会太快产生 undo(row_mysql_delay_if_needed)。
3)从全局视图链表中,克隆最老的 readview(快照、拿视图为了拿事务 id.undo 日志中 upadte 记了事务 id),所有在这个 readview 开启之前提交的事务所产生的 undo 都被认为是可以清理的。克隆之后,还需要把最老视图的创建者的 id 加入到 view->descriptors 中,因为这个事务修改产生的 undo,暂时还不能删除(read_view_purge_open)。
4)从 undo segment 的最小堆中(堆存放每个段未被 purge 的最老的 undo 页),找出最早提交事务的 undolog(trx_purge_get_rseg_with_min_trx_id),如果 undolog 标记过 delete_mark(表示有记录删除操作),则把先关 undopage 信息暂存在 purge_sys_t 中(trx_purge_read_undo_rec)。
5)依据 purge_sys_t 中的信息,读取出相应的 undo,同时把相关信息加入到任务队列中。同时更新扫描过的指针,方便后续 truncate undolog。
6)循环第 4 步和第 5 步,直到为空,或者接下到 view->low_limit_no,即最老视图创建时已经提交的事务,或者已经解析的 page 数量超过 innodb_purge_batch_size。(把 delete 和 Undopage 分别存放,detele 给工作线程删除)
7)把所有的任务都放入队列后,就可以通知所有 Purge Worker 线程 (如果有的话) 去执行记录删除操作了。删除记录的核心逻辑在函数 row_purge_record_func 中。有两种情况,一种是数据记录被删除了,那么需要删除所有的聚集索引和二级索引(row_purge_del_mark),另外一种是二级索引被更新了(总是先删除 + 插入新记录),所以需要去执行清理操作。
8)在所有提交的任务都已经被执行完后,就可以调用函数 trx_purge_truncate 去删除 update undo(insert undo 在事务提交后就被清理了)。每个 undo segment 分别清理,从自己的 histrory list 中取出最早的一个 undo,进行 truncate(trx_purge_truncate_rseg_history)。truncate 中,最终会调用 fseg_free_page 来清理磁盘上的空间。

MVCC
undo+read view 写时并发读 ReadView::id 创建该视图的事务 ID;
m_ids 创建 ReadView 时,活跃的读写事务 ID 数组,有序存储;记录 trx_id 不在 m_ids 中可见
m_low_limit_id  当前最大事务 ID;记录 rx_id>=ReadView::m_low_limit_id,则说明该事务是创建 readview 之后开启的,不可见
Rem_up_limit_id ;m_ids 集合中的最小值; 记录 trx_id< m_up_limit_id 该事务在创建 ReadView 时已经提交了,可见
二级索引回聚簇索引中。若不可见,则通过 undo 构建老版本记录。
redolog

物理:log 文件,ib_logfile 覆盖写
内存:log buffer log_sys(记了日志在磁盘和内存中用到的信息,比如总大小,一些需要刷盘的阈值等)
内容:记录物理位置 spaceid,page,offset 上要操作的逻辑日志
写入 每个子事务的操作都会写入 log(mtr.m_impl.m_log 中) mlog_open_and_write_index=》memcpy=》mlog_close

提交 子事务提交写入缓冲区
将本次的表空间和文件信息加入到一个内存链表上 (去除恢复中对数据字典的依赖)

提交时,准备 log 内容,提交到公共 buffer 中,并将对应的脏页加到 flush list 上
Step 1: mtr_t::Command::prepare_write()
1. 若当前 mtr 的模式为 MTR_LOG_NO_REDO 或者 MTR_LOG_NONE,则获取 log_sys->mutex,从函数返回
2. 若当前要写入的 redo log 记录的大小超过 log buffer 的二分之一,则去扩大 log buffer,大小约为原来的两倍。
3. 持有 log_sys->mutex
4. 调用函数 log_margin_checkpoint_age 检查本次写入:如果本次产生的 redo log size 的两倍超过 redo log 文件 capacity,则打印一条错误信息;若本次写入可能覆盖检查点,还需要去强制做一次同步 *chekpoint*
5. 检查本次修改的表空间是否是上次 checkpoint 后第一次修改(fil_names_write_if_was_clean)
如果 space->max_lsn = 0,表示自上次 checkpoint 后第一次修改该表空间:
a. 修改 space->max_lsn 为当前 log_sys->lsn;
b. 调用 fil_names_dirty_and_write 将该 tablespace 加入到 fil_system->named_spaces 链表上;
c. 调用 fil_names_write 写入一条类型为 MLOG_FILE_NAME 的日志,写入类型、spaceid, page no(0)、文件路径长度、以及文件路径名。
在 mtr 日志末尾追加一个字节的 MLOG_MULTI_REC_END 类型的标记,表示这是多个日志类型的 mtr。
如果不是从上一次 checkpoint 后第一次修改该表,则根据 mtr 中 log 的个数,或标识日志头最高位为 MLOG_SINGLE_REC_FLAG,或附加一个 1 字节的 MLOG_MULTI_REC_END 日志。
Step 2: 拷贝
若日志不够,log_wait_for_space_after_reserving

Step 3:如果本次修改产生了脏页,获取 log_sys->log_flush_order_mutex,随后释放 log_sys->mutex。
Step 4. 将当前 Mtr 修改的脏页加入到 flush list 上,脏页上记录的 lsn 为当前 mtr 写入的结束点 lsn。基于上述加锁逻辑,能够保证 flush list 上的脏页总是以 LSN 排序。
Step 5. 释放 log_sys->log_flush_order_mutex 锁
Step 6. 释放当前 mtr 持有的锁(主要是 page latch)及分配的内存,mtr 完成提交。

刷盘 整个事务的提交 trx_commit. 参数 innodb_flush_log_at_trx_commit 当设置该值为 1 时,每次事务提交都要做一次 fsync,这是最安全的配置,即使宕机也不会丢失事务 当设置为 2 时,则在事务提交时只做 write 操作,只保证写到系统的 page cache,因此实例 crash 不会丢失事务,但宕机则可能丢失事务 当设置为 0 时,事务提交不会触发 redo 写操作,而是留给后台线程每秒一次的刷盘操作,因此实例 crash 将最多丢失 1 秒钟内的事务,写入一条 MLOG_FILE_NAME

刷脏 刷脏会在以下情形被触发
启动和关闭时会唤醒刷脏线程
redo log 可能覆盖写时,调用单独线程把未提交 LSN 对应的 redo log 刷盘
LRU LIST 在未能自己释放时,先自己刷脏一页,不行再 唤醒刷脏线程
刷脏线程

innodb_page_cleaners 设置为 4,那么就是一个协调线程(本身也是工作线程),加 3 个工作线程,工作方式为生产者 - 消费者。工作队列长度为 buffer pool instance 的个数,使用一个全局 slot 数组表示。

buf_flush_page_cleaner_coordinator 协调线程主循环主线程以最多 1s 的间隔或者收到 buf_flush_event 事件就会触发进行一轮的刷脏。协调线程首先会调用 pc_request()函数,这个函数的作用就是为每个 slot 代表的缓冲池实例计算要刷脏多少页,然后把每个 slot 的 state 设置 PAGE_CLEANER_STATE_REQUESTED, 唤醒等待的工作线程。由于协调线程也会和工作线程一样做具体的刷脏操作,所以它在唤醒工作线程之后,会调用 pc_flush_slot(),和其它的工作线程并行去做刷脏页操作。一但它做完自己的刷脏操作,就会调用 pc_wait_finished()等待所有的工作线程完成刷脏操作。完成这一轮的刷脏之后,协调线程会收集一些统计信息,比如这轮刷脏所用的时间,以及对 LRU 和 flush_list 队列刷脏的页数等。然后会根据当前的负载计算应该 sleep 的时间、以及下次刷脏的页数,为下一轮的刷脏做准备。

buf_flush_page_cleaner_worker 工作线程主循环启动后就等在 page_cleaner_t 的 is_requested 事件上,一旦协调线程通过 is_requested 唤醒所有等待的工作线程,工作线程就调用 pc_flush_slot()函数去完成刷脏动作。pc_flush_slot:先找到一个空间的 slot,page_cleaner->n_slots_requested–; // 表明这个 slot 开始被处理,将未被处理的 slot 数减 1 page_cleaner->n_slots_flushing++; // 这个 slot 开始刷脏,将 flushing 加 1 slot->state = PAGE_CLEANER_STATE_FLUSHING; 刷 LRU,FLUSH LISTpage_cleaner->n_slots_flushing–; // 刷脏工作线程完成次轮刷脏后,将 flushing 减 1 page_cleaner->n_slots_finished++; // 刷脏工作线程完成次轮刷脏后,将完成的 slot 加一 slot->state = PAGE_CLEANER_STATE_FINISHED; // 设置此 slot 的状态为 FINISHED 若是最后一个,os_event_set(page_cleaner->is_finished)pc_wait_finished:os_event_wait(page_cleaner->is_finished); 统计等
每次刷多少 srv_max_buf_pool_modified_pct 决定
2. log_checkpoint
在主线程,合并 insertbuffer,等需要 redo log 空间的以及事务提交后等都会调用 log_free_check_wait =》调用单独的 log checkpoint 进程 这里如果 page cleaner 在 ACTIVE 唤醒 buf_flush_event(buf_flush_page_coordinator_thread 监听),否则自己 buf_flush_sync_all_buf_pools。
redo checkpoint 的入口函数为 log_checkpoint,其执行流程如下:Step1. 持有 log_sys->mutex 锁,并获取 buffer pool 的 flush list 链表尾的 block 上的 lsn,这个 lsn 是 buffer pool 中未写入数据文件的最老 lsn,在该 lsn 之前的数据都保证已经写入了磁盘。Step 2. 调用函数 fil_names_clear
扫描 fil_system->named_spaces 上的 fil_space_t 对象,如果表空间 fil_space_t->max_lsn 小于当前准备做 checkpoint 的 Lsn,则从链表上移除并将 max_lsn 重置为 0。同时为每个被修改的表空间构建 MLOG_FILE_NAME 类型的 redo 记录。(这一步未来可能会移除,只要跟踪第一次修改该表空间的 min_lsn,并且 min_lsn 大于当前 checkpoint 的 lsn,就可以忽略调用 fil_names_write)
写入一个 MLOG_CHECKPOINT 类型的 CHECKPOINT REDO 记录,并记入当前的 checkpoint LSN
Step3 . fsync redo log 到当前的 lsn 调用 fil_flush_file_spaces(关闭时 srv_shutdown_log,崩溃恢复……)Step4. 写入 checkpoint 信息
函数:log_write_checkpoint_info –> log_group_checkpoint
checkpoint 信息被写入到了第一个 iblogfile 的头部,但写入的文件偏移位置比较有意思,当 log_sys->next_checkpoint_no 为奇数时,写入到 LOG_CHECKPOINT_2(3 *512 字节)位置,为偶数时,写入到 LOG_CHECKPOINT_1(512 字节)位置。
在 crash recover 重启时,会读取记录在 checkpoint 中的 lsn 信息,然后从该 lsn 开始扫描 redo 日志。
Checkpoint 操作由异步 IO 线程执行写入操作,当完成写入后,会调用函数 log_io_complete 执行如下操作:
fsync 被修改的 redo log 文件
更新相关变量:
log_sys->next_checkpoint_no++
log_sys->last_checkpoint_lsn = log_sys->next_checkpoint_lsn
释放 log_sys->checkpoint_lock 锁

崩溃恢复 1. 从第一个 iblogfile 的头部定位要扫描的 LSN(数据落盘点)2. 扫描 redo log 1)第一次 redo log 的扫描,主要是查找 MLOG_CHECKPOINT,不进行 redo log 的解析,2)第二次扫描是在第一次找到 MLOG_CHECKPOINT(获取表和路径)基础之上进行的,该次扫描会把 redo log 解析到哈希表中,如果扫描完整个文件,哈希表还没有被填满,则不需要第三次扫描,直接进行 recovery 就结束 3)第二次扫描把哈希表填满后,还有 redo log 剩余,则需要循环进行扫描,哈希表满后立即进行 recovery,直到所有的 redo log 被 apply 完为止。3. 具体 redo log 的恢复 MLOG_UNDO_HDR_CREATE:解析事务 ID,为其重建 undo log 头;MLOG_REC_INSERT 解析出索引信息(mlog_parse_index)和记录信息(page_cur_parse_insert_rec)等 在完成修复 page 后,需要将脏页加入到 buffer pool 的 flush list 上;查找红黑树找到合适的插入位置 MLOG_FILE_NAME 用于记录在 checkpoint 之后,所有被修改过的信息(space, filepath);MLOG_CHECKPOINT 用于标志 MLOG_FILE_NAME 的结束。
在恢复过程中,只需要打开这些 ibd 文件即可,当然由于 space 和 filepath 的对应关系通过 redo 存了下来,恢复的时候也不再依赖数据字典。
在恢复数据页的过程中不产生新的 redo 日志;

二次写 redo 会记 spaceid,pageno, 偏移量内的逻辑日志只记录:’这是一个插入操作’和’这行数据的内容‘。为了省地方。但是这样就有个问题。在 redo log 恢复执行时,如果执行逻辑时一半断电了,比如已经某地址加了一个记录数。但又断电了,重新灰度执行又会执行一遍。就会在地址后又加一条。写坏了。这就需要在脏页落盘时采取二次写。数据写入 ibd 前先顺序写入 ibdata. 在崩溃恢复时,先检验 checksum. 不合法载入 ibdata 的数据。

Redo 为了保证原子性,要求一块一写。不够的话要先读旧的然后改然后写。以 512 字节 (最小扇区) 对其方式写入,不需要二次写。设置一个值 innodb_log_write_ahead_size,不需要这个过程,超过该值补 0 到一块直接插入

server 与 innodb 的事务保证

server 和引擎层事务的界限 1. 开启事务。server 只会调用引擎层。server 层如果不以命令,是不会显示开启事务的。在 SQLCOM_BEGIN 等命令会调用 trans_begin 分布式事务会调 trans_begin(跟踪下)证明是正确的,在外层 trans_begin 并没有调用。并不研究了 提交会在 server 层调用各个引擎的事务提交。下面说下 innodb 层的 trx 2. 提交事务。根据是否开启 binlog 和是否有多个引擎执行不同。比如开了 Binlog 且使用了事务引擎,用 Mysql_bin_log 的两阶段和组提交。如果没有用事务引擎,直接记 log 等就可以 3. 事务回滚:分为真正 xa 回滚还是普通回滚。普通回滚调用引擎层回滚 4. 崩溃恢复:没有 server 层的崩溃恢复
开启 分配回滚段,获取事务 id,加入事务链表
提交 入口:MYSQL_BIN_LOG::commit,如果是分布式事务,用 xa,两阶段。prepare 和 commit。我们先研究普通的提交。XA 不作为重点。但是由于 server 层和 Innodb 层两个日志,需要保证顺序,也按照 XA 的两阶段设计。也叫内部 xa 1) xa 两阶段 Prepare undo log 写入 xid, 设置状态为 PREPARED Commit   Flush Stage: 由 leader 依次为别的线程对 flush redo log 到 LSN,再写 binlog 文件 Sync Stage: 如果 sync_binlog 计数超过配置值,以组为维度文件 fsync Commit Stage:队列中的事务依次进行 innodb commit,修改 undo 头的状态为完成;并释放事务锁,清理读写事务链表、readview 等一系列操作。2) 原因 两阶段是为了保证 binlog 和 redo log 一致性。server 和备库用 binlog 来恢复同步。innodb 用 undo 和 redo 恢复。1 落 undo 2flush redo 3 flush binlog 4fsync binlog 5fsync redo [ps:sync 可能只是内核缓冲放入磁盘队列,fsync 只保证放入磁盘,都是同步] 2 要在 3 前 因为要先保证 redo 写了才算是事务执行了,否则无法回滚就记了 binlog 4 要在 5 前 提交成功,redo 才会落盘成功,如果先 redo 再 binlog, 但是 binlog 落盘失败,不会回滚,binlog 少记录 但是如果按照 4 到 5 的顺序,有 binlog 落盘成功,如果此时正常,5 失败会回滚,按照 undo 的内容逆着执行一次,binlog 记录了重新执行的,可以正常恢复数据;如果此时异常宕机,无法回滚,就会出问题。binlog 已经落盘,redo 没有落盘。此时数据同步导致主从不一致。因此加两阶段。在第一阶段在写入 xid,undo 设置为 prepare。如果在宕机恢复时对于 prepare 中的发现 binlog 的 xid 没有被执行,重新执行一遍。prepare 阶段的 redo log 可以先不写,在 commit 阶段一起写。只要保证 flush redo 在 flush binlog 前就可以 两阶段其实也是 undo 标识一下 binlog 和 redolog 还不一致。
3) 组提交:两阶段提交,在并发时无法保证顺序一致,用 ordered_commit 控制

如图在 Online backup taken 时,那么事务 T1 在备机恢复 MySQL 数据库时,发现 T1 未在存储引擎内提交,那么在恢复时,T1 事务就会被回滚。数据不一致。
如果关闭 binlog_order_commits。事务各自提交。这时候没有设置不写 redo log。不能保证 Innodb commit 顺序和 Binlog 写入顺序一直,但是不会影响数据一致性。只是物理备份数据不一致。但是依赖于事务页上记录 binlog 恢复的,比如 xtrabackup 就会发生备份数据不一致的情况。
回滚两阶段:正常应该根据 undo 回滚, 但看到 undo 为 iprepare 且 binlog 有,就不回滚当由于各种原因(例如死锁,或者显式 ROLLBACK)需要将事务回滚时,ha_rollback_trans=》ha_rollback_low,进而调用 InnoDB 函数 trx_rollback_for_mysql 来回滚事务。对于 innodb 回滚的方式是提取 undo 日志,做逆向操作。提交失败会回滚。走的非 xa,调用 trx_rollback_for_mysql。原来一直纠结 binlog 会不会删除。。。跟踪了好久也没看出来,其实是 undo 中的在提交时重新写一下 binlog。这里在子事务里会介绍。
分布式
分布式事务
主从复制

三种日志模式 1. 基于行的复制  row 优点:符合幂等性,高度保障数据一致。缺点:数据量大 2. 基于语句的复制  statement 优点:日志量少缺点:特定功能函数导致主从数据不一致,重复执行时无法保证幂等
3. 混合类型的复制  mixed  (默认语句,语句无法精准复制,则基于行)

主从同步过程

其中 1. Slave 上面的 IO 线程连接上 Master,并请求从指定日志文件的指定位置 (或者从最开始的日志) 之后的日志内容;
重放过程和 master 一样,也 redolog

GTID MySQL 5.6 引入全局事务 ID 的首要目的,是保证 Slave 在复制的时候不会重复执行相同的事务操作;其次,是用全局事务 IDs 代替由文件名和物理偏移量组成的复制位点,定位 Slave 需要复制的 binlog 内容。因此,MySQL 必须在写 binlog 时记录每个事务的全局 GTID,保证 Master / Slave 可以根据这些 GTID 忽略或者执行相应的事务。GTID 的组成部分:前面是 server_uuid:后面是一个串行号 例如:server_uuid:sequence number 7800a22c-95ae-11e4-983d-080027de205a:10 UUID:每个 mysql 实例的唯一 ID,由于会传递到 slave,所以也可以理解为源 ID。Sequence number:在每台 MySQL 服务器上都是从 1 开始自增长的串行,一个数值对应一个事务。当事务提交时,不管是 STATEMENT 还是 ROW 格式的 binlog,都会添加一个 XID_EVENT 事件作为事务的结束。该事件记录了该事务的 id。

同步方案 同步复制 所谓的同步复制,意思是 master 的变化,必须等待 slave-1,slave-2,…,slave- n 完成后才能返回。异步复制 master 只需要完成自己的数据库操作即可。至于 slaves 是否收到二进制日志,是否完成操作,不用关心 半同步复制 master 只保证 slaves 中的一个操作成功,就返回,其他 slave 不管。master 既要负责写操作,还的维护 N 个线程,负担会很重。可以这样,slave- 1 是 master 的从,slave- 1 又是 slave-2,slave-3,… 的主,同时 slave- 1 不再负责 select。slave- 1 将 master 的复制线程的负担,转移到自己的身上。这就是所谓的多级复制的概念。这里会有个一致性的问题。开始提交事务 =>write binlog => sync binlog => engine commit => send events => 返回 send_events 失败会导致 master 有 slave 没有 开始提交事务 =>write binlog => sync binlog => send events => engine commit => 返回 send_events 失败若 sync binlog 未同步,导致 XA 不会重做,slave 领先

并行复制

定期 checkout-point 将队列中执行结束的删除。记录 checkpoint 后每个 worker 是否执行过的 bitmap。崩溃恢复时执行 Bitmap 未执行的部分。按 db 分粒度大可以换成 table

扩展性
当主库支撑不了。水平扩展。拆表。
可靠性
需要 proxy 保证
一致性
同步策略影响。XA 分为外部和内部。对于外部。要应用程序或 proxy 作为协调者。(二阶段提交协调者判断所有 prepare 后 commit)。对于内部,binlog 控制。
proxy 功能
共享式的缓存读写分离路由可靠性的保证,主从切换, 故障发现与定位 XA 一致性的实现过滤加注释例如:https://github.com/mariadb-co…

退出移动版