作者简介：姚远，MySQL ACE，华为云 MVP ，专注于 Oracle、MySQL 数据库多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。现在鼎甲科技任技术顾问，为同事和客户提供数据库培训和技术支持服务。
同事反馈说某个测试的MySQL数据库误删除了ibdata1文件，导致库启动不了，而且没做备份，能不能恢复？
Mysql最常用的三种备份工具分别是mysqldump、Xtrabackup（innobackupex工具）、lvm-snapshot快照。 前面分别介绍了： Mysql备份系列（1）--备份方案总结性梳理 Mysql备份系列（2）--mysqldump备份（全量+增量）方案操作记录 Mysql备份系列（3）--innobackupex备份mysql大数据(全量+增量）操作记录 lvm-snapshot：基于LVM快照的备份 1.关于快照： 1）事务日志跟数据文件必须在同一个卷上； 2）刚刚创立的快照卷，里
续 lvm-snapshot：基于LVM快照的备份之准备工作 http://www.linuxidc.com/Linux/2014-05/101308.htm
读取顺序：/etc/mysql/my.cnf>/etc/my.cnf>~/.my.cnf
物理备份 ： 文件备份，直接在linux系统上拷贝 逻辑备份 ： 库备份，表备份–>>数据库sql脚本 （1） 完整性备份 所有的全部备份 生成所有的sql脚本 （2） 增量备份 完整性为前提 后面完整加上 增加的内容 与上一次进行比较 如果其中间的一个凉了 数据就会丢掉那一层的增量 数据就会丢失 （3） 差异备份 完整性为前提 相比较完整性备份 多出来的3 4
主要也是参考下面链接最终成功恢复。 这篇文章的步骤稍微有点多。有些是恢复不必要的，这里做一下自己的整理。
共享表空间: 某一个数据库的所有的表数据，索引文件全部放在一个文件中，默认这个共享表空间的文件路径在data目录下。 默认的文件名为:ibdata1 初始化为10M。
本人遇到一次在安装zabbix监控的时候，yum安装的MySQL数据库，后面用了一段时间发现data目录下的ibdata1的空间特别大，反而我的zabbix数据库的空间很小，这样的情况在后面备份zabbix数据库的时候会很不方便，所以想着要怎么解决下。 ibdata1文件是什么？
故事情节：我的阿里云服务器突然被黑客攻击了，整个系统down了。 找客服，他们排查说usr目录的文件全部丢失。让我重新初始化系统盘。初始化之前先生成一个快照。还好生成了快照，让事情没有发展为不可挽救的地步。
今天我们的zabbix-server机器根空间不够了，我一步步排查结果发现是/var/lib/mysql/下的libdata1文件过大，已经达到了41G。我立即想到了zabbix的数据库原因，随后百度、谷歌才知道zabbix的数据库他的表模式是共享表空间模式，随着数据增长，ibdata1 越来越大，性能方面会有影响，而且innodb把数据和索引都放在ibdata1下。
在测试环境下没有设置过多的详细参数就初始化并启动了服务，后期优化的过程中发现innodb_data_file_path设置过小：
MySQL 表空间可分为共享表空间和单表空间；其中共享表空间又可分为系统表空间和通用表空间。
爱可生华东交付部 DBA，主要负责 MySQL 日常问题处理及 DMP 产品支持。爱好跳舞，追剧。
Xtrabackup介绍 Xtrabackup是由percona开源的免费数据库热备份软件，它能对InnoDB数据库和XtraDB存储引擎的数据库非阻塞地备份（对于MyISAM的备份同样需要加表锁）；mysqldump备份方式是采用的逻辑备份，其最大的缺陷是备份和恢复速度较慢，如果数据库大于50G，mysqldump备份就不太适合。 Xtrabackup安装完成后有4个可执行文件，其中2个比较重要的备份工具是innobackupex、xtrabackup 1）xtrabackup 是专门用来备份InnoDB
ib_logfile0和ib_logfile1被覆盖但是mysql还在正常运行，复现问题记录排查流程，涉及文件系统的一些知识点。
ERROR 1146 (42S02): Table ‘xxx’ doesn’t exist 可能是很多人都遇到的问题，尤其在数据库迁移或备份的时候
在日常运维工作中，对于数据库的备份是至关重要的！数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失！然而是人总难免会犯错误，说不定哪天大脑短路了，误操作把数据库给删除了，怎么办？
在日常运维工作中，对于mysql数据库的备份是至关重要的！数据库对于网站的重要性使得我们对mysql数据的管理不容有失！ 然后，是人总难免会犯错误，说不定哪天大脑短路了来个误操作把数据库给删除了，怎么办？？？ 下面，就mysql数据库误删除后的恢复方案进行说明。 一、工作场景 （1）MySQL数据库每晚12:00自动完全备份。 （2）某天早上上班，9点的时候，一同事犯晕drop了一个数据库！ （3）需要紧急恢复！可利用备份的数据文件以及增量的binlog文件进行数据恢复。 二、数据恢复思路 （1）利用全备的
今天启动mysql又一次报错：The server quit without updating PID file！记得上次出现这个问题的时候，尝试了一些常规的方法，未果，所以索性重新进行安装。但是，相同的问题今天又出现了！！！OH， my god！恰巧今天时间充裕，尝试各种办法，终于皇天不负有心人，经过一个小时的奋战后，终于让我给搞定，整个过程是这样的！
删库跑路也是个老梗了，可见在运维数据库的过程中误删除数据，或者开发的代码有bug，造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案，例如SQL管理系统，将要执行的SQL先交由管理员审核，然后由管理员备份一个镜像数据库，在镜像上执行该SQL，并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
chown -R mysql.mysql /application/mysql-5.6.38/
最近一个安装宝塔环境的项目，mysql老是关闭停止了。连续好多次了，然后我就发现不对劲。然后去查了下日志，日志内容：
背景： 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
之前用kill的方法杀掉了一个MySQL的进程，今天想要重启这个进程，启动的过程中，发现
看到标题，有的童鞋心中暗想“数据删除有什么可提的呢？不就是执行个delete语句吗？有什么难的呀？”其实呢数据删除没有你想的这么简单，一般情况下公司会明确的要求数据只能逻辑删除，不能物理删除。那什么优势逻辑删除，什么又是物理删除呢？
简介： 1.后缀名为.frm的文件：这个文件主要是用来描述数据表结构和字段长度灯信息 2.后缀名为.ibd的文件：这个文件主要储存的是采用独立表储存模式时储存数据库的数据信息和索引信息； 3.后缀名为.MYD（MYData）的文件：从名字可以看出，这个是存储数据库数据信息的文件，主要是存储采用独立表储存模式时存储的数据信息； 4.后缀名为.MYI的文件：这个文件主要储存的是数据库的索引信息； 5.ibdata1文件:主要作用也是储存数据信息和索引信息
MySQL存储引擎介绍 文件系统 操作系统组织和存取数据的一种机制。 文件系统是一种软件。 文件系统类型 ext2 ext3 ext4 xfs 数据 不管使用什么文件系统，数据内容不会变化 不同的是，存储空间、大小、速度 MySQL引擎 可以将MySQL引擎理解为：MySQL的“文件系统”，只不过功能更加强大。 MySQL引擎的功能 除了可以提供基本的存取功能，还有更多功能事务功能、锁定、备份和恢复、优化以及特殊功能。 MySQL 提供以下存储引擎： – InnoDB – MyISAM – MEMOR
innodb_ruby是jeremycole的一个用于分析Innodb相关结构的一个程序，也是非常方便我们研究Innodb的结构的工具。 1. 工具安装
最近因为电脑重装了系统，导致自己原本的数据库呗覆盖，需要重新重新安装数据库，但是由于我之前数据库版本是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 5.6中开始支持把undo log分离到独立的表空间，并放到单独的文件目录下；这给我们部署不同IO类型的文件位置带来便利，对于并发写入型负载，我们可以把undo文件部署到单独的高速存储设备上。增加了如下几个参数来控制该行为。
操作系统版本：CentOS Linux release 7.6.1810 (Core)，默认的yum源安装后ruby的版本是2.0 ,而innodb_ruby需要2.2及以上版本，因此修改yum源，再安装指定高版本
innodb_space 的git网址：https://github.com/jeremycole...
在 IT 圈内，“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话，但却反映了数据库内数据对企业的重要性。2020年的“微盟事件”就直接让香港主板上市公司微盟集团的市值一天之内蒸发超10亿元，数百万用户受到直接影响。
数据库实例运行正常的情况，在各个log buffer中，会存有 各个LSN，可以通过 show engine innodb status 查看，但是注意，这个lsn并非是直接从磁盘文件获取，而是从buffer 中获取。说明如下：
Flashback恢复数据的原理是通过修改binlog内容，拿回原库进行回放，前提是binlog_format=row和binlog_row_image=FULL。
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
今天突然想起一个问题，那就是对于ibdata的恢复，如果我们简单模拟一下，就会发现还是蛮有意思的。 首先我们得到两个参数值，一个是刷脏页的指标，另外一个是数据文件的目录。 mysql> show variables like '%pct%'; +------------------------------------------+-----------+ | Variable_name | Value | +-------------------
我们知道，磁盘和内存之间的数据交换是通过数据页来实现的，而最小的数据页的大小是16KB，表空间是用来存储数据页的一个池子，下面我们来说说表空间的概念。
说起来日常的故障，其实，首先应该相到的就是：“备份”、“备份”、“备份”。毕竟再怎么牢固的系统或硬件都会有故障的时候，所以，备份放第一位。
xampp环境，错误日志文件见上面，反复重启和修改配置文件页不行，备份mysql文件夹下的ibdata1文件，删除mysql下的全部文件，只保留文件夹。然后启动mysql，一切正常。然后将备份的ibdata1文件替换新生成的。ok
与InnoDb存储引擎密切相关的文件包括重做日志文件和表空间文件，首先来说说我对表空间文件的理解。表空间文件是用来存储表信息和表数据的，它默认的大小是10MB,名称为ibdata1，如下面代码的第10行所示（代码可以左滑）：
备份是数据安全的最后一道防线，对于任何数据丢失的场景，备份虽然不一定能恢复百分之百的数据(取决于备份周期)，但至少能将损失降到最低。衡量备份恢复有两个重要的指标：恢复点目标(RPO)和恢复时间目标(RTO)，前者重点关注能恢复到什么程度，而后者则重点关注恢复需要多长时间。
问题：将A服务器下的Mysql data备份数据复制到B服务器下的Mysql data，打开表示报错：1146错误
MySQL 的主从复制( Replication )关系，不太严谨的叫法是 “同步” 或者 “主从同步”。实际上在早期，MySQL 的主从并不能实现真正的 “同步”( Sync )，而是 “异步” 的( Async )。
redo是引擎层的日志，而且是InnoDB特有的。InnoDB的redo log是有固定大小的，比如可以配置为 一组4个文件（logfile-1，logfile-2，logfile-3，logfile-4），每个文件的大小是1GB，那么它总共可以记录4GB的操作。一个环状循环结构，从头开始写，写到末尾又回到开始循环写。
本次恢复的数据库安装在客户本地服务器上，服务器操作系统为windows2008 r2 。在当前环境内安装有mysql5.6单实例，引擎类型为innodb，表内数据存储所使用表空间类型为独立表空间。未进行数据库备份，未开启binlog。
再次尝试备份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
导读：深入学习MySQL的时候总是习惯性的和Oracle数据库进行比较。在学习MySQL InnoDB的存储结构的时候也免不了跟Oracle进行比较。Oracle的数据存储有表空间、段、区、块、数据文件；MySQL InnoDB的存储管理也类似，但是MySQL增加了一个共享表空间和独立表空间的概念。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
