数据库备份方式有哪些(教你这4种备份方式)

发布日期:2025-02-10 23:28:19     手机:https://m.xinb2b.cn/shenghuo/news123295.html    违规举报
核心提示:为什么需要备份数据? 在生产环境中我们数据库可能会遭遇各种各样的不测从而导致数据丢失, 大概分为以下几种. 硬件故障 软件故障 自然灾害 黑客攻击 误操作 (占比最大) 所以, 为了在数据丢失之后能够恢复数据, 我们

数据库备份方式有哪些(教你这4种备份方式)

为什么需要备份数据?

在生产环境中我们数据库可能会遭遇各种各样的不测从而导致数据丢失, 大概分为以下几种.

硬件故障 软件故障 自然灾害 黑客攻击 误操作 (占比最大)

所以, 为了在数据丢失之后能够恢复数据, 我们就需要定期的备份数据, 备份数据的策略要根据不同的应用场景进行定制, 大致有几个参考数值, 我们可以根据这些数值从而定制符合特定环境中的数据备份策略

能够容忍丢失多少数据 恢复数据需要多长时间 需要恢复哪一些数据 数据的备份类型

数据的备份类型根据其自身的特性主要分为以下几组

完全备份 部分备份 完全备份指的是备份整个数据集( 即整个数据库 )、部分备份指的是备份部分数据集(例如: 只备份一个表)

而部分备份又分为以下两种

增量备份 差异备份 增量备份指的是备份自上一次备份以来(增量或完全)以来变化的数据; 特点: 节约空间、还原麻烦 差异备份指的是备份自上一次完全备份以来变化的数据 特点: 浪费空间、还原比增量备份简单

示意图

MySQL备份数据的方式

在MySQl中我们备份数据一般有几种方式

热备份 温备份 冷备份 热备份指的是当数据库进行备份时, 数据库的读写操作均不是受影响 温备份指的是当数据库进行备份时, 数据库的读操作可以执行, 但是不能执行写操作 冷备份指的是当数据库进行备份时, 数据库不能进行读写操作, 即数据库要下线

MySQL中进行不同方式的备份还要考虑存储引擎是否支持

MyISAM 热备 × 温备 √ 冷备 √ InnoDB 热备 √ 温备 √ 冷备 √ 我们在考虑完数据在备份时, 数据库的运行状态之后还需要考虑对于MySQL数据库中数据的备份方式 物理备份一般就是通过tar,cp等命令直接打包复制数据库的数据文件达到备份的效果 逻辑备份一般就是通过特定工具从数据库中导出数据并另存备份(逻辑备份会丢失数据精度) 物理备份 逻辑备份 备份需要考虑的问题

定制备份策略前, 我们还需要考虑一些问题

我们要备份什么?

一般情况下, 我们需要备份的数据分为以下几种

数据 二进制日志, InnoDB事务日志 代码(存储过程、存储函数、触发器、事件调度器) 服务器配置文件

备份工具

这里我们列举出常用的几种备份工具

mysqldump : 逻辑备份工具, 适用于所有的存储引擎, 支持温备、完全备份、部分备份、对于InnoDB存储引擎支持热备

cp, tar 等归档复制工具: 物理备份工具, 适用于所有的存储引擎, 冷备、完全备份、部分备份

lvm2 snapshot: 几乎热备, 借助文件系统管理工具进行备份

mysqlhotcopy: 名不副实的的一个工具, 几乎冷备, 仅支持MyISAM存储引擎

xtrabackup: 一款非常强大的InnoDB/XtraDB热备工具, 支持完全备份、增量备份, 由percona提供

设计合适的备份策略

针对不同的场景下, 我们应该制定不同的备份策略对数据库进行备份, 一般情况下, 备份策略一般为以下三种

直接cp,tar复制数据库文件 mysqldump+复制BIN LOGS lvm2快照+复制BIN LOGS xtrabackup

以上的几种解决方案分别针对于不同的场景

如果数据量较小, 可以使用第一种方式, 直接复制数据库文件 如果数据量还行, 可以使用第二种方式, 先使用mysqldump对数据库进行完全备份, 然后定期备份BINARY LOG达到增量备份的效果 如果数据量一般, 而又不过分影响业务运行, 可以使用第三种方式, 使用lvm2的快照对数据文件进行备份, 而后定期备份BINARY LOG达到增量备份的效果 如果数据量很大, 而又不过分影响业务运行, 可以使用第四种方式, 使用xtrabackup进行完全备份后, 定期使用xtrabackup进行增量备份或差异备份
 
 
本文地址:https://xinb2b.cn/shenghuo/news123295.html,转载请注明出处。

推荐图文
推荐生活健康
网站首页  |  关于我们  |  联系方式  |  使用协议  |  版权隐私  |  网站地图  |  违规举报  |  蜀ICP备18010318号-4  |  百度地图  | 
Processed in 0.118 second(s), 80 queries, Memory 0.51 M