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
Run Code Online (Sandbox Code Playgroud)
虽然桌子在那里!!
以前有人遇到过这样的问题吗??
任何想法都受到高度赞赏
谢谢
您不应该删除 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
Run Code Online (Sandbox Code Playgroud)
请注意 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
Run Code Online (Sandbox Code Playgroud)
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.
Run Code Online (Sandbox Code Playgroud)
在本例中,日志文件已经存在 5M,并且 innodb_log_file_size 的设置更大(在本例中为 32M)。
对于这个特定的问题,我将不一致的错误消息协议归咎于 MySQL(呃 Oracle [仍然讨厌这么说])。