备份与恢复
备份与恢复
- 逻辑备份（记住用户做了哪些操作，sql语句全部记录下来）、物理备份（把数据文件全部拷贝）
- 全量备份、增量备份（所有数据全部备份还是记录从上一个时刻到现在增量到付）
二、物理、逻辑备份[](https://web-arch.ayaka.space/docs/review/数据库部分/第17章 MySQL备份和恢复#二物理逻辑备份)
- 逻辑备份：先要备份表的结构，然后记录所有的SQL语句的操作，比如所有的增删改查的操作。当一个表崩溃的时候，在另外一个表里面按照顺序执行一遍这些操作，就可以实现备份的恢复。
- 物理备份：拷贝整个表格，索引文件、数据文件、元数据文件，当出现故障的时候，把所有的文件拷贝回去就好了。
逻辑备份优点(便携性(迁移难度), 灵活性(数据粒度), 可读性：
- 因为备份的是SQL语句，所以换一个机器也能执行，换一个数据库系统也能执行。比如从Mysql导出的SQL脚本备份，换到MongoDB也一般可以执行，兼容性好。
缺点：速度慢, 一致性差, 占用空间大
- 空间占用比较大，SQL的脚本文件因为包含了SQL的关键字，所以比只存储数据的表格文件是要大的，牺牲了一部分的空间，在数据量比较大的时候，导出的SQL备份脚本文件会比较浪费空间。
- SQL文件如果泄露了的话，数据库就泄露了，安全性差
物理备份优点：速度, 简单性, 占用空间小, 配置和日志也被一同备份
- 适合大的数据库
- 恢复速度快，出现问题的时候直接把文件拷贝回去就好了，方便快捷恢复便利。
- 相对来说安全一些
物理备份的缺点: 依赖性, 兼容性
- 比如从Mysql备份的内容就只能用于Mysql，不能像逻辑备份一样导入到别的类型的数据库。兼容性差
[在线备份和离线备份](https://web-arch.ayaka.space/docs/review/数据库部分/第17章 MySQL备份和恢复#三在线备份和离线备份)
- 在线备份是系统在运行的时候备份，缺点管理很复杂，涉及到加锁，优点是用户还可以使用
- 离线备份是数据库暂停服务，然后专门备份。缺点是用户不能使用了。
[快照](https://web-arch.ayaka.space/docs/review/数据库部分/第17章 MySQL备份和恢复#四快照)
增量式备份的一种，一些文件系统实现允许拍摄“快照”。它们在给定时间点提供文件系统的逻辑拷贝，而不需要整个文件系统的物理拷贝。（例如，实现可以使用copy-on-write技术，以便只复制快照时间后修改的文件系统的部分。）
MySQL本身不提供获取文件系统快照的功能。它可以通过Veritas、LVM或ZFS等第三方解决方案获得。
实际上，由于copy-on-write技术（在备份过程中只复制被修改的页，从而大大提高了备份效率），假如在某个时间我们做了一个全量备份，那么之后由于数据库的增删改，然后出现了文件数据的变化，文件相对于旧有的文件会有一部分变化，这部分 变化就叫做快照！所以快照是增量式备份。
优点：
- 速度快：由于使用了写时复制技术，备份过程中只复制被修改的页，因此备份速度较快。
- 对生产环境影响小：由于是文件系统级别的备份，不会对正在运行的数据库产生影响。
- 恢复速度快：由于备份是基于文件系统的，恢复速度也较快。
缺点：
- 依赖文件系统：快照备份依赖于特定的文件系统（如ZFS、NFS等），不是所有环境都适用。
- 数据一致性：在备份过程中，如果数据库有写操作，可能会导致数据不一致的情况。
- 存储空间需求：由于使用了写时复制技术，需要额外的存储空间来保存备份数据。
[恢复方法](https://web-arch.ayaka.space/docs/review/数据库部分/第17章 MySQL备份和恢复#五恢复方法)
假设我们的备份策略是每个周日下午一点进行一次全量备份，也就是把数据库里面的所有数据全备份一次。那么，在两次全量备份之间的时间节点 上，数据库每次执行写入操作的时候，都会对bin-log文件进行操作，写入增量备份。也就是记录用户对数据库的所有的操作变更。现在加入在周三的中午，数据库主机突然崩了，那么我们首先要恢复到最近一次做的全量备份：好了，现在就已经恢复到最近一次全量备份的状态里，然后要从上次全量备份到崩溃期间的binlog文件全部读取出来，然后恢复。如果每次磁盘坏死或者磁盘错误，基本上就能恢复到原来的状态。但是如果有一个binlog文件崩溃了或者寄了，那就可能恢复不到周三崩溃的时候的状态了，可能只能恢复到周二的下午或者某个稍微更早的时间点。
验证是否成功导入:
验证时先验证表的元信息SHOW TABLES，再验证约束SHOW INDEX，再对数据进行验证，例如COUNT, 抽查，使用默克尔树进行hash一致性校验等等