情况描述:服务器硬盘损坏,服务器换了个新硬盘 ,然后老硬盘插在上面.挂载在这台机器.可以从老硬盘里面拿到数据.只拿到了里面的mysql数据文件夹,把数据文件夹覆盖新的服务器mysql数据文件夹 启动报错!!!报错!!!错!!!. 数据文件如下: 于是觉得不能使用覆盖文件的方式还原数据,得使用科学方法恢复.google之…… 找到解决办法如下: 可以发现数据目录下有对应数据库名称的文件夹,文件夹下有很多 表名.ibd 文件,这些文件其实就是数据,我们要利用它们来恢复 恢复步骤: 1.在新库里面创建

背景:aliyun上的rds数据库快满了,于是删除了某个备份的表后面大boss说是有用的表,需要恢复回来,阿里云有7天内的物理全量备份(通过percona-xtrabackup备份的)第一时间应该延长备份时间(默认保留7天,可以配置15天或更长避免在恢复过程中被阿里云的rds删除) 准备:数据库大概有700G左右,物理备份文件100G左右,恢复回来需要占用大概1多T的空间,于是在现有同样区域的ecs上挂载一块2T的磁盘用来做恢复 整体的过程是:在相同地域的ecs安装好mysql,恢复到上面,然后

转载自:http://ourmysql.com/archives/1293 数据库数据被误删除是经常看到的事情,数据的恢复也就自然成为了DBA很重要的一门基本功夫,比较笨拙的办法是拉出历史的备份到另外的一台机器恢复出来,但是这种方法如果数据量比较大的话,往往会耗费较长的时间,以前在使用oracle的时候,提供了很多数据恢复的办法,常用的办法就是采用闪回flashback,或者通过logmnr在分析日志完成数据的恢复,但是在mysql中,数据的恢复变成了很困难的一件事情. 上周一同事的数据库就由于

mysqlbinlog --database=数据库名 --start-date="2017-06-01 5:00:00"  --stop-date="2017-06-11 10:00:00" var/mysql-bin.000001 | mysql -u root -p123456 -f 1.注意粗体字可执行文件的位置,如果已加入环境变量可以忽略 2.注意红色字bin-log日志的位置要写对 3.数据库名要改 4.可以设置日期 5.最后设置使用的数据库账号.密码

MySQL闪回原理与实战 DBA或开发人员,有时会误删或者误更新数据,如果是线上环境并且影响较大,就需要能快速回滚.传统恢复方法是利用备份重搭实例,再应用去除错误sql后的binlog来恢复数据.此法费时费力,甚至需要停机维护,并不适合快速回滚.也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能. MySQL闪回(flashback)利用binlog直接进行回滚,能快速恢复且不用停机.本文将介绍闪回原理,给出笔者的实战经验,并对现存的闪回工具作比较. 开胃菜 某天,小明因

show variables like 'log_bin%'; 可以看到Mysql binlog为关闭状态,那我们去更改为开启状态

方案一:(传统方案) 备份+binlog日志增量: 方案二:(针对update.delete语句忘加where的情况) Binlog日志文件中保存有错误操作之前和之后的两组数据,将错误操作之前的数据修改成update语句重新执行一次: 详情链接:http://www.cnblogs.com/exclusive-ada/p/4215178.html 方案三:(利用从库的方案)        添加新从库并设置时差,在主从同步数据之前删除binlog日志文件内执行的错误语句: 第三种方案尚未测试,请有

最近用innobackup进行备份测试,我们只备份一个innodb类型的库,数据大小大概50多G,用innobackupex大概用了5个多小时,但是mysqldump只用了大约2个小时,这让我很费解,有哪位知道的同志能够交流下?按理说innobackupex应该快的,还有就是大家在备份时不要放到高峰期,因为innobackupex备份时比较吃系统IO,下面就是我备份脚本,分为全备和增备,使用innobackupex需要安装依赖包: yum install perl-DBD-MySQL* 一.全备

[问题现象] 服务器在运行过程中,因人为意外导致电源被拔,服务器宕机,mysql重启不成功,报错如下 根据提示,输入systemctl status mysql.service和journalctl -xe查看日志,经过一番百度谷歌折腾也是无果.(很多时候,不能因为突发事件就“病急乱投医”) 最后在mysql 的日志处看到了报错日志 如果centos是通过yum安装的mysql,那么日志一般在/var/log/mysql.log 查看到日志 2018-11-29T08:39:18.977374Z

偶有感触:遇到这个问题,经过一个下午的排查, 终于解决. 故事情节:我的阿里云服务器突然被黑客攻击了,整个系统down了. 找客服,他们排查说usr目录的文件全部丢失.让我重新初始化系统盘.初始化之前先生成一个快照.还好生成了快照,让事情没有发展为不可挽救的地步. mysql数据库数据恢复. 其他的问题都一一解决了. 到了最后, mysql上的数据无论如何都不能正常显示出来.数据库不要紧(有备份), 之前的数据才是最要紧的. 这就是本文的目的. 最终如何将mysql数据显示出来. -------

MySQL 监控要点 MySQL 监控要点,主要涉及服务器和 MySQL 两个方向的监控告警. 在这两个监控告警方向需要重点关注监控策略.监控趋势图及报警方式. 监控策略指的是每个监控项的告警阈值,例如 threads_running > 30 触发报警. 监控趋势图指的是对每个时间点,项目所采集数据的图形展现,基于历史数据的比对能够快速发现异常的监控项. 报警方式则按需配置,Email.电话或企业微信等均可. 服务器监控要点 服务器监控要点主要在于监控硬件健康情况,例如通过 logwathch

当把mysql容器销毁,在新建一个容器,进行之前的数据恢复. 因为之前建立了数据卷,那么现在就可以利用这个数据卷进行数据恢复. 使用docker volume create volume_name命令新建一个数据卷 docker volume ls查看数据卷列表 注意:使用数据卷进行挂载的时候,数据卷必须是一个空的目录,也就是说不能有任何数据. docker inspect volume_name查看数据的相关信息,例如挂载位置 在恢复数据之前需要把刚刚建立的数据卷里面关联的内容删除掉,然后把之

Linux下安装mysql  MySQL官网:https://dev.mysql.com/downloads/mysql/ 到mysql官网下载mysql编译好的二进制安装包,在下载页面Select Platform:选项选择linux-generic,然后把页面拉到底部,64位系统下载Linux - Generic (glibc 2.5) (x86, 64-bit),32位系统下载Linux - Generic (glibc 2.5) (x86, 32-bit)    解压32位安装包: 进入

mysql_Innodb的undo_log和redo_log 原创 2014年10月28日 11:26:34   众所周知,mysql支持多种存储引擎,现在常用的是MyISAM和InnoDB.MyISAM相对简单,但不支持事务,而InnoDB是事务安全型的.而InnoDB的事务处理离不开undo_log和redo_Log. mysql innodb存储引擎 下面简单的介绍一下innodb的存储引擎 内存缓冲池 如果mysql不用内存缓冲池,每次读写数据时,都需要访问磁盘,必定会大大增加I/O请求

1.概述 是一个高性能.高可用.高扩展的存储引擎. 2.InnoDB体系架构 InnoDB存储引擎主要由内存池和后台线程构成. 其中,内存池由许多个内存块组成,作用如下: 维护所有进程和线程需要访问的内部数据结构. 缓存磁盘上的数据,提高处理器读取速度,当数据被修改的时候也是先修改这里的数据,再被后台线程写到内存上去. 重做日志(redo log)缓冲. 后台线程的主要作用: 负责刷新内存池中的数据,以保证缓冲池中数据是最近的数据. 将缓冲中的数据刷新到磁盘上. 保证数据库发生异常的时候 ,数据

转: (三)MySQL锁机制 + 事务 表锁(偏读) 偏向MyISAM存储引擎.开销小,加锁快,无死锁,锁定粒度大,发生锁冲突的概率最高,并发最低. 查看当前数据库中表的上锁情况,0表示未上锁. show open tables; 添加读/写锁 lock table 表名 read(write) , 表名2... 释放表锁 unlock table; 加读锁(共享) 当前会话和其他会话均可读取加了读锁的表 当前会话不能读取其他表(先把自己的事干好) 其他会话要修改加了读锁的表,必须等待锁释放(阻

一.数据库数据备份 1.全备 BakDir=/backup/full #创建全备目录 LogFile=/backup/full/bak.log #创建备份日志 Date=`date +%Y%m%d` Begin=`date +"%Y年%m月%d日 %H:%M:%S"` cd $BakDir DumpFile=$Date.sql GZDumpFile=$Date.sql.tgz mysqldump -uroot -phongjun123 --all-databases --lock-al

配置免密登录服务器及下载备份文件#!/bin/bash BACKUP=192.168.30.233 #一行写一个IP BACKUP_PASSWD="lxzl_root*#2021" #root密码 MYSQLBACKUP=192.168.30.232 #一行写一个IP MYSQLBACKUP_PASSWD="lxzl_root*#2021" #root密码 #检查是否安装expect function init { rpm -qa | grep expect if

数据库通常借助日志来实现事务,常见的有undo log.redo log,undo/redo log都能保证事务特性,undolog实现事务原子性,redolog实现事务的持久性. 为了最大程度避免数据写入时io瓶颈带来的性能问题,MySQL采用了这样一种缓存机制:当query修改数据库内数据时,InnoDB先将该数据从磁盘读取到内存中,修改内存中的数据拷贝,并将该修改行为持久化到磁盘上的事务日志(先写redo log buffer,再定期批量写入),而不是每次都直接将修改过的数据记录到硬盘内,

binlog浅析 一.基础知识 什么是binlog? (图一) 全称:Binary Log (二进制日志),包含描述数据库更改的" 事件 ",例如表创建操作或对表数据的更改.二进制日志不用于诸如select或 show不修改数据的语句 .要记录所有语句(例如,标识问题查询),请使用常规查询日志. 在哪里产生的? 我们都知道MYSQL有两层结构,第一层:server层,里面包含连接器.查询缓存.解析器.优化器.执行器,第二次是存储引擎层,例如:InnoDB.MyISAM.Memory 等

MySQL frm+ibd文件还原data的办法[数据恢复] 此方法只适合innodb_file_per_table          = 1 当误删除ibdata 该怎么办? 如下步骤即可恢复: 1.准备工作 1)准备一台纯洁的mysql环境[从启动到现在没有使用过INNODB的表结构的mysql环境](当然也可以不用纯洁的,但是一定要保证表id 小于后续要恢复的表id); 2)备份frm.ibd文件; 2.通过frm恢复表结构 1)在测试库里新建任意一表,表结构随意,表名必须为:要恢复数据的