备份技术
- 逻辑备份
- 物理备份
- 联机磁盘拷贝
- 基于快照的备份
- 基于复制的备份
- 二进制日志备份
- 增量备份
逻辑备份
- 将数据库和表转换为包含用于重建数据库的SQL语句的文本文件
优点:
- 可移植
- 可以备份本地和远程MySQL服务器
缺点:
- 原始备份只能在服务器主机上执行
- 要求在备份期间MySQL服务器处于运行状态
- 逻辑备份通常比原始(二进制)备份慢
- MySQL服务器必须读取表并解释其内容,然后它必须将表内容转换为磁盘文件,或者将语句发送到客户机程序,由客户机程序将语句写出 - 从逻辑备份中恢复比从原始备份中恢复慢
- 恢复过程执行包含创建每个备份的表和行的单独CREATE和INSERT语句的脚本
- 被恢复表上的所有索引都必须重建 - 逻辑备份文件的大小可能会超过正在备份的数据库的大小
- 这些语句可能比它们所表示的数据占用更多的空间
- 但是,由于InnoDB将数据存储在数据页中,其中可能包含空闲空间,因此InnoDB数据文件在磁盘上占用的空间通常比数据所需的空间多得多
物理备份
- 通过复制数据文件创建
- 可以使用标准命令,例如tar、cp、cpio、rsync或copy
- 使用物理镜像或块设备联机进行磁盘复制
- 使用基于快照的文件归档 - 物理备份是数据库文件中比特位的精确表示
- 这些副本以与MySQL本身将它们存储在磁盘上的格式完全相同的格式保存数据库内容
- 因为它们是原始数据文件的精确副本,所以原始二进制备份的大小与原始数据文件相同 - 可以通过使用将要备份的数据文件与MySQL服务器分离开的技术来最大限度地减少对MySQL和应用程序的影响:
- 快照
- 复制
- DRBD或其他复制整个文件系统的方法
优点:
- 可以跨计算机体系结构进行恢复
- (原始备份)执行备份和恢复要比逻辑备份和恢复更快
缺点:
- 必须恢复到相同的存储引擎和MySQL版本
- 当从InnoDB表恢复原始MySQL备份时,它仍然是目标服务器上的InnoDB表 - 服务器在备份期间不得修改数据文件
- 如果复制实时数据文件,那么就要防止对这些文件的写入:
— 对于InnoDB:需要关闭MySQL服务器
— 对于MyISAM:锁定表以允许读取但不允许更改
联机磁盘拷贝
- 可以使用以下方法将数据直接备份到另一个磁盘:
- 复制或RAID镜像等过程
- 外部应用程序,例如DRBD
— 分布式复制块设备
— 启用群集计算机之间的低级别磁盘复制
优点:
- 实时(或接近实时)备份
- 一种在发生硬件故障时快速恢复数据的方法
缺点:
- 副本是实时(或接近实时)创建的,因此无法使用此技术从用户或应用程序错误导致的数据丢失中恢复
基于快照的备份
- 基于快照的备份使用MySQL外部的快照功能
- 基于快照的备份最适合执行自我恢复的事务引擎,例如InnoDB
- 创建数据的时间点副本
- 通常针对快照副本执行原始备份 - 提供文件系统的逻辑冻结版本,可以从中进行MySQL备份
- 冻结的文件系统不一定包含一致的数据库映像
- 当从这样的文件系统中恢复时,InnoDB必须执行自己的恢复以确保没有未完成的事务
优点:
- 大大减少数据库和应用程序不可用的时间
- 执行快照所需的时间不会随着数据库大小的增长而增加
- 备份窗口(从应用程序的角度来看)几乎为零
- 快照使用 “写入时复制” 的方法来确保它们几乎是即时的
- 快照处于活动状态时,性能开销很小
基于复制的备份
- MySQL支持单向异步复制,其中一台服务器作为主服务器,而其他一台或多台服务器作为从属服务器
- MySQL复制可用于备份:
- 主服务器 (master) 用于生产应用系统
- 从属服务器 (slave) 用于备份目的 - 从属服务器的备份可以是逻辑的,也可以是原始二进制的
- 基于异步复制技术:
- 从属服务器可能会相对于主服务器延迟
- 如果二进制日志在从属服务器读取之前未清除,则这是可以接受的情况
优点:
- 消除了对生产应用系统的影响
缺点:
- 更高的成本:必须有另一台服务器和存储器来存储数据库的副本
二进制日志备份
- 记录对数据的修改
优点:
- 通过还原自上次完全备份以来发生的事件,可最大程度地减少两次完全备份之间的影响
- 二进制日志备份包含随着时间的推移对数据所做的所有更改的记录
- 可以按顺序执行多个二进制日志备份
缺点:
- 必须依次还原自上次完整备份以来创建的所有连续的二进制日志
- 从系统故障中恢复可能很慢,具体取决于必须恢复的二进制日志的数量
增量备份
通过复制和刷新MySQL二进制日志创建(二进制日志可用于细粒度还原:可以识别导致损坏的事务,并在恢复过程中跳过它们)