数据库 MySQL 有没有较的数据备份方案.

lb563 · 2013年06月06日 · 最后由 woody1983 回复于 2013年10月11日 · 7125 次阅读

项目做到这个点.感觉 mysql 自带的 mysqldump 备份数据不太适合. 所以在网上找了一些方案:

1,mysqldump

2,mysqlhotcopy

3,准备一台从服务器,开启日志同步功能,专门做备份(master-slave 方式

还有一种是使用软件: Xtrabackup 备份 MySQL 数据库

不知道群里有没有人用上面的方案.或者还有没有其它的方案来做这件事呢?

多大规模的数据库?

@lb563 mysqldump 都不合适了,你可以考虑数据冷热分离、分库分表了。

有几个库,平均每个有一两百张表. mysqldump 有时间很慢,前期都还行.不一会就导执行完了.现在得慢了很多.

#1 楼 @iamroody #2 楼 @zfjoy520

看你网站多少人在用了,是不是全球性的,我选择在凌晨三点直接关闭 apache, 关闭 mysql, 把/var/lib/mysql 里面 有改动的 数据表对应的三个文件 tar 个包,再重启 mysql 和 apache,几年了,运行可靠,没遇到抱怨的,断网时间最多也就一分钟吧。

本机保留 90 天备份,最近 10 天的同步到 dropbox,因为加了密码,被偷也没关系。有条件可以上传到不在一个机房的 ftp 服务器。

以下是一个小站的备份代码,另一个大站的,大同小异,把代码里面的 ruby-china.org ServerName 密码 User 按自己的情况替换掉就可以了。

#!/bin/bash

today=`date '+%Y-%m-%d'`
bakdir=/home/User/bak/ServerName/$today
mkdir -p $bakdir
/etc/init.d/apache2 stop > /dev/null
/etc/init.d/mysql stop > /dev/null
cp /var/lib/mysql/ $bakdir -R
/etc/init.d/mysql start > /dev/null
/etc/init.d/apache2 start > /dev/null

cd $bakdir
cd ..
tar cf $today.tar ./$today
rm ./$today -fr
7z a -p密码 $today.ruby-china.org.7z $today.tar
rm ./$today.tar

manyweeksbefore=`date --date='10 days ago' '+%Y-%m-%d'`
manyweeksbeforeserver=`date --date='90 days ago' '+%Y-%m-%d'`
rm /root/Dropbox/ruby-china.org/$manyweeksbefore.ruby-china.org.7z > /dev/null
rm /home/User/bak/ServerName/$manyweeksbeforeserver.ruby-china.org.7z  > /dev/null
cp /home/User/bak/ServerName/$today.ruby-china.org.7z /root/Dropbox/ruby-china.org/

我从来都是直接用 root 用户 copy 数据库文件,各种正规军会觉得不专业,但 It works!

关掉 mysql 会保险一点,如果你确定那个表没有被写 (比如 discuz 关站提示正在备份),不关 mysql 照样可以 copy 数据库文件。恢复的时候,把属主改成 mysql:mysql , 权限改成 660 就可以了,如果是 tar 打的包,什么都不用改。

我原来也用过 mysqldump, 真是慢!要从数据库读出数据,又变成 sql 语句,这又何苦,遇到一些用户发特殊符号的,从 mysqldump 恢复的时候,有时候还出错。

最后一点强调一下,这种方法只适合 MYISAM 数据库引擎 INNODB 不行。。。

暂时数据还没到那个点;lz 的方案 3 感觉应该挺好,通过日志同步主备,另使用 slave db 定时批量导出备份。

如果有机器资源的话,master/slave 是最好的 如果服务器是用 LVM,可以用 snapshot 都没有的话,推荐用 xtrabackup

#7 楼 @doabit 现在一直就是用这个方式来处理数据备份的.只是简单的把数据导出然后压缩成 tar 文件放么硬盘上.用的时候再找到对应的数据进行分析.

#5 楼 @Peter 谢谢分享你的经验.感觉你这种方案和现在用的backup方案差不多.

#9 楼 @lb563 我觉得这种在足够了,如果数据量很大的话,还是用第 3 种吧

master/slave 相当不错, 然后用 mysqldump 定时 dump 一下

master+slave(这样的作用还有读写分离,镜像切换什么的,好处很多),然后定期全量备份,每天增量备份。(备份用 percona 的 xtrabackup) 另外,如果机子磁盘比较大的话,可以把 binlog 的保留时间设置大点,这样可以通过 binlog 恢复数据。

基本这样就 ok 了。

以前公司做的是 1、准备一台从服务器 A 与主服务放同一机房,开启日志同步功能,专门做备份(master-slave)方式。 2、公司内部放一台服务器 B,设定计划任务,定时停掉数据库主从机制,去机房服务器 A 将数据库文件下载下来。 3、完成下载后,自动再次开启主从机制。

如果备份频率较高,数据量大,并且资源丰富的话,master/slave 吧

#13 楼 @xiaogui 还会定时到机房下载备份文件? 感觉有点麻烦. 为何不定期的 ftp 上去然后下载文件呢?

#15 楼 @lb563 我说的就是定时计划任务,服务器 B 去机房服务器 A 自动 ftp 上去下载文件的那种。

#16 楼 @xiaogui 嗯,我理解失误.

#17 楼 @lb563 是我说的不够明白,哈哈。

文件备份很快,但是可能需要 check & repair.

我给你一个建议 DDL 和 DATA 分开备份 重要的表单独备份出来 Basic 的表一起备份

需要 登录 后方可回复, 如果你还没有账号请 注册新账号