mysql 开发进阶篇类别 11 锁难题 (复苏和复制的急需,对锁机制的熏陶)

1. 回复和复制的急需,对innodb锁机制的震慑

  mysql
通过binlog文件对增加和删除除改等革新数据的sql语句,完毕数据库的东山再起和主从复制。mysql的恢复生机机制(复制其实正是在slave
mysql不断做基于binglog的还原)特点有如下:
  (1) mysql 的过来是sql语句级的,也等于双重执行binlog中的sql语句,
oracle数据库则是依据数据库文件块的。
  (2) mysql
的binlog是遵照作业提交的先后顺序记录的,复苏也是按这几个顺序实行的。那也与oracle分歧,oracle是根据系统更新号(SCN)来回复数据的。

2.  insert into 和create table对于原表也会加共享锁
 
 下边演示原表加锁的事例:

会话1

会话2

SET autocommit=0;

SELECT * FROM city WHERE CityCode=’003′

city_id      country_id        cityname CityCode

103  2       杭州         003

SET autocommit=0;

SELECT * FROM city WHERE CityCode=’003′

city_id      country_id        cityname CityCode

103  2       杭州         003

INSERT INTO  cityNew

SELECT  * FROM city WHERE CityCode=’003′

共 1 行受到影响

 

 

UPDATE city SET CityCode=’004′ WHERE CityCode=’003′

等待超时

Lock wait timeout exceeded; try restarting transaction

Commit;

 

 

Commit;

  上边的例证中,只是简单的读取city表,相当于三个常见的select
语句,在此处innodb给city表加了共享锁,并有利用多版本数据一致性技术。原因依然为了保险苏醒和复制的科学,因为不加锁,上述话语的执行进度中,别的作业对city表做了革新操作,恐怕造成数据苏醒结果错误。如供给演示那种能够将系统变量
innodb_locks_unsafe_for_binlog的值设置为”NO”不加共享锁(set
innodb_locks_unsafe_for_binlog=’on’) 暗中同意是”OFF”
。假若设置方面包车型大巴值为ON,
大概会使Binlog中记录的sql执行顺序分裂,使用复苏的结果与事实上的应用逻辑不符,假设进展复制,就会导致基本数据库不等同。
  假若不想设置为ON,又不指望对源表的产出更新发生潜移默化,能够利用 into
outfile 将city表导入到二个txt文件,再接纳load data infile
导入到新表。使用那种直接方法不会对源city表加锁。

 

相关文章