DM数据守护（Data Watch）——实时主备

引用

DM数据守护的详细介绍可参考下文

云适配中心 - 数据守护与读写分离集群
https://eco.dameng.com/docs/zh-cn/pm/data-watch-overview.html

前言

单库有很多局限性，如果整个库没了怎么办？（火灾、地震）性能受限于硬件怎么办？（若目前单台计算机最多能有526G内存，那么单库能使用的内存上限便是526G）

以上这些问题可以通过部署多个库解决，一个人搞不定就多喊几个嘛。但人多就会出现协调的问题，如何做好协调的工作呢？你干什么？我干什么？等等……

为了保证数据库的安全，为了在发生故障时能尽早恢复，可以多准备一个数据库，东西有两份，这份坏了就用另外一份。

数据库有多个时，应用该如何写入呢？是应用同时往多个数据库发送指令，与它们交互？还是只把"写操作"发送给"主库"，把"读操作"发送给"备库"？如何确保多个库数据同步？这需要一个东西来"守护"，在DM，它应该是DM数据守护（Data Watch）

DM数据守护（Data Watch）是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。

• 高可用
  对于一个TB级的库，且部署了主备（1主1备，主库在深圳，备库在上海），在发生意外时（主库连机带库被台风吹跑了），只需花几秒钟的时间，做个主备切换，让应用把指令都发送给备库，让备库接管主库的活，问题便解决了。要是通过备份恢复的方法，TB级的数据，可以试试需要多长时间…

DM数据守护有三大方案

• 实时主备
• MPP主备
• 读写分离主备

这些方案不光能解决安全问题，还能解决性能问题。（多余的备库总不可能让它闲着嘛，让备库接手一些主库的活，性能不就上来了嘛）

基本概念（实时主备）

实时主备 = 1主库 + 1（或多个）备库
其中，备库配置了实时（REALTIME）归档

主备分工
主库 - 提供完整的数据库功能
备库 - 提供只读服务

实时归档介绍

归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM数据库的归档可以分为5类，此处重点关注实时归档和本地归档

实时归档

与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的Redo日志通过MAL系统传递到备库，实时归档是实时主备和MPP主备的实现基础。
实时归档只在主库生效，一个主库可以配置1~8个实时备库。

本地归档

redo日志本地归档，就是将redo日志写入到本地归档日志文件的过程

本地归档是个"动作"，其产物是"本地归档日志文件"，这个归档日志由于保存在本地（而不是发送到其他机器上），故称为"本地"（与之相对的就是"远程"）

Normal/Primary库在Redo日志写入联机Redo日志文件后，将对应的RLOG_PKG由专门的归档线程写入本地归档日志文件中

联机Redo日志和本地归档日志，都是读取内存中的redo日志的吧？即这种情况下，日志flush线程和日志归档线程，都是读取内存中的redo日志？

redo记录（RREC）对应一个修改物理数据页的动作
物理RREC记录的是数据页的变化情况，内容包括：
操作类型
修改数据页地址
页内偏移
数据页上的修改内容

Redo日志包（RLOG_PKG）是DM数据库批量保存物理事务产生的Redo日志的数据单元

问题：
物理事务和逻辑事务的差异？一个具体到数据页的操作？
物理事务、redo日志包概念不懂
物理事务、redo日志包、redo记录之间的关联是什么？
为什么传输的是RLOG_PKG?

Standby库收到主库产生的Redo日志后，直接进行本地归档，写入本地归档日志文件中，同时启动Redo日志重演

注意：
备库接收到的redo日志，不需要写入到备库的联机重做日志中，而是直接写到备库的本地归档中，同时通过日志apply线程（重做日志）。备库重做日志时会产生备库的联机重做日志。

备库

参数文件对应的几个系统
dm.ini 数据库实例
dmarch.ini 归档系统，记录数据库的更改
dmmal.ini 通信系统，完成主备通信工作
dmwatcher.ini 完成了啥？？

主备同步流程图

根据文档的描述绘制的流程图，可能有误，请批判性的看

部署（实时主备 - 1主1备）