14.15 InnoDB Backup and Recovery Innodb备份和恢复
14.15.1 The InnoDB Recovery Process
安全数据库管理的关键是 做定期的备份。 依赖你的数据库的容量, MySQL servers的数量,
和数据库的工作负载, 你可以使用这些技术,单独的或是组合的：
使用MySQL 企业备份进行热备份,关闭MySQL数据库进行冷备份, 物理备份用于快速操作(尤其是恢复);
logical 备份使用mysqldump 用于小的数据量或者恢复schema 对象的结构。
Hot Backups：
mysqlbackup命令,是 MySQL 企业备份组件的一部分,可以让你备份运行中的Mysql 实例,
包括InnoDB和MyISAM 表,以最小的中断操作 来产生一个一致性的数据库的快照。
当mysqlbackup 是复制InnoDB表, reads和写到InnoDB 和MyISAM 表可以继续。
在复制MyISAM 表的时候,读(不是写)到那些表是允许的。
MySQL 企业备份可以创建压缩的备份文件,备份 表和数据库的子集。
在Mysql 2进制log的组合,用户执行基于时间点的恢复。
Cold Backups
如果你关闭Mysql server， 你可以做一个binary backup 有InnoDB 管理的表的所有的文件,使用下面的过程:
1.Do a slow shutdown of the MySQL server and make sure that it stops without errors.
2.Copy all InnoDB data files (ibdata files and .ibd files) into a safe place.
3.Copy all the .frm files for InnoDB tables to a safe place.
4.Copy all InnoDB log files (ib_logfile files) to a safe place.
5.Copy your my.cnf configuration file or files to a safe place.
替代备份类型:
除了做binary 备份 有前面的描述, 定期用mysqldump 备份表。
一个binary 文件可能被损坏在你没注意的情况下。 转储出的表是存储在text files ,对人是可读的,
因此发现表腐败变的简单。而且,因为格式简单,严重的数据腐败的几率变小。
mysql 也有–single-transaction选项 在不需要锁定其他客户端的情况下进行一个一致性的备份。
复制使用InnoDB 表,因此你可以使用Mysql 复制能力来保证数据库的一份复制 在需要高可用的网站
Performing Recovery
恢复你的InnoDB 数据库到现在从2进制备份创建的时间开始,你必须运行MySQL server 启用binary logging ,
甚至在开始备份前。 为了完成基于时间点的恢复在恢复了一个备份后,你可以应用改变从binary log
从MySQL server 的crash中恢复,唯一的需求时重启它。InnoDB 自动检查logs和执行一个数据库的前滚操作。
InnoDB 自动回滚未提交的事务: 在恢复期间, mysqld 显示输出这样的东西:
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files…
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
…
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database…
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
如果你的数据库变被损坏或者磁盘故障发生,你必须执行恢复使用一个备份
在腐败的情况下, 首先找到一个备份是不腐败的有用的。在恢复基础的备份后,做一个基于时间点的恢复从binary log files
使用mysqlbinlog和mysql来恢复在备份之后的变化。
在数据库腐败的某些情况下, 转储数据库是足够的,drop,重建一个或者一部分腐败的表。
你可以使用CHECK TABLE SQL 语句来检查是否一个表是冲突的
14.15.1 The InnoDB Recovery Process InnoDB 恢复进程:
InnoDB crash recovery 包括几个步骤:
- 应用重做日志:Redo log 应用是第一步骤, 在初始化期间被执行, 在接受任何连接前。
如果所有的改变从buffer pool 被flushed 到tablespace(ibdata* and *.ibd files) 在关闭的时间点或者crash,
redo log 应用可以被跳过。 如果redo log 文件在启动的时候丢失,InnoDB 跳过redo log 应用:
删除redo log 可以加速 恢复进程是不允许的,即使如果一些数据丢失可以接受。
删除redo logs 只是考虑为一个选项在一个干净的关闭被执行,设置innodb_fast_shutdown set to 0 or 1.
回滚不完整的事务,任何事务在crash或者fast shutdown 期间是活动的。
花费在回滚一个未完成的事务可能是3倍或者4倍的时间
你不能退出事务 ,正在被回滚的事务。在极端情况下,回滚一个事务预计会很长的时间,
使用innodb_force_recovery为3 会变的更快。
Change buffer merge: 从change buffer 应用改变( system 表空间的一部分)到 secondary indexes的leaf pages，
因为index pages 是读到buffer pool:
Purge: 删除 标记为删除的记录,对于任何活动的事务永远不可见
遵循redo log 应用不依赖redo log( 除了记录写之外)
在redo log应用后, InnoDB 尝试尽早接受连接,降低停机时间。
作为crash recovery 的一部分,InnoDB 回滚任何事务没有提交的或者在XA 准备阶段的当server crahsed时。
rollback 是通过一个后台thread 执行, 执行在并行模式 事务从新的连接。
知道回滚操作被完成,一个新的连接可能遇到锁冲突和恢复事务发生锁冲突
在大多数情况下,即使MySQL server 被异常的kill 在大事务中间,
recovery 过程会自动发生 ,DBA不需要做任何动作。