MySQL定时增量备份处理脚本

在提出 MySQL主从结构灾难恢复策略机制设想 后尝试编写用于以上目的的备份脚本。

增量日志备份

每日一个全量备份,同时做binlog 的删减(只保留一个小时的日志,根据需要可以做延时),然后每小时对日志文件做增量部分的备份。

  1. #!/bin/bash
  2.  
  3. PATH=/usr/local/sbin:/usr/bin:/bin
  4.  
  5. #get cur date str 2008-10-12
  6. DATE=`date -I`
  7.  
  8. #set backup path info
  9. DATADIR="/var/lib/mysql"
  10. BASE_BAK_DIR="/backup"
  11. CUR_BAK_DIR="$BASE_BAK_DIR/current"
  12.  
  13. #set mysql user name and password
  14. MYSQL_USER="root"
  15. MYSQL_PWD="rootpwd"
  16. MYACC=" -u'$MYSQL_USER' -p'$MYSQL_PWD' "
  17.  
  18. #set backup type info
  19. INTERVAL="$1"
  20.  
  21. # days, files in base_bak_path
  22. # before this days will be deleted
  23. RETENTION=21
  24. #get host name (a part of bin log file names,
  25. #  if change set master bin file manual, need change this)
  26. HOST=`hostname -s`
  27.  
  28. #set mysql version
  29. MYVERSION="4.1"
  30.  
  31. if [ "$MYVERSION" = '4.1' ] || [ "$MYVERSION" = '5.0' ] ; then
  32.   #purge master logs to latest backup time (remain one hour bin log for slave replication delay)
  33.   PURGELOGS="mysql $MYACC -e \"PURGE MASTER LOGS BEFORE DATE_SUB( NOW(), INTERVAL 1 HOUR )\""
  34. else    
  35. echo "not support MYSql Ver $MYVERSION"
  36. exit 1
  37. fi
  38.        
  39. #check param input (daily or hourly)
  40. if [ ! $1 ];
  41. then    
  42.   read -p "Backup Interval? (Hourly|Daily) : " INTERVAL
  43. fi    
  44.  
  45. case $INTERVAL in
  46.   hourly | HOURLY | Hourly | H | h | 1 )
  47.   echo "Performing hourly level backup — `date`"
  48.   MYCMD="mysql $MYACC -e \"FLUSH LOGS\""
  49.   eval $MYCMD
  50.  
  51.   if [ -d $BASE_BAK_DIR/$DATE ] && [ "$MYVERSION" = '4.1' -o "$MYVERSION" = '5.0' ] ; then
  52.      rsync -aub $DATADIR/$HOST-bin.?????? $BASE_BAK_DIR/$DATE
  53.   else    
  54.      echo "dest dir not exists! please run daily backup first." 1>&2
  55.      exit 1
  56.   fi
  57.   exit 0
  58.   ;;
  59.  
  60.   daily | DAILY | Daily | D | d | 2 )
  61.   echo "Performing daily level backup — `date`"
  62.   # check dest path
  63.   if [ ! -d $CUR_BAK_DIR ]; then    
  64.      echo "Creating $CUR_BAK_DIR"
  65.      mkdir -p $CUR_BAK_DIR
  66.   fi
  67.  
  68.   MYCMD="mysqlhotcopy $MYACC –regexp=.* $CUR_BAK_DIR"
  69.   eval $MYCMD
  70.   chown -R mysql: $CUR_BAK_DIR/
  71.   mv $CUR_BAK_DIR $BASE_BAK_DIR/$DATE
  72.   eval $PURGELOGS
  73.  
  74.   #delete files that outdate
  75.   find $BASE_BAK_DIR -ctime +$RETENTION -exec rm -rf '{}' \;
  76.   exit 0
  77.   ;;
  78.  
  79.   * )
  80.   echo "Invalid Selection" 1>&2
  81.   exit 1
  82. esac

可以在脚本的前面指定好备份目录参数

DATADIR="/var/lib/mysql"
BASE_BAK_DIR="/backup"
CUR_BAK_DIR="$BASE_BAK_DIR/current"

以及用来连接数据库的账号的参数

#set mysql user name and password
MYSQL_USER="root"
MYSQL_PWD="rootpwd"

通过参数 RETENTION=21 来指定备份文件保留的天数,要视具体用来做备份的磁盘大小和数据库大小做综合衡量处理。

最后将脚本添加到crontab中定时运行
首先设定每天备份一次的,然后再设定每小时的备份,其中第一次的每小时备份应该是在每天备份执行之后。
数据库发生失败时的恢复在每日全量备份基础上通过日志文件快速恢复到最近时间的变化。

Popularity: 4% [?]

Related

MySQL主从结构灾难恢复策略机制设想

当数据库服务器建立好以后,我们一般为了安全以及性能考虑,对数据库建立一个主从结构配置。但是这样做了以后查询性能是得到了提高,但是数据库的安全性真的像我们想的那样,主库坏掉了可以使用从库顶上使用吗?
考虑如下一种情况:
数据库服务器不是发生故障,而是被黑客黑了,黑客将其中一个数据表删除了,只时候我们建立的从库还有作用吗?
答案是:
没有用,因为从库上也会执行主库上所执行的操作,将这个表删除了,这个表的数据在主库和从库上都不存在了,里面的数据再也回不来了。

由此我们在建立了主从服务器后还要做好数据库的备份策略,保障在数据库遭到破坏后(物理损坏或黑客破坏),可以迅速恢复到最后一次正常的状态,使得数据的损失达到最小,同时要考虑做恢复操作所需要花费的时间(1分钟,10分钟,1小时,1天?)。

备份策略考虑

恢复策略考虑

1. 主服务器数据被黑客篡改破坏

这个时候从库备份的数据无效,因为从库的数据也被破坏,需要重备份的数据中恢复。
情况一: 主库的机器未被黑,只是数据库被黑,数据破坏
处理方法: 停止主库服务,修改主库的my.cnf 文件使其数据库文件目录指向到备份的数据库目录,根据备份的数据重做从库数据库。
情况二: 主库的机器被黑,整个机器失去控制,同时数据被破坏。
处理方法: 启动利用其他机器上最近备份的全量数据,建立新的数据库服务。

2. 主库数据由于意外原因丢失,但是未发生数据篡改

比如主数据库机器虽未被黑客攻击,但是只是停了相关服务,未对数据做篡改破坏。
或机器由于意外原因发生物理损坏不可用,但是未有发生数据被篡改。
处理方法1: 直接使用从库切换
将从库中的一台变更为主库,更改其他从库的主库连接设置,使他们从这台新设的主库机器上复制数据。
处理方法2: 安装数据被篡改的方式处理。

策略原则
鸡蛋不能放在一个篮子中,当一个篮子坏掉了,还有其他篮子可用。
所以数据要在多处以及多种方式做备份恢复处理。

参考:
1. Mysql Slave群切换Master (from alidba)
2. 数据库的自动备份与数据库被破坏后的恢复(mysqlhotcopy)

Popularity: 4% [?]

Related

常见MySQL数据库备份工具和备份方式比较

原文 Hands on MySQL Backup & Migration

本文在原文的基础上稍有删减。

用以备份的工具

1. mysqldump
http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html

2. mysqlhotcopy
http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html

3.mysqlsnapshot
http://jeremy.zawodny.com/mysql/mysqlsnapshot/

4.ibbackup
http://www.innodb.com/hot-backup/order/

联机备份 .VS. 脱机备份

联机备份通常使用在不能接受数据库停机的情况下,一般来说,脱机备份速度快,并且发生错误的几率少,我们不用担心数据库正在执行事务,锁表等容易发生一致性问题的发生。如果你幸运的可以停下数据库或者有一个主从方式的数据库,请使用脱机方式备份。

Data Dump vs Raw backups

Data dump 输出一系列SQL 语句序列,可以在后来用来重新创建数据库的结构并恢复数据。mysqldump 是这个领域的首选工具,他可以用在任意类型的表上面,无论是本地的还是网络的。当然,由于要产生很多额外的SQL语句,导出结果将是一个很大的文件并且占用很多CPU资源,最重要的是,当数据恢复后需要一次完全的索引重建。

更有效率的方法是是对MySQL数据库的物理文件做一次快照(snapshot)。因为我们跳过了很多转化步骤,因此处理起来比较高效。 做一个MyISM数据表的备份只要拷贝磁盘上数据文件和索引文件。对InnoDB,需要备份对应表空间和关联的事务日志。

mysqldump / mysqlhotcopy / mysqlsnapshot / ibbackup

mysqldump – (online, dump) – 最一般的工具,他会通过锁表的方式从一个联机数据库中做数据导出并写到指定的文件中(磁盘或网络上)。他只适合小的数据库。

# typical mysql dump backup and restore usage
mysqldump -u root -pPassword -x --all-databases > db_dump.sql
mysql -u root -pPassword < db_dump.sql

# dump into 'backup' folder (local machine), into two text files <data, table_structure>
mysqldump -T backup --fields-terminated-by=',' database-name -u root -pPassword

# compress the dumped data on the fly
mysqldump -u root -pPassword --all-databases | bzip2 -c > db_dump.bz2

mysqlhotcopy – (online, raw) 将对由 ISAM或MyISAM 表构成的数据库做一个完全的物理备份。他的操作方式:对所有表获取一个只读锁=>做文件拷贝=>释放锁。

# perform an online backup into /backup/location
mysqlhotcopy -u root -p password database_name /backup/location

mysqlsnapshot – (online, raw) 一个非常好的工具用来在联机方式下获得MySQL数据库的一个快照。可以配置它来压缩数据,并/或 为每一个数据库提供一个分离的tar文件。 不过他只适合 MyISAM 类型数据库。

# save a full database snapshot of an online database into /backup/location
mysqlsnapshot -u root -pPassword -s /backup/location

# restore a snapshot
tar -xvf /backup/location/db.tar

ibbackup – (online, raw) 可以对使用InnoDB和MyISAM表的任何数据库做联机备份。是一个很好的工具就是要收费.当然如果你是一个InnoDB的用户,还是值得花钱购买的。

# perform online backup of MyISAM / InnoDB tables
ibbackup /etc/my.cnf /etc/ibbackup.cnf

# restore recent backup (as configured in ibbackup.cnf)
ibbackup --restore /etc/ibbackup.cnf

cp, scp, nc – (offline, raw) 如果你可以停下数据库,则可以使用这几个工具直接拷贝数据库目录下的文件。是获取数据库快照的最安全方法。

Popularity: 3% [?]

Related