MySQL 数据库误删除后的数据恢复操作说明

在日常运维工作中,对mysql数据库的备份是万分重要的,以防在数据库表丢失或损坏情况出现,可以及时恢复数据。

线上数据库备份场景:
每周日执行一次全量备份,然后每天下午1点执行MySQLdump增量备份.

下面对这种备份方案详细说明下:
1.MySQLdump增量备份配置
执行增量备份的前提条件是MySQL打开binlog日志功能,在my.cnf中加入
log-bin=/opt/Data/MySQL-bin
“log-bin=”后的字符串为日志记载目录,一般建议放在不同于MySQL数据目录的磁盘上。

1

2

3

4

5

6

7

8

9

-----------------------------------------------------------------------------------

mysqldump >       导出数据

mysql <           导入数据  (或者使用source命令导入数据,导入前要先切换到对应库下)

注意一个细节:

若是mysqldump导出一个库的数据,导出文件为a.sql,然后mysql导入这个数据到新的空库下。

如果新库名和老库名不一致,那么需要将a.sql文件里的老库名改为新库名,

这样才能顺利使用mysql命令导入数据(如果使用source命令导入就不需要修改a.sql文件了)。

-----------------------------------------------------------------------------------

2.MySQLdump增量备份
假定星期日下午1点执行全量备份,适用于MyISAM存储引擎。
[root@test-huanqiu ~]# MySQLdump --lock-all-tables --flush-logs --master-data=2 -u root -p test > backup_sunday_1_PM.sql

对于InnoDB将--lock-all-tables替换为--single-transaction
--flush-logs为结束当前日志,生成新日志文件;
--master-data=2 选项将会在输出SQL中记录下完全备份后新日志文件的名称,

用于日后恢复时参考,例如输出的备份SQL文件中含有:
CHANGE MASTER TO MASTER_LOG_FILE=’MySQL-bin.000002′, MASTER_LOG_POS=106;

3.MySQLdump增量备份其他说明:
如果MySQLdump加上–delete-master-logs 则清除以前的日志,以释放空间。但是如果服务器配置为镜像的复制主服务器,用MySQLdump –delete-master-logs删掉MySQL二进制日志很危险,因为从服务器可能还没有完全处理该二进制日志的内容。在这种情况下,使用 PURGE MASTER LOGS更为安全。

每日定时使用 MySQLadmin flush-logs来创建新日志,并结束前一日志写入过程。并把前一日志备份,例如上例中开始保存数据目录下的日志文件 MySQL-bin.000002 , ...

1.恢复完全备份
mysql -u root -p < backup_sunday_1_PM.sql

2.恢复增量备份
mysqlbinlog MySQL-bin.000002 … | MySQL -u root -p注意此次恢复过程亦会写入日志文件,如果数据量很大,建议先关闭日志功能

--compatible=name
它告诉 MySQLdump,导出的数据将和哪种数据库或哪个旧版本的 MySQL 服务器相兼容。值可以为 ansi、MySQL323、MySQL40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options 等,要使用几个值,用逗号将它们隔开。当然了,它并不保证能完全兼容,而是尽量兼容。

--complete-insert,-c
导出的数据采用包含字段名的完整 INSERT 方式,也就是把所有的值都写在一行。这么做能提高插入效率,但是可能会受到 max_allowed_packet 参数的影响而导致插入失败。因此,需要谨慎使用该参数,至少我不推荐。

--default-character-set=charset
指定导出数据时采用何种字符集,如果数据表不是采用默认的 latin1 字符集的话,那么导出时必须指定该选项,否则再次导入数据后将产生乱码问题。

--disable-keys
告诉 MySQLdump 在 INSERT 语句的开头和结尾增加 /*!40000 ALTER TABLE table DISABLE KEYS */; 和 /*!40000 ALTER TABLE table ENABLE KEYS */; 语句,这能大大提高插入语句的速度,因为它是在插入完所有数据后才重建索引的。该选项只适合 MyISAM 表。

--extended-insert = true|false
默认情况下,MySQLdump 开启 --complete-insert 模式,因此不想用它的的话,就使用本选项,设定它的值为 false 即可。

--hex-blob
使用十六进制格式导出二进制字符串字段。如果有二进制数据就必须使用本选项。影响到的字段类型有 BINARY、VARBINARY、BLOB。

--lock-all-tables,-x
在开始导出之前,提交请求锁定所有数据库中的所有表,以保证数据的一致性。这是一个全局读锁,并且自动关闭 --single-transaction 和 --lock-tables 选项。

--lock-tables
它和 --lock-all-tables 类似,不过是锁定当前导出的数据表,而不是一下子锁定全部库下的表。本选项只适用于 MyISAM 表,如果是 Innodb 表可以用 --single-transaction 选项。

--no-create-info,-t
只导出数据,而不添加 CREATE TABLE 语句。

--no-data,-d
不导出任何数据,只导出数据库表结构。
mysqldump --no-data --databases mydatabase1 mydatabase2 mydatabase3 > test.dump
将只备份表结构。--databases指示主机上要备份的数据库。

--opt
这只是一个快捷选项,等同于同时添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 选项。本选项能让 MySQLdump 很快的导出数据,并且导出的数据能很快导回。该选项默认开启,但可以用 --skip-opt 禁用。注意,如果运行 MySQLdump 没有指定 --quick 或 --opt 选项,则会将整个结果集放在内存中。如果导出大数据库的话可能会出现问题。

--quick,-q
该选项在导出大表时很有用,它强制 MySQLdump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。

--routines,-R
导出存储过程以及自定义函数。

--single-transaction
该选项在导出数据之前提交一个 BEGIN SQL语句,BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表,例如 InnoDB 和 BDB。本选项和 --lock-tables 选项是互斥的,因为 LOCK TABLES 会使任何挂起的事务隐含提交。要想导出大表的话,应结合使用 --quick 选项。

--triggers
同时导出触发器。该选项默认启用,用 --skip-triggers 禁用它。

跨主机备份
使用下面的命令可以将host1上的sourceDb复制到host2的targetDb,前提是host2主机上已经创建targetDb数据库:
-C 指示主机间的数据传输使用数据压缩
mysqldump --host=host1 --opt sourceDb| mysql --host=host2 -C targetDb

结合Linux的cron命令实现定时备份
比如需要在每天凌晨1:30备份某个主机上的所有数据库并压缩dump文件为gz格式
30 1 * * * mysqldump -u root -pPASSWORD --all-databases | gzip > /mnt/disk2/database_`date '+%m-%d-%Y'`.sql.gz

一个完整的Shell脚本备份MySQL数据库示例。比如备份数据库opspc
[root@test-huanqiu ~]# vim /root/backup.sh
#!bin/bash
echo "Begin backup mysql database"
mysqldump -u root -ppassword opspc > /home/backup/mysqlbackup-`date +%Y-%m-%d`.sql
echo "Your database backup successfully completed"

[root@test-huanqiu ~]# crontab -e
30 1 * * * /bin/bash -x /root/backup.sh > /dev/null 2>&1

mysqldump全量备份+mysqlbinlog二进制日志增量备份
1)从mysqldump备份文件恢复数据会丢失掉从备份点开始的更新数据,所以还需要结合mysqlbinlog二进制日志增量备份。
首先确保已开启binlog日志功能。在my.cnf中包含下面的配置以启用二进制日志:
[mysqld]
log-bin=mysql-bin

2)mysqldump命令必须带上--flush-logs选项以生成新的二进制日志文件:
mysqldump --single-transaction --flush-logs --master-data=2 > backup.sql
其中参数--master-data=[0|1|2]
0: 不记录
1:记录为CHANGE MASTER语句
2:记录为注释的CHANGE MASTER语句

mysqldump全量+增量备份方案的具体操作可参考下面两篇文档:
数据库误删除后的数据恢复操作说明
解说mysql之binlog日志以及利用binlog日志恢复数据

--------------------------------------------------------------------------
下面分享一下自己用过的mysqldump全量和增量备份脚本

应用场景:
1)增量备份在周一到周六凌晨3点,会复制mysql-bin.00000*到指定目录;
2)全量备份则使用mysqldump将所有的数据库导出,每周日凌晨3点执行,并会删除上周留下的mysq-bin.00000*,然后对mysql的备份操作会保留在bak.log文件中。

脚本实现:
1)全量备份脚本(假设mysql登录密码为123456;注意脚本中的命令路径):
[root@test-huanqiu ~]# vim /root/Mysql-FullyBak.sh
#!/bin/bash
# Program
# use mysqldump to Fully backup mysql data per week!
# History
# Path
BakDir=/home/mysql/backup
LogFile=/home/mysql/backup/bak.log
Date=`date +%Y%m%d`
Begin=`date +"%Y年%m月%d日 %H:%M:%S"`
cd $BakDir
DumpFile=$Date.sql
GZDumpFile=$Date.sql.tgz
/usr/local/mysql/bin/mysqldump -uroot -p123456 --quick --events --all-databases --flush-logs --delete-master-logs --single-transaction > $DumpFile
/bin/tar -zvcf $GZDumpFile $DumpFile
/bin/rm $DumpFile
Last=`date +"%Y年%m月%d日 %H:%M:%S"`
echo 开始:$Begin 结束:$Last $GZDumpFile succ >> $LogFile
cd $BakDir/daily
/bin/rm -f *

2)增量备份脚本(脚本中mysql的数据存放路径是/home/mysql/data,具体根据自己的实际情况进行调整)
[root@test-huanqiu ~]# vim /root/Mysql-DailyBak.sh
#!/bin/bash
# Program
# use cp to backup mysql data everyday!
# History
# Path
BakDir=/home/mysql/backup/daily                     //增量备份时复制mysql-bin.00000*的目标目录,提前手动创建这个目录
BinDir=/home/mysql/data                                   //mysql的数据目录
LogFile=/home/mysql/backup/bak.log
BinFile=/home/mysql/data/mysql-bin.index           //mysql的index文件路径,放在数据目录下的
/usr/local/mysql/bin/mysqladmin -uroot -p123456 flush-logs
#这个是用于产生新的mysql-bin.00000*文件
Counter=`wc -l $BinFile |awk '{print $1}'`
NextNum=0
#这个for循环用于比对$Counter,$NextNum这两个值来确定文件是不是存在或最新的
for file in `cat $BinFile`
do
    base=`basename $file`
    #basename用于截取mysql-bin.00000*文件名,去掉./mysql-bin.000005前面的./
    NextNum=`expr $NextNum + 1`
    if [ $NextNum -eq $Counter ]
    then
        echo $base skip! >> $LogFile
    else
        dest=$BakDir/$base
        if(test -e $dest)
        #test -e用于检测目标文件是否存在,存在就写exist!到$LogFile去
        then
            echo $base exist! >> $LogFile
        else
            cp $BinDir/$base $BakDir
            echo $base copying >> $LogFile
         fi
     fi
done
echo `date +"%Y年%m月%d日 %H:%M:%S"` $Next Bakup succ! >> $LogFile

3)设置crontab任务,执行备份脚本。先执行的是增量备份脚本,然后执行的是全量备份脚本:
[root@test-huanqiu ~]# crontab -e
#每个星期日凌晨3:00执行完全备份脚本
0 3 * * 0 /bin/bash -x /root/Mysql-FullyBak.sh >/dev/null 2>&1
#周一到周六凌晨3:00做增量备份
0 3 * * 1-6 /bin/bash -x /root/Mysql-DailyBak.sh >/dev/null 2>&1

4)手动执行上面两个脚本,测试下备份效果
[root@test-huanqiu backup]# pwd
/home/mysql/backup
[root@test-huanqiu backup]# mkdir daily
[root@test-huanqiu backup]# ll
total 4
drwxr-xr-x. 2 root root 4096 Nov 29 11:29 daily
[root@test-huanqiu backup]# ll daily/
total 0

先执行增量备份脚本
[root@test-huanqiu backup]# sh /root/Mysql-DailyBak.sh
[root@test-huanqiu backup]# ll
total 8
-rw-r--r--. 1 root root 121 Nov 29 11:29 bak.log
drwxr-xr-x. 2 root root 4096 Nov 29 11:29 daily
[root@test-huanqiu backup]# ll daily/
total 8
-rw-r-----. 1 root root 152 Nov 29 11:29 mysql-binlog.000030
-rw-r-----. 1 root root 152 Nov 29 11:29 mysql-binlog.000031
[root@test-huanqiu backup]# cat bak.log
mysql-binlog.000030 copying
mysql-binlog.000031 copying
mysql-binlog.000032 skip!
2016年11月29日 11:29:32 Bakup succ!

然后执行全量备份脚本
[root@test-huanqiu backup]# sh /root/Mysql-FullyBak.sh
20161129.sql
[root@test-huanqiu backup]# ll
total 152
-rw-r--r--. 1 root root 145742 Nov 29 11:30 20161129.sql.tgz
-rw-r--r--. 1 root root 211 Nov 29 11:30 bak.log
drwxr-xr-x. 2 root root 4096 Nov 29 11:30 daily
[root@test-huanqiu backup]# ll daily/
total 0
[root@test-huanqiu backup]# cat bak.log
mysql-binlog.000030 copying
mysql-binlog.000031 copying
mysql-binlog.000032 skip!
2016年11月29日 11:29:32 Bakup succ!
开始:2016年11月29日 11:30:38 结束:2016年11月29日 11:30:38 20161129.sql.tgz succ

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/535337.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

MySQL 之binlog日志说明及利用binlog日志恢复数据操作记录

众所周知&#xff0c;binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下&#xff0c;我们往往会想到用binlog日志功能进行数据恢复&#xff08;定时全备份binlog日志恢复增量数据部分&#xff09;&#xff0c;化险为夷&#xff01; 一、简单了解binlog MySQ…

zabbix巡检脚本

#!/bin/bash BIN/usr/local/zabbix/binpasswort() { name$2 while read line do ipecho $line|awk -F {print $1} timeecho $line|awk -F {print $2} echo -e "${name}passport${ip}探活时间\t $time" done <$1 }for i in 100.245.160.113 100.245.160.141 1…

mysqldump备份(全量+增量)

在日常运维工作中&#xff0c;对mysql数据库的备份是万分重要的&#xff0c;以防在数据库表丢失或损坏情况出现&#xff0c;可以及时恢复数据。 线上数据库备份场景&#xff1a; 每周日执行一次全量备份&#xff0c;然后每天下午1点执行MySQLdump增量备份. 下面对这种备份方案…

查找指定日期数据所在分区数据

select a.subobject_namefrom dba_objects a join (select dbms_rowid.rowid_object(rowid) object_idfrom NEWLOG4 where TO_CHAR(autudt,YYYY-MM-DD) 2021-06-22) b on a.object_id b.object_id and object_name UPPER(NEWLOG4) group by a.subobject_name

统计内存使用率shell

#!/bin/bashdatedate "%Y-%m-%d %H:%M:%S"#显示消耗资源内存最高的进程名firstps aux | grep -v "grep" | grep -v "USER" | sort -rn -k 4 | head -4 | awk -F {print $13} | sed -n 1pSecondps aux | grep -v "grep" | grep -v &q…

Oracle 11g系统自动收集统计信息

从Oracle Database 10g开始&#xff0c;Oracle在建库后就默认创建了一个名为GATHER_STATS_JOB的定时任务&#xff0c;用于自动收集CBO的统计信息&#xff0c;调用DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC收集统计信息。该过程首先检测统计信息缺失和陈旧的对象。然后确定优先…

Redis监控指标

监控指标 •性能指标&#xff1a;Performance•内存指标: Memory•基本活动指标&#xff1a;Basic activity•持久性指标: Persistence•错误指标&#xff1a;Error 性能指标&#xff1a;Performance NameDescriptionlatencyRedis响应一个请求的时间instantaneous_ops_per_s…

innobackupex参数说明

1、备份&#xff1a; #常用参数     --user&#xff1a;该选项表示备份账号。     --password&#xff1a;该选项表示备份的密码。     --port&#xff1a;该选项表示备份数据库的端口。     --host&#xff1a;该选项表示备份数据库的地址。     --socket…

innobackupex远程备份脚本

#!/bin/sh #备份主机 remote_ip10.2.142.161 Master_ip10.2.142.148 VIP103.2.132.136 #备份用户 userroot #密码 password123456 # 返回年月日 backup_datedate %F # 返回时分秒 backup_timedate %H-%M-%S # 返回今天是这周的第几天 backup_week_daydate %u backup_ok0 #备份目…

MySQL管理利器 MySQL Utilities---mysqlreplicate

mysqlreplicate 工具是在两台服务器间设置和启动复制。用户提供登录从服务器信息和连接到主的信息。也可以指定一个数据库用于测试复制。 该工具报告条件是当主和从的存储引擎不一样时。如果主和从的存储引擎不同将产生告警信息。对于Innodb存储引擎而言&#xff0c;必需完全…

MySQL管理工具MySQL Utilities — 如何连接MySQL服务器

连接参数 连接到一个服务器&#xff0c;必须指定连接参数&#xff0c;如用户名&#xff0c;主机名称&#xff0c;密码&#xff0c;端口号&#xff0c;socket。MySQL Utilities提供了三种提供这些参数的方法&#xff0c;这些方法都需要通过命令行指定。 使用.mylogin.cnf文件&…

MHA高可用

manager 组件 masterha_manger # 启动MHA masterha_check_ssh # 检查MHA的SSH配置状况 masterha_check_repl # 检查MySQL复制状况&#xff0c;配置信息 masterha_master_monitor # 检测master是否宕机 masterha_check_status # 检测当…

MySQL Replication需要注意的问题

主库意外宕机 如果没有设置主库的sync_binlog选项&#xff0c;就可能在奔溃前没有将最后的几个二进制日志事件刷新到磁盘中。备库I/O线程因此也可一直处于读不到尚未写入磁盘的事件的状态中。当主库从新启动时&#xff0c;备库将重连到主库并再次尝试去读该事件&#xff0c;但…

update和delete操作忘加where条件导致全表更新的处理方法

在数据库日常维护中&#xff0c;开发人员是最让人头痛的&#xff0c;很多时候都会由于SQL语句写的有问题导致服务器出问题&#xff0c;导致资源耗尽。最危险的操作就是在做DML操作的时候忘加where条件&#xff0c;导致全表更新&#xff0c;这是作为运维或者DBA的我们改如何处理…

Innodb结构

从MySQL5.5版本开始默认使用InnoDB作为引擎&#xff0c;它擅长处理事务&#xff0c;具有自动崩满恢复的特性&#xff0c;在日常开发中使用非常广泛&#xff0c;下面是言方的InnoDB引擎美构图&#xff0c;主要分为内存结构和磁盘结构两大部分。 内存结构主要包括Buffer Pool、C…

ES备份工具elasticdump

安装 下载node下载 | Node.js 中文网 tar xvf node-v16.5.0-linux-x64.tar.xz ln -s /app/temp/node-v16.5.0-linux-x64/bin/node /usr/bin/node ln -s /app/temp/node-v16.5.0-linux-x64/bin/npm /usr/bin/npm npm install elasticdump -g npm config get cache npm in…

innodb_flush_method理解【转】

innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、刷写模式&#xff0c;对于这个参数&#xff0c;文档上是这样描述的&#xff1a; 有三个值&#xff1a;fdatasync(默认)&#xff0c;O_DSYNC&#xff0c;O_DIRECT 默认是fdatasync&#xff0c;调用fsync()去…

linux下的/dev/shm/

首先可以看出来/dev/shm是一个设备文件, 可以把/dev/shm看作是系统内存的入口, 可以把它看做是一块物理存储设备&#xff0c;一个tmp filesystem, 你可以通过这个设备向内存中读写文件, 以加快某些I/O高的操作&#xff0c;比如对一个大型文件频繁的open, write, read&#xff0…

2021-07-30

1.服务器级别的锁等待 可以通过show processlist看到等待锁的线程id&#xff0c;但是无法知道究竟哪个线程持有锁 可以通过mysqladmin debug 相关等待锁的线程以及谁持有锁可以在错误日志中找到 2.存储引擎层的锁等待则比较麻烦&#xff0c;以下是innodb存储引擎中锁等待以及…

getopt设计shell脚本选项

写shell脚本的时候&#xff0c;通过while、case、shift来设计脚本的命令行选项是一件比较麻烦的事&#xff0c;因为Unix命令行的选项和参数自由度很高&#xff0c;支持短选项和长选项&#xff0c;参数可能是可选的&#xff0c;选项顺序可能是无所谓的&#xff0c;等等。 bash下…