数据库容灾技术
数据库容灾技术网上报考
(一)数据备份与恢复
数据备份是以容灾为目的，为防止故障导致的数据丢失，而将全部或者部分数据复制到其他存储介质的过程。备份过的数据往往通过压缩打包保存，提升存储效率。备份数据一般不能直接提供数据库服务，需要一套数据恢复操作流程进行备份逆操作，在现有数据库实例或基于空闲资源搭建新实例，覆盖原有数据，才能再次通过该数据库实例进行访问。所以数据备份也称为数据冷备。
1.数据备份
笔记本电脑发射wifi数据库的备份技术从备份机制可分为物理备份和逻辑备份两种。物理备份是针对数据库的数据文件进行备份的方式。物理备份往往是将数据库的数据文件连同备份时间窗口内的重做日志一同进行备份。备份完成后，备份程序会重新执行重做日志，保持数据文件中数据的一致性。由于物理备份主要备份内容是复制数据库数据文件，能最大程度利用IO，备份效率很高。逻辑备份是针对数据库的数据内容进行备份的方式。
2.数据恢复
全量备份是基于时间点的数据库镜像，而增量备份是将此时间点扩展到持续的时间窗口。通过全量备份和增量备份，数据库可以恢复备份覆盖的时间范围内任意时间点的数据状态。同时数据恢复也可指定恢复目标，将恢复范围限制为部分库表，可大幅降低恢复时间开销。
(二)数据同步与传输
按照监管要求，核心业务系统生产中心的数据库数据能实时同步传输到异地的灾备中心。下面以MySQL数据库场景为例，介绍几种不同的同步传输技术，供数据库容灾架构规划参考。
1.主从复制
MySQL主从复制6是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。
补水效果好的眼霜
党员的权利和义务是什么每一组主从复制的连接，都由三个独立的线程协作实现。在主库上为每一个连接到主库的从库创建一个二进制日志(以下简称“binlog”)输出线程。每一个发送给从库的SQL事件或者数据变更事件，都会基于binlog传输给从库。而每一个从库都会为同步创建一个I/O线程和一个SQL线程。I/O线程连接到主库并请求主库发送binlog事件到从库，读取到的binlog会更新到本地中继日志（以下简称“relay-log”）文件。而SQL线程读取到I/O线程写到relay-log的更新事件后，在数据库中进行执行，从而完成数据从主库到从库的同步。
2.半同步复制
半同步复制是MySQL 5.5版本引入的机制7。半同步复制出现前，虽然异步复制可以满足主从实例之间的数据同步要求，但如果主库崩溃，将从库提升为主库时，原来的主库上可能有一部分已经提交的数据还没有来得及被从库接收，主从不一致将导致切换后的新主库丢失这一部分数据。
半同步复制改进了事务提交的逻辑。客户端在主库上写入一个事务时，需要等待从库接收到主库相关的binlog数据，且主库接收到从库的应答之后，客户端才能收到事务成功提交的消息。
早期的半同步复制存在一些缺陷。主库在等待应答的过程中，存储引擎内部已经提交的事务，只是阻塞返回客户端消息而已，此时如果有其他会话对该会话事务修改数据进行查询会查询到数据。如果此时出现主库故障转移，非发起数据库提交的客户端可能会出现幻读。所以MySQL 5.7版本对半同步进行了优化，称为增强半同步复制。优化后一个事务在存储引擎内部提交之前，必须要先收到从库的应答确认，否则不进行事务的最后提交，从而解决上述提到的幻读问题。
3.组复制
MySQL在5.7版本正式推出组复制（MySQL Group Replication8，以下简称“MGR”）机制。MGR集由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点决议并通过才能得以提交。
引入组复制，主要是为了解决异步主从复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议实现了分布式架构下数据的最终一致性，提供了MySQL集的多主写入方案。
MGR技术与Oracle RAC类似，对集网络的要求非常高。网络延时和不稳定会严重影响MGR集的正常工作，所以多用在单数据中心的内网环境中，对于主备和多活容灾架构下异地同步的场景，存在一定的短板。智能手机省电方法
4.分组强同步
自制兔灯笼100种半同步复制机制保障了主库故障切换时事务数据能够在至少一个从库中持久化存储，保证切换过程不丢失最新数据。随着数据库集规模逐渐增大，同城和异地多机房灾备架构对同步的要求也愈发提高。当跨多机房部署的集出现大规模故障，例如机房故障或专线故障时，主库和完成接收binlog数据的从库节点可能同时出现故障。因此在半同步的基础上，出现了分组强同步机制。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。