ERROR 1146 (42S02): Table ‘xxx’ doesn’t exist 可能是很多人都遇到的问题，尤其在数据库迁移或备份的时候
共享表空间: 某一个数据库的所有的表数据，索引文件全部放在一个文件中，默认这个共享表空间的文件路径在data目录下。 默认的文件名为:ibdata1 初始化为10M。
故事情节：我的阿里云服务器突然被黑客攻击了，整个系统down了。 找客服，他们排查说usr目录的文件全部丢失。让我重新初始化系统盘。初始化之前先生成一个快照。还好生成了快照，让事情没有发展为不可挽救的地步。
主要也是参考下面链接最终成功恢复。 这篇文章的步骤稍微有点多。有些是恢复不必要的，这里做一下自己的整理。
本人遇到一次在安装zabbix监控的时候，yum安装的MySQL数据库，后面用了一段时间发现data目录下的ibdata1的空间特别大，反而我的zabbix数据库的空间很小，这样的情况在后面备份zabbix数据库的时候会很不方便，所以想着要怎么解决下。 ibdata1文件是什么？
爱可生华东交付部 DBA，主要负责 MySQL 日常问题处理及 DMP 产品支持。爱好跳舞，追剧。
在测试环境下没有设置过多的详细参数就初始化并启动了服务，后期优化的过程中发现innodb_data_file_path设置过小：
之前用kill的方法杀掉了一个MySQL的进程，今天想要重启这个进程，启动的过程中，发现
简介： 1.后缀名为.frm的文件：这个文件主要是用来描述数据表结构和字段长度灯信息 2.后缀名为.ibd的文件：这个文件主要储存的是采用独立表储存模式时储存数据库的数据信息和索引信息； 3.后缀名为.MYD（MYData）的文件：从名字可以看出，这个是存储数据库数据信息的文件，主要是存储采用独立表储存模式时存储的数据信息； 4.后缀名为.MYI的文件：这个文件主要储存的是数据库的索引信息； 5.ibdata1文件:主要作用也是储存数据信息和索引信息
今天我们的zabbix-server机器根空间不够了，我一步步排查结果发现是/var/lib/mysql/下的libdata1文件过大，已经达到了41G。我立即想到了zabbix的数据库原因，随后百度、谷歌才知道zabbix的数据库他的表模式是共享表空间模式，随着数据增长，ibdata1 越来越大，性能方面会有影响，而且innodb把数据和索引都放在ibdata1下。
最近因为电脑重装了系统，导致自己原本的数据库呗覆盖，需要重新重新安装数据库，但是由于我之前数据库版本是mysql 5.0.22，版本太低，所以小编决定安装mysql 5.7.23版本的，一开始没什么问题，根据之前的安装路径安装成功后，接着配置了mysql的环境变量mysql_path，，然后在数据库编辑工具Navicat for MySQL打开后，进行了一个小小的数据库查询：select * from user；回车之后发现报错：[Err] 1146 – Table ‘performance_schema.session_status’ doesn’t exist
MySQL 表空间可分为共享表空间和单表空间；其中共享表空间又可分为系统表空间和通用表空间。
innodb_ruby是jeremycole的一个用于分析Innodb相关结构的一个程序，也是非常方便我们研究Innodb的结构的工具。 1. 工具安装
操作系统版本：CentOS Linux release 7.6.1810 (Core)，默认的yum源安装后ruby的版本是2.0 ,而innodb_ruby需要2.2及以上版本，因此修改yum源，再安装指定高版本
innodb_space 的git网址：https://github.com/jeremycole...
我们知道，磁盘和内存之间的数据交换是通过数据页来实现的，而最小的数据页的大小是16KB，表空间是用来存储数据页的一个池子，下面我们来说说表空间的概念。
Mysql最常用的三种备份工具分别是mysqldump、Xtrabackup（innobackupex工具）、lvm-snapshot快照。 前面分别介绍了： Mysql备份系列（1）--备份方案总结性梳理 Mysql备份系列（2）--mysqldump备份（全量+增量）方案操作记录 Mysql备份系列（3）--innobackupex备份mysql大数据(全量+增量）操作记录 lvm-snapshot：基于LVM快照的备份 1.关于快照： 1）事务日志跟数据文件必须在同一个卷上； 2）刚刚创立的快照卷，里
与InnoDb存储引擎密切相关的文件包括重做日志文件和表空间文件，首先来说说我对表空间文件的理解。表空间文件是用来存储表信息和表数据的，它默认的大小是10MB,名称为ibdata1，如下面代码的第10行所示（代码可以左滑）：
今天启动mysql又一次报错：The server quit without updating PID file！记得上次出现这个问题的时候，尝试了一些常规的方法，未果，所以索性重新进行安装。但是，相同的问题今天又出现了！！！OH， my god！恰巧今天时间充裕，尝试各种办法，终于皇天不负有心人，经过一个小时的奋战后，终于让我给搞定，整个过程是这样的！
MySQL存储引擎介绍 文件系统 操作系统组织和存取数据的一种机制。 文件系统是一种软件。 文件系统类型 ext2 ext3 ext4 xfs 数据 不管使用什么文件系统，数据内容不会变化 不同的是，存储空间、大小、速度 MySQL引擎 可以将MySQL引擎理解为：MySQL的“文件系统”，只不过功能更加强大。 MySQL引擎的功能 除了可以提供基本的存取功能，还有更多功能事务功能、锁定、备份和恢复、优化以及特殊功能。 MySQL 提供以下存储引擎： – InnoDB – MyISAM – MEMOR
作者简介：姚远，MySQL ACE，华为云 MVP ，专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任技术顾问，为同事和客户提供数据库培训和技术支持服务。
ib_logfile0和ib_logfile1被覆盖但是mysql还在正常运行，复现问题记录排查流程，涉及文件系统的一些知识点。
chown -R mysql.mysql /application/mysql-5.6.38/
最近一个安装宝塔环境的项目，mysql老是关闭停止了。连续好多次了，然后我就发现不对劲。然后去查了下日志，日志内容：
问题：将A服务器下的Mysql data备份数据复制到B服务器下的Mysql data，打开表示报错：1146错误
https://github.com/jeremycole/innodb_ruby
再次尝试备份master数据库 [root@master-qa ~]# /usr/bin/innobackupex --defaults-file=/etc/my.cnf --user=root --password=xxxxxxx /data/fullbackup/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2
背景： centos7.0版本，安装的是mysql5.6版本 问题： 在安装好mysql，并设置开机启动，但是在关机重启后，会发现Mysql服务无法启动 [root@hf-01 ~]# ps aux |grep mysql root 2329 0.0 0.0 112676 984 pts/0 R+ 17:05 0:00 grep --color=auto mysq [root@hf-01 ~]# service mysqld start Starting MySQL. E
早些年的MYSQL 版本大多没有那么多想法，能装上，一堆的数据库文件，都在一个ibdata1 文件的例子并不少见，可能现在想想好可怕，要是万一坏了，不想在想下去了。
目的：主机系统/var目录快满了，经查询最大的文件是mysql的ibdata1文件，有17G大小，故需要迁移这个文件到其他目录下，以释放/var目录空间。
对于商业数据库而言，数据库升级是一个优先级很高的事情，有版本升级路线图，有相应的补丁，而且对于方案还有一系列的演练，显然是一场硬仗。而在MySQL方向上，升级这件事情就被淡化了许多，好像只能证明它的存在而已，当然正是由于这种不重视，也让我今天走了不少弯路。
任何一个技术都有其底层的关键基础技术，这些关键技术很有可能也是其他技术的关键技术，学习这些底层技术，就可以一通百通，让你很快的掌握其他技术。如何在磁盘上存储数据，如何使用日志文件保证数据不丢失以及如何落盘，不仅是MySQL等数据库的关键技术，也是MQ消息队列或者其他中间件的关键技术之一。
电脑重装系统后把原来的mysql data复制进去后大部分表是可以访问的，但是有几个表提示表不存在：
修改 innodb_data_file_path 选项值可自定义InnoDB系统表空间设置，不过要注意 autoextend 和 max 属性只能放在最后一个文件，而不能放在前面的文件。
MySQL 5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给我们部署不同IO类型的文件位置带来便利，对于并发写入型负载，我们可以把undo文件部署到单独的高速存储设备上。增加了如下几个参数来控制该行为。
读取顺序：/etc/mysql/my.cnf>/etc/my.cnf>~/.my.cnf
摘自https://www.rathishkumar.in/2016/04/understanding-mysql-architecture.html
今天突然想起一个问题，那就是对于ibdata的恢复，如果我们简单模拟一下，就会发现还是蛮有意思的。 首先我们得到两个参数值，一个是刷脏页的指标，另外一个是数据文件的目录。 mysql> show variables like '%pct%'; +------------------------------------------+-----------+ | Variable_name | Value | +-------------------
MySQL里面的文件蛮有意思，之前大体有两个参数来做基本的控制。一个是innodb_data_file_path就是一个共享表空间，数据都往这一个文件里放，也就是ibdata1,这个文件其实角色是有重复的，undo，数据都会放在一起。ibdata1会持续增长，无法收缩。另外一个参数是innodb_file_per_table，这样一来，就成了独立表空间，通俗一些就是每一个表都有独立的文件.frm和.ibd，而且实际中使用独立表空间还是比较普遍的，对于delete的操作影响MySQL和Oracle就大大不同。
无论何种存储引擎（InnoDB、MyISAM、MEMORY...），只要创建了表结构就会在磁盘上创建一个frm文件，文件名为：表名.frm
xtrabackup : 这个备份工具是挺好的，但是有缺陷，只可以备份innodb；但是我们也需要备份myisam，然后就出来了一个工具：innobackupex，也就是我们今天所用的！ 一、innobackupex 备份: 1.1 查看数据目录： [[email protected]03 ~]# ls /data/mysql/ auto.cnf db1 ibdata1 ib_logfile0 ib_logfile1 mysql mysql2 performance_schema test
现在的MySQL版本已经可以实现自动扩展表空间，其中innodb_file_per_table默认是开启的，表示为每一张新建的表创建表空间，这样可以避免ibdata1过于庞大。
undrop是一款针对mysql innodb的数据恢复工具，通过扫描文件或磁盘设备，然后解析innodb数据页进而恢复丢失的数据，对于drop、truncate以及文件损坏都很有帮助。本文介绍drop操作后表结构的恢复过程。
MySQL中可以使用编程语言（比如Python）来解析binlog中DML的逆操作来达到闪回的效果，如果数据不多，手工解析也可以。这也是现在大家碰到的很多DML Flashback的一个基本原理。而如果是DDL，比如DROP,那就得叹声气了。 GitHub上有一个很不错的项目是undrop,基于InnoDB,也就意味着如果你所在的环境有了drop操作还是存在恢复的可能了，当然这个过程需要谨慎，建议大家在测试环境先练习测试论证后再做决定，当然我们希望这个工具永远不要排上用场。 这个项目貌似现在关注的人还不太多
准备数据 [root@slave-test ~]# /usr/bin/innobackupex --apply-log /data/fullbackup/2015-10-12_15-24-06/ InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy and Percona LLC and/or its affiliates 2009-2013. All Rights Reserved. This soft
xampp环境，错误日志文件见上面，反复重启和修改配置文件页不行，备份mysql文件夹下的ibdata1文件，删除mysql下的全部文件，只保留文件夹。然后启动mysql，一切正常。然后将备份的ibdata1文件替换新生成的。ok
数据库实例运行正常的情况，在各个log buffer中，会存有 各个LSN，可以通过 show engine innodb status 查看，但是注意，这个lsn并非是直接从磁盘文件获取，而是从buffer 中获取。说明如下：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
