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

lb563 · 发布于 2013年06月06日 · 最后由 woody1983 回复于 2013年10月11日 · 4620 次阅读
257

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

1,mysqldump

2,mysqlhotcopy

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

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

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

共收到 20 条回复
4744

多大规模的数据库?

958

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

257

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

#1楼 @iamroody #2楼 @zfjoy520

1553

看你网站多少人在用了,是不是全球性的,我选择在凌晨三点直接关闭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/
1553

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

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

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

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

2511

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

162

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

257

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

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

694

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

2408

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

3479

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

基本这样就ok了。

667

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

4744

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

257

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

667

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

257

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

667

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

973

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

3288

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

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