InnoDB 中文参考手册 13 出错处理数据库教程

InnoDB 中文参考手册 13 出错处理数据库教程（共2篇）

篇1：InnoDB 中文参考手册 13 出错处理数据库教程

参考|参考手册|中文

InnoDB 中文参考手册 --- 犬犬(心帆)翻译 1 InnoDB Tables 概述

InnoDB 给 MySQL 提供了具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表，InnoDB 提供了行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)。这些特性均提高了多用户并发操作的性能表现。在InnoDB表中不需要扩大锁定(lock escalation)，因为 InnoDB 的列锁定(row level locks)适宜非常小的空间。InnoDB 是 MySQL 上第一个提供外键约束(FOREIGN KEY constraints)的表引擎。

InnoDB 的设计目标是处理大容量数据库系统，它的 CPU 利用率是其它基于磁盘的关系数据库引擎所不能比的。

在技术上，InnoDB 是一套放在 MySQL 后台的完整数据库系统，InnoDB 在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。 InnoDB 把数据和索引存放在表空间里，可能包含多个文件，这与其它的不一样，举例来说，在 MyISAM 中，表被存放在单独的文件中。InnoDB 表的大小只受限于操作系统的文件大小，一般为 2 GB。

在www.innodb.com/上可以找到 InnoDB 最新的信息。InnoDB 手册的最新版本总是被放置在那里，并且在那里可以得到 InnoDB 的商业许可(order commercial licenses)以及支持。

InnoDB 现在(十月)在一些大的需高性能的数据库站点上被使用。著名的 Internet 新闻站点 Slashdot.org 就是使用的 InnoDB，

Mytrix, Inc. 在 InnoDB 表上存储了超过 1 TB 的数据，而且另外的一个站点在 InnoDB 表上处理着平均每秒 800 次的插入/更新的负载。

在 MySQL 的源代码中，从 3.23.34a 开始包含 InnoDB 表引擎，并在 MySQL -Max 的二进制版本中激活。

为了使用 InnoDB 表引擎，必须在‘my.cnf’或‘my.ini’文件中详细指定 InnoDB 的启动配置。最小的修改方法就是在 [mysqld] 区中加入下面一行：

innodb_data_file_path=ibdata:30M

但是为了得到最好的性能推荐详细指定配置选项，查看 2 InnoDB Startup Options。

InnoDB 以 GNU GPL 版本 2 的许可发布(1991年六月)。

1.1 MySQL/InnoDB 发布版本间的差别

MySQL-Max-3.23: 这是一个稳定版本，被推荐为产品使用。 MySQL-4.0: 这是一个开发版本，与 MySQL 3.23 相比它包含了一些新特性，比如多表删除(multi-table delete)、查询结果缓冲(cached query results)和 SSL 通信。4.0 版与 3.23 版中的 InnoDB 表引擎是一致的。4.0.1 的稳定性可被归类为 beta。 MySQL-4.0 embedded server library: You can link this into your application. The benefits are easier deployment for your application, better performance, and easier use. The stability of the embedded library is classified as alpha, but it should be gamma within a few months.

篇2：InnoDB 中文参考手册 13 出错处理数据库教程

InnoDB 中文参考手册 --- 犬犬(心帆)翻译 6 备份和恢复 InnoDB 数据库

安全的数据库管理就是使用正规的数据备份，

InnoDB Hot Backup 是一个在线备份工具，你可以在 InnoDB 数据库运行时使用它来实现在线备份。InnoDB Hot Backup 不需要你关闭你的服务器也不需要加任何锁或影响其它普通的数据操作。InnoDB Hot Backup 是一个非免费的附加工具，它的费用为每 MySQL 服务器每年 400 欧元。浏览网页 InnoDB Hot Backup homepage 可获得更多的信息以及程序屏幕截图。

如果你可以关闭你的 MySQL 服务，那么可以通过下面几个步骤进行数据库的“二进制”备份：

关闭 MySQL 数据库服务，并确定在关闭时没有发生任何错误 将你的所有数据文件复制到一个安全的地方 将所有的 InnoDB 日志文件复制到一个安全的地方 将 my.cnf 配置文件复制到一个安全的地方 将所有的 InnoDB 表 .frm 文件复制到一个安全的地方

在需要高性能的数据库服务站点上，可以通过 MySQL 的复制特性来保持数据库的一个副本，MySQL 的复制特性同样适用于 InnoDB 表类型。

除了上面描述的二进制备份方式之外，最好定期地使用 mysqldump 转储数据表。原因是二进制文件可能会在你未注意时而被破坏，而表转储(dump)文件是以文本文件方式保存的，它与二进制文件相比更简单、有更好的的可读性。因为转储文件更简单所以更容易发现表损坏， 重要数据损环的可能性很小。

一个好的主意就是在对数据库做二进制备份的同时也做一个转储(dump)备份。为了得到一致的数据快照，必须关闭所有客户端的连接。然后就可以进行二进制备份，这样你就有了数据一致的两种格式的备份。

如了实现通过上面所述的二进制备份方法将 InnoDB 数据库恢复到当前状态，必须打开 MySQL 的二进制日志(binlogging)开关。这样你就可以二进制日志 与备份数据配合实现分时间点的恢复：

mysqlbinlog yourhostname-bin.123 | mysql

为了恢复一个崩溃了的 MySQL 服务进程，你所能做的唯一一件事就是重新启动。InnoDB 将自动地检查日志并完成数据库的前滚(roll-forward)到当前状态。同时，InnoDB 将自动回滚崩溃前未提交的事务。在恢复过程中，mysqld 将显示如下所示的提示：

heikki@donna:~/mysql-3.23.48/sql>mysqld 04 23:08:31 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 177573790 InnoDB: Doing recovery: scanned up to log sequence number 0 177638912 InnoDB: Doing recovery: scanned up to log sequence number 0 177704448 InnoDB: Doing recovery: scanned up to log sequence number 0 177769984 InnoDB: Doing recovery: scanned up to log sequence number 0 177835520 InnoDB: Doing recovery: scanned up to log sequence number 0 177901056 InnoDB: Doing recovery: scanned up to log sequence number 0 177966592 InnoDB: Doing recovery: scanned up to log sequence number 0 178032128 InnoDB: Doing recovery: scanned up to log sequence number 0 178097664 InnoDB: Doing recovery: scanned up to log sequence number 0 178163200 InnoDB: Doing recovery: scanned up to log sequence number 0 178228736 InnoDB: After this prints a line for every 10th scan sweep: InnoDB: Doing recovery: scanned up to log sequence number 0 178884096 ... InnoDB: Doing recovery: scanned up to log sequence number 0 19330 InnoDB: Doing recovery: scanned up to log sequence number 0 193957376 InnoDB: Doing recovery: scanned up to log sequence number 0 194612736 020204 23:08:40 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Doing recovery: scanned up to log sequence number 0 195268096 InnoDB: Doing recovery: scanned up to log sequence number 0 195923456 ... InnoDB: Doing recovery: scanned up to log sequence number 0 203132416 InnoDB: Doing recovery: scanned up to log sequence number 0 203787776 InnoDB: Doing recovery: scanned up to log sequence number 0 204443136 InnoDB: 5 uncommitted transaction(s) which must be rolled back InnoDB: Trx id counter is 0 129792 InnoDB: Starting rollback of uncommitted transactions InnoDB: Rolling back trx with id 0 129400 InnoDB: Rolling back of trx id 0 129400 completed InnoDB: Rolling back trx with id 0 129217 InnoDB: Rolling back of trx id 0 129217 completed InnoDB: Rolling back trx with id 0 129098 InnoDB: Rolling back of trx id 0 129098 completed InnoDB: Rolling back trx with id 0 128743 InnoDB: Rolling back of trx id 0 128743 completed InnoDB: Rolling back trx with id 0 127939 InnoDB: Rolling back of trx id 0 127939 completed InnoDB: Rollback of uncommitted transactions completed 020204 23:08:51 InnoDB: Starting an apply batch of log records to the database. .. InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 7 3 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file offset 0 40418561, file name ./donna-bin.001 020204 23:08:53 InnoDB: Flushing modified pages from the buffer pool... 020204 23:09:03 InnoDB: Started mysqld: ready for connections

如果数据库遭到损坏或磁盘失败，则不得不从一个备份文件恢复，

在损坏的情况下，首先可以恢复一个未损坏的备份文件。然后依照 MySQL 手册提示从一般的日志文件中恢复数据。

在某些数据库损坏的情况下，可能通过转储(dump)、撤销(drop)和重新建立一个或多个损坏的表就足够了。可怜通过 CHECK TABLE SQL 命令检查一个受损的表，虽然 CHECK TABLE 并不能发现所有的损坏类型。你可能使用 innodb_tablespace_monitor 来检查数据文件时的文件空间管理的完整性。

在某些情况下，数据库页面显示损坏，而实际上是由于操作系统的文件高速缓冲损坏，而磁盘上的数据文件还是好的。 这时最好先重起你的系统。这可能解决数据库页面错误。

6.1 强制(Forcing)恢复

如果出现数据库页面损坏，可以通过 SELECT INTO OUTFILE 从数据库中转储出表数据，通常大部分的数据并未受损坏。 但是这些损坏可能引起 SELECT * FROM table 或 InnoDB 后台操作崩溃或中断(assert)，甚至是 InnoDB 的前滚(roll-forward)恢复崩溃。从 InnoDB version 3.23.44 开始，在 my.cnf 中有个设置选项可以强制 InnoDB 启动，以及防止后台操作的运行，因而你可以转储数据。例如，你可以 my.cnf 在中加入如下设置：

set-variable = innodb_force_recovery = 4

innodb_force_recovery 代替选择将在下面列出。 这个参数不能用于数据库的其它方面!当设置值大于 0 时，作为安全尺度，InnoDB 禁止用户使用 INSERT, UPDATE, 或 DELETE 。

从 3.23.53 和 4.0.4 开始，即使强制恢复被使用你也可以使用 DROP 或 CREATE 一个表。 如果你确定表如引起回滚崩溃，你可以移除(drop)它。你也可以通过这个停止一个因导入大量数据或 ALTER TABLE 而引起的失控(runaway)回滚。你可以杀死 mysqld 进程，并使用 my.cnf 设置项 innodb_force_recovery=3 不使用回滚。然后就可以 DROP 那个引起失控(runaway)回滚的表。

下面较大的数意味着包含所有较低数所对就的安全防范。为了能够转储表设置至少为 4 ，这是相对安全的，仅仅只有一些损坏的页面数据掉失。Option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures. 1 (SRV_FORCE_IGNORE_CORRUPT) 即使发现一个错误也启动服务;试着使用 SELECT * FROM table 跳过损坏的索引记录和页面，这将帮助转储表。 2 (SRV_FORCE_NO_BACKGROUND) prevent the main thread from running: 如果在清理过程中将发生崩溃，这将预防它。 3 (SRV_FORCE_NO_TRX_UNDO) 恢复时不运行事务回滚。 4 (SRV_FORCE_NO_IBUF_MERGE) 防止插入缓冲区的归并操作：如果他们将引起崩溃，最好不要操作他们;不要考虑表统计(table statistics)。 5 (SRV_FORCE_NO_UNDO_LOG_SCAN) 当启动数据库时不撤销日志(undo logs)：InnoDB 将未完成的事务已提交。 6 (SRV_FORCE_NO_LOG_REDO) do not do the log roll-forward in connection with recovery.

6.2 检查点(Checkpoints)

InnoDB 通过调用一个模糊的检查点来实现检查点机制。InnoDB 以很小的批量从缓冲池中刷新修改了的数据库页面。这就不需要在一个批量中刷新整个缓冲池，因这个实话上将可能停止用户 SQL 语句运行进程一段时间。

In crash recovery InnoDB 在崩溃修复时会检查记录在日志文件中的检查点标签。它知道，在标签前所有对数据库的修改已被记录到数据库的磁盘镜像中。然后 InnoDB 扫描日志文件中检查点后面的日志并将修改记入数据库。

InnoDB 以一个环形方式记录日志文件。所有使缓冲池中的数据库页面与磁盘镜像不相同已提交了的修改必须记录在日志文件中，以防 InnoDB 需要恢复。 这就意味着 InnoDB 以环形方式重新启用一个日志文件，它必须确定将被重新使用的日志文件中的操作日志结果已被磁盘镜像文件包含。用另一句话来说就是，InnoDB 必须时常地建立检查点并将修改了的数据库页面更新到磁盘中。