2023年7月30日发(作者:)
windows下mysql每天定时备份数据库⼏种⽅法在windows中备份mysql 数据库的⽅法有很多种,如有常⽤的WinRAR备份mysql、mysqldump备份成sql⽂件、xcopy 直接复制⽂件形式备份数据库,下⾯我来总结⼀下这些⽅法,并给出相关实例。第⼀种:新建批处理⽂件 ,⾥⾯输⼊以下代码: 代码如下 复制代码net stop mysqlxcopy "C:/Program Files/MySQL/MySQL Server 5.0/data/piaoyi/*.*"D:/db_backup/%date:~0,10%/ /ynet start mysql注意:批处理命令中路径⾥有空格的话,必须在路径上加上双引号!然后使⽤Windows的"计划任务"定时执⾏该批处理脚本即可。(例如:每天凌晨3点执⾏)解释:备份和恢复的操作都⽐较简单,完整性⽐较⾼,控制备份周期⽐较灵活。此⽅法适合有独⽴主机但对mysql没有管理经验的⽤户。缺点是占⽤空间⽐较多,备份期间mysql会短时间断开(例如:针对30M左右的数据库耗时5s左右)。
关于时间参数的参考:%date:~0,10% //提取年⽉⽇信息%date:~-3% //提取星期⼏信息%time:~0,5% //提取时间中的时和分%time:~0,-3% //提取时和分和秒信息第⼆种:mysqldump备份成sql⽂件==============假想环境:MySQL 安装位置:C:/MySQL论坛数据库名称为:bbsMySQL root 密码:123456数据库备份⽬的地:D:/db_backup/脚本: 代码如下 复制代码@echo offset "Ymd=%date:~,4%%date:~5,2%%date:~8,2%"C:/MySQL/bin/mysqldump --opt -u root --password=123456 bbs >D:/db_backup/bbs_%Ymd%.sql@echo on将以上代码保存为backup_然后使⽤Windows的"计划任务"定时执⾏该脚本即可。(例如:每天凌晨5点执⾏back_)说明:此⽅法可以不⽤关闭数据库,并且可以按每⼀天的时间来名称备份⽂件。通过%date:~5,2%来组合得出当前⽇期,组合的效果为yyyymmdd,date命令得到的⽇期格式默认为yyyy-mm-dd(如果不是此格式可以通过pause命令来暂停命令⾏窗⼝看通过%date:~,20%得到的当前计算机⽇期格式),所以通过%date:~5,2%即可得到⽇期中的第五个字符开始的两个字符,例如今天为2009-02-05,通过%date:~5,2%则可以得到02。(⽇期的字符串的下标是从0开始的)第三种:利⽤WinRAR对MySQL数据库进⾏定时备份。
对于MySQL的备份,好的⽅法是直接备份MySQL数据库的Data⽬录。下⾯提供了⼀个利⽤WinRAR来对Data⽬录进⾏定时备份的⽅法。⾸先当然要把WinRAR安装到计算机上。将下⾯的命令写⼊到⼀个⽂本⽂件⾥,如 代码如下 复制代码net stop mysql"C:/Program Files/WinRAR/" a -ag -k -r -s D:/db_backup/mysql_.rar"C:/Program Files/MySQL/MySQL Server 5.0/data/"net start mysqlwinrar参数解释:a: 添加⽂件到压缩⽂件-ag: 使⽤当前⽇期⽣成压缩⽂件名-k: 锁定压缩⽂件-r: 递归⼦⽬录-s: 创建固实压缩⽂件 执⾏以上⽂件后,会⽣成⼀个压缩⽂件如:mysql_。 进⼊控制⾯版,打开计划任务,双击"添加计划任务"。在计划任务向导中找到刚才的⽂件,接着为这个任务指定⼀个运⾏时间和运⾏时使⽤的账号密码就可以了。 这种⽅法缺点是占⽤时间⽐较多,备份期间压缩需要时间,mysql断开⽐第⼀种⽅法更多的时间,但是对于⽂件命名很好。1.在D盘创建db_backup⽂件夹,并新建。2.在⾥⾯加⼊⼀下代码: 代码如下 复制代码echo 取⽇期、时间变量值set yy=%date:~0,4%set mm=%date:~5,2%set dd=%date:~8,2%if /i %time:~0,2% lss 10 set hh=0%time:~1,1%if /i %time:~0,2% geq 10 set hh=%time:~0,2%set mn=%time:~3,2%set ss=%time:~6,2%set date=%yy%%mm%%dd%set time=%hh%%mn%%ss%set filename=%date%_%time%"C:/Program Files (x86)/MySQL/MySQL Server 5.0/bin/" -uroot -pxxx --opt --default-character-set=utf8 -e --triggers -R --hex-blob --flush-logs -xDBNAME > C:/db_backup/DBNAME%filename%.sqlecho 导出已经完成#pause在这⾥要注意你的MySQL安装路径以及相应的数据库⽤户名和密码,我使⽤的是D:/sense/mysql/bin。3.双击运⾏此脚本,看是否会⽣成Dbname20111207_⽂件,如有则脚本⽆错误。4.进⼊控制⾯板,在任务计划⾥添加计划任务,把要执⾏的批处理以浏览⽅式加⼊任务计划,并设定好执⾏时间,最好选择每天执⾏,这样就实现每天⾃动备份数据库了。本⽂章来给各位同学介绍⼀下关于利⽤MySQL中InnoDB数据⽂件中的恢复数据,如果你正需要此⽅法可进⼊参考哦。1. 简述恢复原理因为⽂档中较为详细的描述,这⾥只简单说明。所有InnoDB的数据都是索引的⽅式组织的,⽽且所有的数据都是存储在16KB的数据块中。恢复的过程分⼏步,分解所有数据⽂件为单个16KB⼤⼩的页⾯,根据每个页⾯的标记的数据起点开始尝试匹配,如果与给定表定义的size合适,认为匹配成功,则输出记录。2. 并⾏的恢复数据恢复通常是争分夺秒的,PDRTI⼯具本⾝是⼀个基础⼯具,如果使⽤该⼯具做做串⾏恢复,时间会⾮常长,通过简单的shell脚本可以让constraints_parser脚本并⾏⼯作,这样可以⼤⼤缩短数据的恢复时间。根据实际经验,机器稍微好点,实际恢复时间可以缩短到串⾏的⼆⼗分之⼀。也就是说,原来需要40⼩时,通过并⾏可能2个⼩时就可以了。以下是两个并⾏恢复的脚本,供参考: 代码如下 复制代码#!/bin/bashws=/u01/recoverypagedir=/u01/recovery/pages-1372436970/FIL_PAGE_INDEXlogdir=/u01/recovery/logrectool=/u01/recovery/percona-data-recovery-tool-for-innodb-0.5/constraints_parsercd `dirname $rectool`count=0page_count=353894page_done=0startdate=`date +%s`for d1 in `ls $pagedir`do count=$(($count+1)) echo "in page $d2 at dir $d1" > $logdir/$ thedate=`date +%s` echo "$page_done / $page_count at $thedate from $startdate" total=`ls -l $pagedir/$d1/|wc -l` page_done=$(($page_done+$total)) threads=`ps axu|grep parser_jobs|grep -v grep|wc -l` echo $threads while [ $threads -gt 48 ]; do sleep 1 threads=`ps axu|grep parser_jobs|grep -v grep|wc -l` done $ws/parser_ $pagedir/$d1 > $ws/ 2>&1 &done#!/bin/bashpagedir=/u01/recovery/pages-1372436970/FIL_PAGE_INDEXlogdir=/u01/recovery/logrectool=/u01/recovery/percona-data-recovery-tool-for-innodb-0.5/constraints_parserlogfile="$logdir/`basename $1`.log"echo "$1" > $logfileif [ -d $1 ];then for d2 in `ls $1` do $rectool -5 -f $1/$d2 >> $logfile 2>/dev/null donefi3. 从索引中恢复如果知道数据表的索引结构,如果数据部分损坏,但是索引部分完整,可以通过这个办法提取出来更多的字段信息。4. 紧急情况下的问题处理这次下厨房的技术总结中提到,"第⼀时间停⽌MySQL防⽌硬盘继续写⼊这个应急措施是错误的",正常如果进程没有被关闭,进程所打开的⽂件是不会被覆盖的,可以通过从/proc⽂件系统拷贝的⽅式恢复出当前仍然打开的⽂件(参考:Recovering files from /Proc)。如果数据⽂件和⽇志⽂件都能够cp出来,那么有希望让MySQL⾃⼰启动,并根据事务⽇志恢复出当前⼀致的数据。
发布者:admin,转转请注明出处:http://www.yc00.com/news/1690655341a387697.html
评论列表(0条)