高逼格企业级MySQL数据库备份方案,原来是这样....

很多人,这里说的是运维工程师们,一提到写某某方案,很是头疼。不是上某度一统搜索,就是同样一句话在N个群全部群发一遍:“有没有某某方案,可以共享一下的吗??求助,各位大佬们”,估计十有八九,全部石沉大海,杳无音讯。

其实,到底是真的很难,还是说你没有完全掌握整个备份思路的整理?一个方案的好坏,在于对于外行人来说,能不能一眼就能看懂其中要表达的意思,而且不需要很多的思考就可以。

一份好的备份方案无非包括以下几点:

  • 为什么需要备份?
  • 备份的方式有哪些?
  • 某几种备份方式的区别在哪?
  • 备份实战操作概述
  • 恢复实战操作概述
  • 其它备注信息

那么,此文将从以上几个角度,结合一些实际的实战经验,分步阐述一个完整的备份方案到底是怎么样构成的。

为什么需要数据库备份?

很多人,一看这标题,肯定张口就会答,这不是废话么。不备份故障了怎么办?跑路吗?数据被沙雕开发(不许喷)误删了怎么办?背锅吗?

当然,大家都知道备份的重要性与必要性。

1、保证数据安全与完整

企业的数据安全应该来说是企业的命脉,一旦丢失或造成损坏,轻则损失客户与金钱,重则倒闭(已经有前例在)。

备份的目的:为了保证数据在被人为失误、操作不当、蓄意等情况下删除或损坏后,能及时、有效的进行恢复并不会很大程度上影响到业务运行。

2、为业务提供不间断服务

实际生产环境对数据库的要求,首先就是具备7×24×365不间断服务的能力,这也是一定要备份数据库的其中原因之一。

数据库的备份方式

常用的备份方式包括以下:

  • 逻辑备份
  • 物理备份

1、逻辑备份

逻辑备份其实就是利用MySQL数据库自带的mysqldump命令,或者使用第三方的工具,然后把数据库里的数据以SQL语句的方式导出成文件的形式。在需要恢复数据时,通过使用相关的命令(如:source )将备份文件里的SQL语句提取出来重新在数据库中执行一遍,从而达到恢复数据的目的。

实例如下:

mysqldump -A -B --single-transaction >/server/backup/mysql_$(date +%F).sql

一般备份时都会进行压缩处理,以节省磁盘空间,如下

mysqldump -A -B --single-transaction |gzip>/server/backup/mysql_$(date +%F).sql.gz

恢复操作

cd /server/backup/gzip -o mysql_$(date +%F).sql.gz

mysql -uroot -pMyadmin -h mysqldb.mingongge.com

> source /server/backup/mysql_$(date +%F).sql

逻辑备份的优点与使用场景

优点:简单,易操作,自带工具方便、可靠。

使用场景:数据库数据量不大的情况可以使用,数据量比较大(超过20G左右)时备份速度比较慢,一定程度上还会影响数据库本身的性能。

2、物理备份

物理备份就是利用命令(如cp、tar、scp等)直接将数据库的存储数据文件复制一份或多份,分别存放在其它目录,以达到备份的效果。

这种备份方式,由于在备份时数据库还会存在数据写入的情况,一定程度上会造成数据丢失的可能性。在进行数据恢复时,需要注意新安装的数据的目录路径、版本、配置等与原数据要保持高度一致,否则同样也会有问题。

所以,这种物理备份方式,常常需要在停机状态下进行,一般对实际生产中的数据库不太可取。因此,此方式比较适用于数据库物理迁移,这种场景下这种方式比较高效率。

物理备份的优点及使用场景

优点:速度快,效率高。

场景:可用于停机维护及数据库物理迁移场景中。

实际生产环境中,具体使用哪种方式,就需要看需求与应用场景所定。

全量与增量备份概述

在介绍完备份方式之后,再来介绍一下,增量与全量备份这两个概念。

什么是全量备份?

全量备份:就是将数据库中的所有数据,或者是某一个特定的库里的所有数据,一次全部备份下来。

备份数据库中所有数据

mysqldump -A -B --single-transaction |gzip>/server/backup/All_data_$(date +%F).sql.gz

备份某个库的数据

mysqldump -A -B --single-transaction testDB1|gzip>/server/backup/testDB1_$(date +%F).sql.gz

什么是增量备份?

增量备份:指的是上一次全量备份之后到下一次全量备份这前这段时间内数据库所更新或者是增加的数据,将其备份下来。

注:全量备份是一个文件,而增量备份则是MySQL的binlog日志文件。所以常说的增量备份就是备份binlog日志文件。

两者的区别在哪?

全量备份:需要的备份时间长一点,恢复时间会短一点,因为文件数少,维护方便。但是,全量备份的文件大,占用一定的磁盘空间,全理备份时会一定程序上影响数据库的性能(这也就是为什么在0:00点备份的原因),也因文件大的原因,不便于服务器本地保存过多文件,重要业务的全量备份文件可能需要手工下载或迁移到服务器之外的存储空间中。

增量备份:备份简单,恢复时复杂一点,因为文件数量多,需将所有binlog文件解析成SQL语句,如下:

mysqlbinlog testDB1-bin.000001 testDB1-bin.000002 >./bin.sql

然后,再通过恢复的方式进行恢复

mysql -uroot -pMyadmin -h mysqldb.mingongge.com

> source /server/backup/bin.sql

或者如下操作

cd /server/backup

mysql testDB1 <./bin.sql

备份与恢复实践操作

对于Mysql数据库的备份,一般采取脚本+定时任务进行日常备份。

常用执行策略是:

  • 每天0:00执行一次全量备份
  • 按业务需求执行增量备份

分享一个我在一个创业公司初期的一个备份方案实例

阿里云数据库服务器备份方案

方案一:

目前数据库是主从同步,从库开启binlog日志功能进行异地备份,就目前数据量而言,只需要在从库的基础上进行定时全量与增量备份数据库即可。

1、创建备份目录

mkdir /server/backup

2、备份数据库到指定目录

mysqldump --single-transaction -F -B phoenix_coupon_production|gzip >/server/backup/phoenix_$(date +%F).sql.gz

mysqldump --single-transaction -F -B ywotx|gzip >/server/backup/ywotx_$(date+%F).sql.gz

find /server/backup/ -type f –name “*.sql.gz”-mtime +7 |xargs rm-f

将脚本写入定时任务,分时段进行打包备份 

3、定时备份二进制文件

通过参数刷新binlog产生新的文件,通过脚本判断文件新旧,然后备份旧的日志文件
mysqladmin -uroot -pywotx!123 flush-logs #刷新日志,产生新的日志文件

最终将备份文件同步或定时手工下载到异地备份服务器异地存储备份文件,实现数据库备份文件双备份存储,防止服务器硬件故障。

方案二

后期数据量增大之后,数据库需要进行读写分离,实现主写,从读,主从同步的架构,备份还是按照原来的备份方案进行,可采用分库分表进行数据备份,防止数据量大导致的恢复时间的问题,提升恢复效率。

1、创建备份目录

Mkdir /server/backup

2、备份数据到指定目录( 分库分表)
#/bin/sh
#create by mingongge at 2017-06-01
BACKUPDIR=/server/backup
DATE=`date +%F`
USER=root
PASSWD=”123456”
CMD=”mysql –u$USER –p$PASSWD”
DUMPCMD=”mysqldump –u$USER –p$PASSWD --single-transaction -F”

for dbname in `${CMD} –e “show databases”|sed ‘1d’`
do
mkdir –p${BACKUPDIR}/${dbname}
for tablename in`${CMD} –D ${dbname} –e “show tables”|sed ‘1d’`
do
${DUMPCMD} --tables${dbname} ${tablename} |gzip > ${BACKUPDIR}/${dbname}/${tablename}_$(DATE).sql.gz
done
done

find /server/backup/${dbname} -type f –name “*.sql.gz”-mtime +7|xargs rm -f

3、定时备份二进制文件(增量)
备份方法同方案一

备份频率:

  • 每天0:00进行一次数据库全备
  • 每天03:00 9:00 15:00 21:00 增量备份一次

数据库的备份,每天一次全备,在全备时会更新binlog日志,重新生成新的日志文件,因此在下一次增量备份时再刷新binlog,再次产生新的日志文件,实现从全备之后对数据库的操作的增量备份,一旦发现数据问题,立即刷新binlog重新成新的日志文件,将原来的日志文件手工备份一份,然后找出产生数据问题的点,从而利用日志文件进行恢复全备到产生数据问题点之间的数据,然后恢复从问题点到发现问题时间段之间的数据.

新增一台备份服务器,配置如下:

实例配置:2核/4G/40G + 200G高效云盘 经典网络 1M 295元/月

方案总结:

对于数据库服务器本地的备份文件基本上只保留一周时间内的数据,备份服务器按需求(一般保留至少30天的数据),保留30天的数据包括数据库全备文件与增量备份文件,后期可按实际生产需求进行修改,保留时间长短只会增加相应的服务器磁盘空间,增加一定的成本,其它无需改动,操作较为灵活、方便。

本文分享自微信公众号 - 数据和云(OraNews)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大讲堂的专栏

技术大牛都是怎么突破运维瓶颈、提升数据价值的?

? 2019年度Gdevops全球敏捷运维峰会 经过潜心打磨,结合行业热点 将于5月10日以北京为起点强势启动 展开新一年精彩纷呈的技术巡演! 运维专场精华...

17630
来自专栏云加头条

腾讯数据库专家雷海林分享智能运维架构PPT下载

2019年5月8日-10日的DTCC2019年中国数据库大会上,腾讯云数据库专家工程师雷海林首受邀做了主题为《TDSQL智能运维平台-扁鹊架构与实践》的技术分享...

15520
来自专栏数据派THU

数据蒋堂 | 如何将数据热导出到文件

本文共1800字,建议阅读8分钟。 我们把数据存储到文件中,只要有好的计算引擎,基于文件计算将获得更优性能。

11220
来自专栏腾讯移动品质中心TMQ的专栏

做一个小程序给老爸玩乐(小程序云开发实践)

一、概述 有同事提醒我说,小程序出了云开发功能。我看了一下觉得蛮有意思的,琢磨着可以给老爸做一个买马(广东民间流行的一种六合彩赌博)的小程序。然后用了2个周末...

24730
来自专栏FreeBuf

在“天眼”看到弑母案嫌疑人之前,我们付出了什么?

不久前,一则新闻引起巨大震动,三年前弑母案中的嫌疑人吴谢宇在重庆江北机场被抓,有人透露吴谢宇进入机场不到十分钟,警察便找到了他。这场所谓的“完美犯罪”是否完美我...

17530
来自专栏青青天空树

springboot+security整合(1)

  Spring Security 是一个能够为基于 Spring 的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在 Spring ...

12030
来自专栏生信技能树

100篇泛癌研究文献解读之可变剪切事件大起底

文章发表于 2014 Dec 4. doi: 10.4137/CIN.S19435, 到现在引用才6次,可以说是泛癌研究的一朵奇葩!题目是:A Pan-Canc...

17840
来自专栏尖动

腾讯云最新优惠活动,服务器一年优惠价格只需99元。

腾讯云最新优惠活动开始了,服务器一年只需99元,另外还有数据库等等腾讯云的产品,都参与了这次优惠活动。需要购买腾讯云的不要错过这次机会哦,如果错过了这次腾讯云的...

37100
来自专栏银河系资讯

在MySQL中,不要使用“utf8”。使用“utf8mb4”

今天的错误:我试图将一个UTF-8字符串存储在MariaDB“utf8”编码的数据库中,并且引发了一个奇怪的错误:

9920
来自专栏程序员的成长之路

记住:永远不要在 MySQL 中使用 UTF-8

最近我遇到了一个bug,我试着通过Rails在以“utf8”编码的MariaDB中保存一个UTF-8字符串,然后出现了一个离奇的错误:

9920

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励