Ala*_*laa 6 mysql innodb replication
我在服务器 S1 上有 mysql DB（mysql 版本 5.1.41-3ubuntu12.7-log）。
我在服务器 S2（mysql 版本 5.1.54-1ubuntu4-log）上为这个数据库创建了主从。
S1 上的 DB 使用一个数据文件 (ibdata)。
将数据库转储到 S2 后，我设置了innodb_file_per_table=1. 这使得每个表都有自己的 ibd 文件。现在一切顺利。
在 S2 上重新启动 mysql 后，我遇到了出现此错误的问题：
Error 'Unknown table engine 'InnoDB'' on query. Default database: MyDB
当我尝试显示引擎时，我得到以下信息：
显示引擎； +------------+---------+------------------------- ------------------------------+------------ ---+------+------------+ | 发动机 | 支持 | 评论 | 交易 | XA | 保存点 | +------------+---------+------------------------- ------------------------------+------------ ---+------+------------+ | 我的ISAM | 默认 | MySQL 3.23 的默认引擎，具有出色的性能| 否 | 否 | 否 | | MRG_MYISAM | 是 | 相同 MyISAM 表的集合 | 否 | 否 | 否 | | 黑洞 | 是 | /dev/null 存储引擎（您写入的任何内容都会消失）| 否 | 否 | 否 | | CSV | 是 | CSV 存储引擎 | 否 | 否 | 否 | | 内存 | 是 | 基于哈希，存储在内存中，对临时表有用| 否 | 否 | 否 | | 联合 | 否 | 联合 MySQL 存储引擎 | 空 | 空 | 空 | | 存档 | 是 | 归档存储引擎 | 否 | 否 | 否 | +------------+---------+------------------------- ------------------------------+------------ ---+------+------------+
InnoDB 未列出。
在错误日志中，我可以看到：
InnoDB：数据库物理写入文件已满：等待... InnoDB：无法初始化创建的日志文件，因为 InnoDB：数据文件已损坏，或新数据文件已损坏 InnoDB：在之前启动数据库时创建 InnoDB：时间但数据库没有关闭 InnoDB：通常在那之后。 111016 8:24:11 [错误] 插件“InnoDB”初始化函数返回错误。 111016 8:24:11 [错误] 插件“InnoDB”注册为存储引擎失败。 111016 8:24:11 [警告] 既没有使用 --relay-log 也没有使用 --relay-log-index；因此，当此 MySQL 服务器充当从服务器并更改其主机名时，复制可能会中断！！请使用'--relay-log=S2-relay-bin'来避免这个问题。
我试图删除 ib_logfiles 但这并没有奏效。如果我删除 ib_logfiles 和 ibdata 文件，innodb 将正常返回，但我无法访问我的 innodb 表，即。删除ibdata1并重新启动mysql后
描述文章； 错误 1146 (42S02)：表 'MyDb.article' 不存在
我在my.cnf中的innodb配置如下：
innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M
innodb_lock_wait_timeout = 18000
虽然桌子在那里！！
以前有人遇到过这样的问题吗？？
任何想法都受到高度赞赏
谢谢
您不应该删除 ibdata1 文件。原因如下：
ibdata1 包含四种类型的信息：
创建的每个 InnoDB 表都有一个数字 id，通过一些自动增量元数据功能分配给每个 ibd 文件。该内部表空间 ID (ITSID) 嵌入在 .ibd 文件中。根据维护的 ITSID 列表检查该数字，猜猜在哪里，... ibdata1。
可以重建 ibdata1 以获得正确的 ITSID，但需要做一些工作。虽然我个人没有单独完成程序，但我在我雇主的虚拟主机上协助客户完成此操作。我们一起解决了这个问题，但由于客户端处理了 ibdata1，我让他完成大部分工作（30 个 InnoDB 表）。
无论如何，这是我在 DBA StackExchange 中发表的一篇过去的文章。我回答了另一个问题，其根本原因是 ITSID 的混淆。
为了切入正题，这篇文章解释了如何参考 ITSID 以及如何处理 ibdata1 以确认 .ibd 文件中包含的 ITSID 的存在。
很抱歉，除了使用 ITSID 玩游戏之外，没有快速而简单的方法来恢复 .ibd 文件。
这是您问题中的原始 innodb 配置：
innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M
innodb_lock_wait_timeout = 18000
请注意 innodb_log_file_size 出现了两次。仔细看...
innodb_file_per_table=1
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G <----
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
innodb_buffer_pool_size = 384M
innodb_log_file_size=5M <----
innodb_lock_wait_timeout = 18000
innodb_log_file_size 的最后一个设置优先。MySQL 预计启动时日志文件为 5M。当您尝试启动 mysqld 时，您的 ib_logfile0 和 ib_logfile1 为 1G。它看到了大小冲突并采取了阻力最小的路径，即禁用 InnoDB。这就是为什么 InnoDB 从show engines;. 谜团已揭开 ！！！
该错误消息具有欺骗性，因为 innodb_log_file_size 小于当时为 1G 的日志文件（ib_logfile0 和 ib_logfile1）。有趣的是：报告损坏是因为文件预计为 5M，而且文件更大。如果情况相反，并且 innodb 日志文件小于 my.cnf 中声明的大小，您应该在错误日志中看到如下内容：
110216 9:48:41 InnoDB: Initializing buffer pool, size = 128.0M
110216 9:48:41 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 33554432 bytes!
110216 9:48:41 [ERROR] Plugin 'InnoDB' init function returned error.
110216 9:48:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
在本例中，日志文件已经存在 5M，并且 innodb_log_file_size 的设置更大（在本例中为 32M）。
对于这个特定的问题，我将不一致的错误消息协议归咎于 MySQL（呃 Oracle [仍然讨厌这么说]）。