数据库锁设计的初衷是处理并发问题。作为多用户共享的资源,当出现并发访问的时候,数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。根据加锁的范围,MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。
全局锁
全局锁就是对整个数据库实例加锁。可以通过命令 Flush tables with read lock (FTWRL) 对全局进行加锁,让整个库处于只读状态。
使用全局锁后,其他线程的以下语句会被阻塞:
- 数据更新语句(增删改)
- 数据定义语句(包括建表,修改表结构等)
- 更新类事务的提交语句。
全局锁的典型使用场景是,做全库逻辑备份。但如果直接用 FTWRL 去进行备份,会让整库都处于只读状态,这光想想就觉得危险。
- 如果在主库上备份,那么在备份期间都不能执行更新,业务基本停摆;
- 如果在从库上备份,那么备份期间从库不能执行从主库同步过来的binlog,会导致主从延迟。
那么不加锁备份数据库可以吗?答案是不可以的,比如你有两张表,余额表和商品表。如果不加锁,在备份期间时先备份余额表,再备份商品表会出现什么情况呢?假设在这两张表备份的间隔时间内进行了数据更新,则余额表数据在备份表中没有减少,但是商品表在备份表中的数据却减少了,造成了逻辑上的数据不一致问题。当然这两张表的备份顺序颠倒过来也是一样会有这个问题。
也就是说,不加锁的话,备份系统备份的得到的库表锁一个逻辑时间点,这个视图是逻辑不一致的。
其实,在可重复读隔离级别下开启一个事务,也能够拿到一致性视图。
官方自带的逻辑备份工具是 mysqldump 。当 mysqldump 使用参数 -single-transaction 时,备份数据之前会启动一个事务,来确保拿到一致性视图。而由于MVCC(多版本并发控制)的支持,这个过程中数据是可以正常更新的。
至此,为什么有了上述这个功能,还需要 FTWRL 呢?此处有个细节是:可重复读是很好,但并不是所有的MySQL引擎支持这个隔离级别的。(如 MyISAM 这种不支持事务的引擎,就需要执行 FTWRL 命令了。)所以,single-transaction方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎,那么备份就只能通过FTWRL的方法。
既然要保证备份时全库只读,为什么不使用 set global readonly = true 的方式呢?
不建议使用这种方式有以下两方面原因:
- 在有些系统中,readonly 的值会被用来处理其他逻辑,修改 global 变量的方式影响面更大。
- 在异常处理机制上的差异。执行 FTWRL 命令后如果客户端发生异常断开连接,那么 MySQL 会自动释放这个全局锁。而readonly=true 会保持数据库长时间处于只读状态。如果客户端发生异常,数据库一直保持 readonly 状态,这样会导致整个