孙某某的运维之路

孙富阳， 江湖人称没人称。多年互联网运维工作经验，曾负责过孙布斯大规模集群架构自动化运维管理工作。擅长Web集群架构与自动化运维，曾负责国内某大型博客网站运维工作。

1.事务介绍

事务：Transaction（交易）。伴随着交易类的业务出现的概念（工作模式）
交易？
		物换物，等价交换
		货币换物，等价交换
		虚拟货币换物（虚拟物品），等价交换
现实生活中怎么保证交易和谐，有法律道德等规则约束
数据库中为了保证线上交易的和谐，加入了事务工作机制

2.事务ACID特性简介

A：atomicity原子性
一个事务是一个完整整体，不可再分
一个事务中所有的DML语句要么全执行成功，要么全失败
C:consistency一致性
事务工作前中后，数据最终一致
只要事务提交成功，数据保证最终一致
I:isolation隔离性
事务和事务工作过程中是互不影响的
D:durability持久性
已经提交的事务，保证落盘

3.事务的生命周期

1.标准事务控制语句

begin 开启事务
commit 提交事务，事务结束##提交后不能使用roolback进行回归
roolback 回滚事务，事务结束

2.自动提交机制

autocommit#默认情况下，执行一个语句提交一次
查询是否开启自动提交mysql> select @@autocommit；

3.隐式提交

执行了begin之后，再次执行begin会自动提交
还有以下也会触发自动提交
DDL语句：（ALTER、CREATE、DROP）
DCL语句：（GRANTE、REVOKE和SET PASSWORD）
锁定语句：（LOCK TABLES和UNLOCK TABLES）
导致隐式提交的语句示例：
Truncate table
Load data infile
Select for update

4.隐式回滚

会话窗口被关闭
数据库关闭
出现事务冲突（死锁）

4.事务的隔离级别

1.作用

实现事务工作期间的“读"的隔离
读?----》数据页的读

2.级别类型

mysql> select @atransaction_isolation;
#RU : READ-UNCOMMITTED 读未提交
可以读取到事务未提交的数据。并发高，但隔离性差，会出现脏读（当前内存读），不可重复读，幻读问题
#RC : READ-COMMITTED读已提交(可以用):
可以读取到事务已提交的数据。并发较高，隔离性一般，不会出现脏读问题，但是会出现不可重复读，幻读问题
#RR :REPEATABLE-READ可重复读（默认）:
防止脏读（当前内存读），并发一般，防止不可重复读，会出现幻读问题
#SR : SERIALIZABLE可串行化
隔离性最好，但没有并发
结论:隔离性越高，事务的并发度就越差。

3.设置事务的级别类型

查询
mysql> select @@transaction_isolation;
修改
mysql> set global   transaction_isolation='READ-COMMITTED';
当然也可以写到配置文件里

5.事务的脏读、不可重复读、幻读解释

1.脏读

首先将事务的隔离级别调整为ru状态
mysql> set global   transaction_isolation='READ-UNCOMMITTED';
mysql> set global autocommit=0;
打开两个mysql窗口
更新表中的数据，未提交事务。但是另一个窗口也看到了未提交的事务，这就是脏读

2.不可重复读

首先将事务的隔离级别调整为rc状态
mysql> set global   transaction_isolation='READ-COMMITTED';
mysql> set global autocommit=0;
打开两个mysql窗口
A窗口执行update操作未提交前B窗口查询不到更新的数据，避免了脏读

3.幻读

幻读和不可重复读有一念之差
幻读是A窗口执行更新操作后，当前事务还未结束，但是B窗口新插入了一条数据，A窗口在查询的时候查到了B插入的数据，A就认为上面执行的更新出现了问题，这就是出现了幻读

6.事务的工作流程原理（ACID特性如何保证）

1.名词介绍

重做日志（redo log）
磁盘：ib_loggile0-N,参数innodb_log_file_size和innodb_log_files_in_group
内存：innodb_log_buffer参数innodb_log_buffer_size
表数据
磁盘：独立表空间xxx.ibd segment extents pages
内存：innodb_buffer_pool  innodb_buffer_pool_size
日志序列号
一个顺序递增的数字，记录数据页变化的版本，redo日志的变化量（字节）
那些对象有日志序列号
Redo buffer：Log sequence number          111786856
Redo log：Log flushed up to            111786856
数据页：Last checkpoint at           111786856
查询方式
mysql> show engine innodb status \G
WAL（write ahead log）日志先行
commit提交事务时，保证日志先写磁盘，数据后写
脏页（dirty page）
在内存中修改的数据页，没写到磁盘的叫脏页
检查点（checkpoint）
将脏页刷新到磁盘的动作
DB_TRX_ID
事务编号 存储在数据页头部
DB_ROLL_PTR
回滚指针 存储在数据页头部

2.事务的工作流程原理

事务举例:
begin;
update t1 set A=2 where A=1;
commit;

1 redo log重做日志如何应用:

1.用户发起update事务语句，将磁盘数据页(page100,A=1,LSN=1000）加载到内存(buffer pool)缓冲区。
2，在内存中发生数据页修改(A-1改成A=2)，形成脏页，更改中数据页的变化，记录到redo buffer中，加入100个字节日志。LSI1-100+1=-200。
3.当commit语句执行时，基于WAL机制，等到redo buffer中的日志完全落盘到ib_logfilell中，commit正式完成。
4. ib_logfileN中记录了一条日志。内容: page100数据页变化+LSN=2000。

##情景:当此时，redo落地了，数据页没有落地，宕机了。
1.MySQL CR（自动故障恢复）工作模式，启动数据库时，自动检查redo的LSN和数据页LSN。
2．如果发现redoLSN>数据页的LSN ，加载原始数据页+变化redo指定内存。使用redo重构脏页（前滚）。
3．如果确认此次事务已经提交(commit标签），立即触发CKPT动作，将脏页刷写到磁盘上。

##补充一点:
MySQL有一种机制，批量刷写redo的机制。会在A事务commit时，顺便将redo buffer中的未提交的redo日志也一并剧到磁盘
为了区分不同状态的redo，日志记录时，会标记是否COMMIT。
##redo保证了ACID哪些特性?
主要是D的特性,另外A、C也有间接关联。

2 undo log回滚日志如何应用:

1．事务发生数据页修改之前，会申请一个undo事务操作，保存事务回滚日志（逆向操作的逻辑日志)。
2. undo写完之后，事务修改数据页头部（会记录DB_TRX_ID+DB_ROLLl_PTR)，这个信息也会被记录的redo。
情景1:
当执行rollback命令时。根据数据页的DB_TRX_ID+DB_ROLL_PTR信息，找到undo日志，进行回滚。

情景2:
begin;
update t1 set A=2 where A=1;
宕机。

假设:undo有, redo没有
启动数据库时，检查redo和数据页的LSN号码。发现是一致的。
所以不需要进行redo的前滚，此时也不需要回滚。undo信息直接被标记为可覆盖状态。

假设: undo有，redo也有(没有commit标签。）
1.MySQL CR(自动故障恢复〉工作模式，启动数据库时，自动检查redo的LSN和数据页LSN。
2．如果发现redoLSN>数据页的LSN，加载原始数据页+变化redo指定内存。使用redo重构脏页（前滚）。
3.如果确认此次事务没有commit标记，立即触发回滚操作，根据DB_TRX_TO+OB_ROLL_PTR信息，找到und回滚日志，实现回滚。
以上流程被称之为InnoOB的核心特性:自动故障恢复(Crash Recovery)。先前滚再回滚，先应用redo再应用undo。

##undo在ACID中保证了啥?
主要保证事务的A的特性,同时C和I的特性也有关系。

3.事务中的C特性怎么保证?

InnoDB crash recovery:数据库意外宕机时刻，通过redo前滚+undo回滚保证数据的最终一致。
InnoDB doublewrite buffer:默认存储在ibdataN中。解决数据页写入不完整
mysqld process crash in the middle of a page write，Ind0B can find a good copy of the page from the doblewrite buffer during crash recvery.
DWB一共2M。分两次，每次1M写入

4.事务中的I特性怎么保证?

隔离级别:读隔离性
RU :脏读、不町重复读、幻读
RC :个可重复读、幻读
RR :有可能会出现幻读。
SR(SE) :事务串行工作。
#锁机制:写的隔离I
作用:保护并发访问资源。
保护的资源分类:
latch(门锁) : rwlock、mutex，主要保护内存资源
MDL: Metadata_lock,元数据(DDL操作)
table_lock:表级别
		lock table t1 read ;
		mysqldump、XBK (PBK):备份非InnoDB数据时，触发FTWRL全局锁表(Global)。
		行锁升级为表锁。
row lock: InnoDB默认锁粒度，加锁方式都是在索引加锁的。
record lock :记录锁，在聚簇索引锁定。RC级别只有record lock。
gap lock:间隙锁，在辅助索引间隙加锁。RR级别存在。防止幻读。
next lock:下一键锁，GAP+Record。RR级别存在。防止幻读。