- 综合排序
- 最热优先
- 最新优先
- 来自专栏爱可生开源社区
技术分享 | ibdata1 “减肥” 记
需要评估下 ibdata1 文件大小如何回收及 UNDO 相关参数配置。 ，然后将数据导入的方式来释放 ibdata1 文件。 夏天来了，没想到连 ibdata1 文件也要开始“减肥”了~~~ ”减肥“前 减肥之前的 ibdata1 重量是 512M。 ps：因为是测试‘减肥计划’，所以只模拟了一个‘微胖’的 ibdata1 文件。 我们使用 mysqldump 做全备，因为 Xtrabackup 会备份 ibdata1 文件。
87210编辑于 2023-08-18 - 来自专栏从ORACLE起航，领略精彩的IT技术。
MySQL ibdata1文件迁移
目的：主机系统/var目录快满了，经查询最大的文件是mysql的ibdata1文件，有17G大小，故需要迁移这个文件到其他目录下，以释放/var目录空间。 sql 2.关闭mysql服务 # /etc/init.d/mysqld stop 停止 mysqld： [确定] # /etc/init.d/mysqld status mysqld 已停 3.移动ibdata1 mysql移动到/usr2/mysql # pwd /var/lib/mysql # ls -lh 总用量 17G -rw-rw---- 1 mysql mysql 17G 10月 13 10:23 ibdata1
2.2K21发布于 2019-05-24 - 来自专栏大大刺猬
5.7能否从ibdata1中提取出表DDL
导读mysql 8.0的系统表是在mysql.ibd文件中,记录内容非常全(基本上和ibd中的sdi差不多),可以拼接成实际的DDL.mysql 5.7的系统表是在ibdata1中的, 是否也能拼接为真实的 ibdata1中系统表解析先来看看ibdata1中的各系统表的表结构,这部分信息只有自己拼接(8.0是有专门的sdi page来记录的). row in set (0.00 sec)[root@ddcw21 ibd2sql-ibd2sql-v2.x]#python3 main.py /data/mysql_5744/mysqldata/ibdata1 但是不知道虚拟字段的关系啊, 光有这玩意有屁用....能否从ibdata1中提取出表DDL? ibdata1中的系统表记录的都是存取数据所必须的数据,至于取出来之后能否"读得懂"就不关心了, 所以我们无法直接从ibdata1中的系统表提取DDL, 当然,如果字段"简单"的话,还是可以的.能,但不完全能
17520编辑于 2025-12-31 - 来自专栏雪碧君终将成长
MySQL InnoDB数据恢复，丢失ibdata1时怎么安全恢复
如何在删除ibdata1的情况下恢复 数据库宕机恢复数据或迁移数据，几个重要节点。 1 检查数据库目录配置是否正确 数据库目录配置错误时，MySQL是不能正常启动的，报错可能与此无关。 譬如说，我在修改数据库目录的时候，点击了宝塔面板的迁移按钮，导致ibdata1文件被覆盖，以及随之而来的崩溃恢复之旅。 如果提前做好了备份，可能几秒钟就可以顺利恢复了。 3 检查ibdata1的最后更新日期，以及是否可用 MySQL在运行以及关闭时会更新ibdata1文件，我们通过ibdata1的最后更新时间可以判断这个文件大概是什么时候的。 4 丢失ibdata1或 ibdata1文件损坏，与数据库数据文件不匹配时的数据恢复。 由于innoDB将表数据字典存储在ibdata1中，当ibdata1改变时，ID就无法对应上，所以就会找不到表 解决方案概括来说就是 CREATE TABLE table_name ...; # 这里的表格式
5K30编辑于 2023-02-15 - 来自专栏开源部署
MySQL的ibdata1文件越来越大解决方法
本人遇到一次在安装zabbix监控的时候，yum安装的MySQL数据库，后面用了一段时间发现data目录下的ibdata1的空间特别大，反而我的zabbix数据库的空间很小，这样的情况在后面备份zabbix ibdata1文件是什么？ ibdata1是一个用来构建innodb系统表空间的文件，这个文件包含了innodb表的元数据、撤销记录、修改buffer和双写buffer。 是什么原因导致ibdata1文件会越来越大？ ibdata1存放数据，索引和缓存等，是MYSQL的最主要的数据。所以随着数据库越来越大，表也会越大，这个无法避免的。 首先我们把数据库文件备份下来，然后直接删除ibdata文件（为了保险起见最好先全备一次，做到数据安全和完整），然后再重新导入数据库文件即可！ -------------+-------+ 1 row in set (0.00 sec) innodb_file_per_table的状态变为ON 5、删除ibdata1
1.8K20编辑于 2022-08-16 - 来自专栏散尽浮华
mysql启动后随即关闭问题解决（ibdata1文件损坏导致）
分析日志后发现，数据库无法重启的原因是因为ibdata1文件损坏，重启后无法正常恢复。 再次启动mysql就ok了~ 如果还无法启动，则需要删除数据目录datafile下的 ibdata1,ib_logfile*等文件。 启动后导出MySQL数据库，重新恢复即可。
1.7K100发布于 2018-01-22 - 来自专栏DBA随笔
一个MySQL实例启动问题
--T19::36.077860+: [ERROR] Aborting 从errlog的信息可以推断，是ibdata1的文件大小和配置文件.cnf的大小不一致导致的，这里需要留意这两个数字，一个是 我们看看我们在配置文件my.cnf中设定的文件大小： innodb_data_file_path = ibdata1:1024M;ibdata2:1G:autoextend 这里写的是ibdata1:1024MB 那么报错信息中心提示当前的ibdata1文件和my.cnf中配置的大小不一样，我们看看当前的ibdata大小： 1000M ibdata1 1.1G ibdata2 也就是说，实际的ibdata 大小为1000M，而我们的配置文件的大小是1024M，这就产生了问题，那么解决方案就比较容易了，就是把my.cnf中的配置改为: ibdata1:1024M;ibdata2:1G:autoextend即可 由于ibdata2是autoextend的，所以，大小超过1G也是可以理解的。 这样，重新启动mysql，问题得到解决。
76910发布于 2020-03-12 - 来自专栏开源部署
如何给MySQL共享表空间扩容
四.如何给共享表空间扩容 场景一：在同一磁盘中给共享表空间的ibdata1扩容操作： 检查my.cnf文件配置的ibdata1大小初始值为1000M，自动增长，如下： innodb_data_home_dir =/apps/dbdat/mariadb10_data3306 innodb_data_file_path=ibdata1:1000M:autoextend 检查数据文件目录中ibdata1实际文件大小为 1786773504，如下： -rw-r--r-- 1 apps apps 1786773504 Jul 27 21:29 ibdata1 这里扩容有两个注意的地方： 1.若ibdata1的实际大小没有超过 ,如下 innodb_data_file_path=ibdata1:1704M;ibdata2:1000M:autoextend ------这里注意格式，分号和冒号 重启MySQL后，检查新增的ibdata2 my.cnf配置,在不同磁盘中增加一个ibdata3,如下 innodb_data_file_path=ibdata1:1704M;ibdata2:1000M;/apps2/dbdat/ibdata3:
3.2K20编辑于 2022-08-16 - 来自专栏数据库干货铺
MySQL OCP试题解析（8）
A)ibdata1:12M;ibdata2:12M:autoextend B)ibdata1:12M:autoextend C)ibdata1:12M;/tmp/ibdata2:12M:autoextendD )ibdata1:12M;ibdata2:12M;ibdata3:12M E)ibdata1:12M:autoextend;ibdata2:12M:autoextend F)ibdata1:12M 题目要求 选项解析 A) ibdata1:12M;ibdata2:12M:autoextend 正确。 D) ibdata1:12M;ibdata2:12M;ibdata3:12M 错误：所有文件均为固定大小（12MB），无自动扩展，无法应对数据增长。 E) ibdata1:12M:autoextend;ibdata2:12M:autoextend 错误。自动扩展属性只能应用于最后一个文件，此配置违反规则。 F) ibdata1:12M 错误。
38210编辑于 2025-05-23 - 来自专栏全栈程序员必看
1146 mysql_MySQL–ERROR 1146 (42S02)：table doesn’t exist
1146 (42S02): Table ‘xxx’ doesn’t exist 可能是很多人都遇到的问题，尤其在数据库迁移或备份的时候 mysql数据目录结构 mysql数据目录下有如下几个重要文件：ibdata1 ib_logfile1 数据库xx 以及该目录下的一系列 .frm 文件 其中 ib_logfile0 和 ib_logfile1 是关于数据库的一些日志文件 数据库xx 是默认数据库和我们添加的数据库目录 ibdata1 那是因为ibdata1 文件受影响了，表数据存储在ibdata1中 mysql是通过缓存的方式写入数据到ibdata1，当我们异常拷贝ibdata1的时候，可能缓存数据还没写入，导致有点出入，因此操作顺序很重要 解决方案 介于ibdata1数据被影响了，我们需要矫正下数据写入顺序，如下： 1、在新mysql数据目录下新建我们需要拷贝的数据库 mysql/videos, 同时把旧mysql中对应数据库下的文件全部拷贝过来 文件拷贝到新mysql数据目录下 mysql/ibdata1，这个时候我们会发现目录下有 ib_logfile0 ib_logfile1 和 ibdata1 4、再次启动新的mysql服务，然后验证，mysql
1.8K10编辑于 2022-08-15 - 来自专栏AustinDatabases
MYSQL 表空间设置上的一些细节
早些年的MYSQL 版本大多没有那么多想法，能装上，一堆的数据库文件，都在一个ibdata1 文件的例子并不少见，可能现在想想好可怕，要是万一坏了，不想在想下去了。 buffer 4 undo logs 等组成，所以对 ibdata 文件的要求很大，并且希望是多个文件来支持MYSQL 的运行。 现在的ibdata 文件，已经将 undo logs doublewrite 等文件移出了 ibdata 文件（在MYSQL 5.7 官方没有找到，在percona 版本中有innodb_parallel_doublewrite_path 的默认值，会在数据目录中产生一个xb_doublewrite的文件 所以ibdata 文件的功能已经减少了。 另在innodb_file_per_table 是必须要打开的，不能再将所有数据都在灌入到ibdata文件中。
1.5K20发布于 2019-06-21 - 来自专栏DBA随笔
InnoDB的表空间介绍
系统表空间（ibdata1、ibdata2文件） 系统表空间是指data目录下面的ibdata1文件和ibdata2文件，文件个数可以指定，这里的表空间文件默认大小是12M，当然，我们也可以手动设置， # InnoDB Directory Variables innodb_data_home_dir = /data/mysql_4306/data innodb_data_file_path = ibdata1 :1000M;ibdata2:100M:autoextend innodb_file_per_table = 1 在配置文件my.cnf里面写上以上参数，注意看，这里我写的是ibdata1是1000M ，而ibdata2是100M，这样的设置是完全可行的，可以看到，在ibdata一行最后是autoextend，他的意思是这个文件是可以自动扩展的，所以一般都会比较大，往往是1G更多。 edit innodb_data_file_path in my.cnf back 190813 18:44:12 InnoDB: to what it was, and remove the new ibdata
1.5K20发布于 2019-11-06 - 来自专栏开源部署
MySQL修改 innodb_data_file_path 参数注意事项
:12M:autoextend [mysqld] innodb_data_file_path = ibdata1:12M:autoextend 当需要改为1G时，不能直接在配置文件把ibdata1改为1G 大致意思就是ibdata1的大小不是 65536page*16KB/1024KB=1G,而是 786page*16KB/1024KB=12M（未使用压缩页） 方法一：推荐 而应该再添加一个ibdata2 :1G，如下： [mysqld] innodb_data_file_path = ibdata1:12M;ibdata2:1G:autoextend 重启数据库！ 方法二：不推荐 直接改为如下的话 [mysqld] innodb_data_file_path = ibdata1:1G:autoextend 可以删除$mysql_datadir目录下ibdata1、 ib_logfile0、ib_logfile1文件： rm -f ibdata* ib_logfile* 也可以启动MySQL，但是mysql错误日志里会报如下错误： 2019-03-29T07:10:
1.7K20编辑于 2022-08-17 - 来自专栏MySQL解决方案工程师
InnoDB数据恢复的工具——TwinDB介绍
apt install make gcc flex bison 使用make生成执行文件： # make 使用方法 1.恢复表结构 当MySQL无法启动时，TwinDB工具集可以从系统表空间文件ibdata1 使用工具集中的stream_parser对系统表空间文件ibdata1进行解析： # . /stream_parser -f /var/lib/mysql/ibdata1 Opening file: /var/lib/mysql/ibdata1 File information: 解析完成后将解析的数据放在当前目录下的pages-ibdata1目录下： # ls pages-ibdata1/* pages-ibdata1/FIL_PAGE_INDEX: 0000000000000001 /c_parser -4f pages-ibdata1/FIL_PAGE_INDEX/0000000000000002.page -t \ dictionary/SYS_COLUMNS.sql >
3K30发布于 2021-08-20 - 来自专栏盛开在夏天的太阳
linux服务器MySQL数据从磁盘拷贝以及恢复
将/var/lib/mysql下的ibdata1文件删除 3. 将/mnt/var/lib/mysql下的ibdata1拷贝到/var/lib/mysql下. 注: 我们数据库实际的数据都是放在ibdata1下的, 所以这个文件很重要 4. 一定要注意修改文件的权限 chown mysql:mysql ibdata1 ------------------------------------------------------------ 但是,我觉得直接将/mnt/var/lib/mysql文件夹下的rap_db文件夹和ibdata1文件一起拷贝到/var/lib/mysql下应该也能成功. 最后别忘了修改文件夹和文件的权限.
2.1K20发布于 2020-09-27 - 来自专栏linda
【Mysql】innodb_space 的使用介绍
innodb_file_format=Barracuda, innodb_file_format_max=Barracuda 3.基本用法 Against a single space file (ibdata 这基本上是一个表的列表: innodb_space -s ibdata1 system-spaces [root@vm-test01 ztj]# innodb_space -s .. /ibdata1 -T ztj/aa space-page-type-summary [root@vm-test01 ztj]# innodb_space -s .. /ibdata1 -T ztj/aaa -I PRIMARY index-recurse [root@vm-test01 ztj]# innodb_space -s .. /ibdata1 -T ztj/aaa -I PRIMARY index-recurse [root@vm-test01 ztj]# innodb_space -s ..
2.7K30发布于 2019-06-02 - 来自专栏数据库干货铺
InnoDB 表空间可视化工具innodb_ruby初探
"ibdata1", a comma-delimited list of files e.g. "ibdata1,ibdata1", or a directory name. If a directory name is provided, it will be scanned for all files named "ibdata?" 2.2.7 查看指定页面的信息 参考中2.2.2中page号（root值），查看对应页面的信息，可以查询具体的结果说明 # innodb_space -s ibdata1 -T testdb/test1 # innodb_space -s ibdata1 -T testdb/test1 -p 4 page-account Accounting for page 4: Page type is 在看一下二级索引c1的内容，也便于理解二级索引，会有主键id的信息 # innodb_space -s ibdata1 -T testdb/test1 -p 4 page-records Record
1.2K20发布于 2021-05-10 - 来自专栏数据库干货铺
InnoDB 表空间可视化工具innodb_ruby
"ibdata1", a comma-delimited list of files e.g. "ibdata1,ibdata1", or a directory name. If a directory name is provided, it will be scanned for all files named "ibdata?" in set (0.03 sec) mysql> exit Bye -- 在数据目录下操作 # cd /data/mysql/mysql3306/data/ # innodb_space -s ibdata1 # innodb_space -s ibdata1 -T testdb/test1 -p 4 page-account Accounting for page 4: Page type is 在看一下二级索引c1的内容，也便于理解二级索引，会有主键id的信息 # innodb_space -s ibdata1 -T testdb/test1 -p 4 page-records Record
1.6K60发布于 2021-04-25 - 来自专栏杨建荣的学习笔记
MySQL数据库升级的一些坑
使得迁移过程中避免其他业务连接的影响，验证无误后停库 4）修改mysql_base路径为5.7版本，修改/usr/bin/mysql等环境变量配置 5）替换配置文件为5.7版本，在5.7模式下启动数据库，这里没有注意ibdata 的配置，运气不好，碰上了一个奇葩配置，如下： innodb_data_file_path = ibdata1:1000M;ibdata2:100M:autoextend 而原本的规范配置都是一个ibdata 文件，如下： innodb_data_file_path = ibdata1:1G:autoextend， 导致数据库启动时报错，提示ibdata文件已经被损坏了。 9）使用物理备份模式备份当前数据库 10）重新升级数据库，尤其注意ibdata的配置，如果升级失败则使用物理备份快速回退 11）升级过程再次受阻，这一次是sql_mode,系统数据字典升级成功，但是数据库的表检测中
2K30发布于 2020-08-10 - 来自专栏爱可生开源社区
第10期：选择合适的表空间
一、系统表空间 在 MySQL 数据目录下有一个名为 ibdata1 的文件，可以保存一张或者多张表。 innodb_data_file_path=ibdata1:200M;ibdata2:200M:autoextend:max:800M 系统表空间不仅可以是文件系统组成的文件，也可以是非文件系统组成的磁盘块 ls -sihl ibdata1 923275 12M -rw-r----- 1 mysql mysql 12M 3月 18 15:32 ibdata1 # ... ls -sihl ibdata1 923275 76M -rw-r----- 1 mysql mysql 76M 3月 18 15:34 ibdata1 # 删除这张表 mysql> drop table ls -sihl ibdata1 923275 76M -rw-r----- 1 mysql mysql 76M 3月 18 15:39 ibdata1 如何才能释放 ibdata1 呢这个比较麻烦，
87110发布于 2020-08-11
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号