MySQL学习笔记
DM 数据库默认包含两个联机 Redo 日志文件（如 DAMENG01.log、DAMENG02.log）， 系统内部分别称为 0 号文件、1 号文件。RLOG_PKG 顺序写入联机 Redo 日志文件中，当一 个日志文件写满后，自动切换到另一个文件。其中 0 号文件是 Redo 日志主文件，在日志主 文件头中保存了诸如 CKPT_LSN，CKPT_FILE，CKPT_OFFSET，FILE_LSN 等信息。系 统故障重启时，从[CKPT_FILE, CKPT_OFFSET]位置开始读取 Redo 日志，解析 RREC 记录，并重新修改对应数据页内容，确保将数据恢复到系统故障前状态。 随着检查点（Checkpoint）的推进，对应产生 Redo 日志的数据页从数据缓冲区（Data Buffer）写入磁盘后，联机 Redo 日志文件可以覆盖重用、循环使用，确保 Redo 日志文 件不会随着日志量的增加而增长。
！！！！！！！！！任何数据页从 Buffer 缓冲区写入磁盘之前，必须确保修改数据页产生的 Redo 日志已经写入到联机 Redo 日志文件中。
在联机日志文件中，可以覆盖写入 Redo 日志的文件长度为可用日志空间；不能被覆盖， 系统故障重启需要重做部分，为有效 Redo 日志，有效 Redo 日志的 LSN 取值范围是 (CKPT_LSN,FILE_LSN]；已经被发起日志刷盘请求，但还没有真正写入联机 Redo 日志 文件的区间为(FILE_LSN,FLUSH_LSN]，称为待写入日志空间。
归档介绍
归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM 数据库的 归档可以分为 5 类：本地归档、远程归档、实时归档、即时归档和异步归档。其中，本地 归档和远程归档日志的内容与写入时机与数据库模式相关；主库 Redo 日志写入联机日志文 件后，再进行本地归档和远程归档；备库收到主库产生的 Redo 日志后，直接进行本地归档 和远程归档，同时启动 Redo 日志重演。
本地归档
Redo 日志本地归档（Local），就是将 Redo 日志写入到本地归档日志文件的过程。 配置本地归档情况下，Normal/Primary 模式库在 Redo 日志写入联机 Redo 日志文件后， 将对应的 RLOG_PKG 由专门的归档线程写入本地归档日志文件中。Stanby 模式库收到主 库产生的 Redo 日志后，直接进行本地归档，写入本地归档日志文件中，同时启动 Redo 日 志重演。
Normal/Primary 模式库归档日志文件保存的是当前节点产生的 Redo 日志，归档日 志文件内容与联机日志内容保持一致。Standby 模式库重演日志重新产生的 Redo 日志只 写入联机日志文件，归档日志文件保存主库产生的 Redo 日志，因此备库联机日志文件内容 和归档日志文件内容是不完全一致的。采用这种归档实现方式后，可以确保数据守护系统中 所有节点的归档日志文件内容是完全一致的。
与联机 Redo 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中 的 Redo 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会 自动删除最早生成的归档 Redo 日志文件，腾出空间。本地归档文件在配置的归档目录下生 成并保存，如果磁盘空间不足，且没有配置归档日志空间上限（或者配置的上限超过实际空 间），系统将自动挂起，直到用户主动释放出足够的空间后继续运行。
DM 提供了按指定的时间或指定的 LSN 删除归档日志的系统函数，分别为 SF_ARCHIVELOG_DELETE_BEFORE_TIME 和 SF_ARCHIVELOG_DELETE_BEFORE_LSN，但用户需要谨慎使用。例如，在守护系统中， 如果备库故障了，主库继续服务，主库的日志在继续增长。此时如果删除尚未同步到备库的 主库归档日志，那么备库重启之后，会由于备库收到的日志缺失导致主备库无法正常同步数据
！！！！！！！！！为了最大限度地保护数据，当磁盘空间不足导致归档写入失败时，系统会挂 起等待，直到用户释放出足够的磁盘空间。当磁盘损坏导致归档日志写入失 败时，系统会强制 HALT。
远程归档
DMDSC 集群数据库实例除了将 Redo 日志归档在本地，还可以归档到 DMDSC 集群的其 他实例，这种将归档日志发送到远程实例保存的归档方式，我们称为远程归档。配置远程归 档后，DMDSC 集群中每个实例完整保存了集群所有实例产生的 Redo 日志，任意实例都可 以像访问本地归档一样，访问所有实例产生的归档日志。
远程归档的使用场景：
1.执行数据库恢复时，恢复工具（如 DMRMAN）所在节点需要访问其他各节点归档日志。
2.DMDSC 守护系统中进行主、备库异步归档日志的同步或备库恢复时DMDSC 控制节 点作为发送端，需要访问其他从节点的归档日志。
归档文件
备库归档机制调整后，备库归档日志文件写入的并不是自己重演生成的 Redo 日志，而 是直接将主库产生的 Redo 日志写入到本地归档日志文件中。为了区分生成 Redo 日志和写 入 Redo 日志的库，归档日志文件头增加了几个 MAGIC 字段：
PMNT_MAGIC 永久魔数，用来唯一标识数据库，初始化数据库时生成并保持不 变（DDL_CLONE 还原库除外），数据守护集群中所有主备库的 PMNT_MAGIC 是相同的。只 有 DDL_CLONE 还原库的 PMNT_MAGIC 会发生改变，当一个库使用 DDL_CLONE 备份集还 原并恢复之后，在执行 RECOVER DATABASE „„ UPDATE DB_MAGIC 时，PMNT_MAGIC 会发生改变。
DB_MAGIC 数据库魔数，数据库初始化时生成，数据库还原后重新生成新的 DB_MAGIC，数据守护集群中所有主备库的 DB_MAGIC 是不同的。归档日志文件使用 DB_MAGIC 标识写入 Redo 日志的库。
SRC_DB_MAGIC 源库魔数，产生 Redo 日志数据库的 DB_MAGIC 值；主库归档日志文件中 SRC_DB_MAGIC 与 DB_MAGIC 相同；备库归档日志文件中 SRC_DB_MAGIC 与 主库的 DB_MAGCI 值相同。
Primary/Normal 模式库本地归档日志文件的命名方式调整为：
ARCH_NAME_DB_MAGIC[SEQNO]_日期时间.log，其中 ARCH_NAME 是在 dmarch.ini 中配置的 LOCAL/REMOTE 归档名称，DB_MAGIC 是生成日志的数据库魔数，SEQNO 代表 DSC 节点号，日期时间是归档日志文件的创建时间。
Standby 模式库（备库）生成的归档日志文件的命名方式调整为：STANDBY_ARCHIVE_DB_MAGIC[SEQNO]_日期时间.log
其中 STANDBY_ARCHIVE 表示备库生成的归档日志文件，DB_MAGIC 是生成日志的数 据库（主库）魔数，SEQNO 代表主库对应的 DSC 节点号，日期时间是归档日志文件的创建 时间。
！！！！！！由于 STANDBY_ARCHIVE 用于表示备库生成的归档日志，不允许将归档名称 配置为 STANDBY_ARCHIVE。
实时归档
与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的 Redo 日志通过 MAL 系统传递到备库，实时归档是实时主备和 MPP 主备的实现基础。实时 归档只在主库生效，一个主库可以配置 1~8 个实时备库。
实时归档的执行流程是，主库Redo日志RLOG_PKG写入联机日志文件前，将redo日志发送到备库，备库收到redo日志RLOG_PKG后标记为keep_pkg，将源keep_pkg加入日志重演任务系统，并马上响应主库，不需要等待redo日志重演结束户在相应主库。主库收到备库的响应消息，确认备库已经收到redo日志后，再讲redo日志写入联机日志文件中。
即时归档
即时归档（Timely）在主库将 Redo 日志写入联机日志文件后，通过 MAL 系统将 Redo 日志发送到备库。即时归档与实时归档的主要区别是 Redo 日志的发送时机不同。一个主库 可以配置 1~8 个即时备库。
根据备库重演 Redo 日志和响应主库时机的不同，即时归档分为两种模式：事务一致模 式和高性能模式。即时归档模式根据配置文件 dmarch.ini 中的 ARCH_WAIT_APPLY 配置 项（默认值为 1）来确定，1 表示事务一致模式，0 表示高性能模式。
事务一致模式 主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发 送的 Redo 日志，并重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交 请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行， 查询结果都满足 READ COMMIT 隔离级要求。
高性能模式 与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应 主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下 延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。
事务一致模式下，主备库之间严格维护事务一致性，但主库要等备库 Redo 日志重演完 成后，再响应用户的提交请求，事务提交时间会变长，存在一定的性能损失。高性能模式则 通过牺牲事务一致性获得更高的性能和提升系统的吞吐量。用户应该根据实际情况，选择合 适的即时归档模式。
异步归档
异步归档（Async）由主、备库上配置的定时器触发，根据异步备库的 KEEP LSN 信息，扫描本地归档目录获取 Redo 日志，并通过 MAL 系统将 Redo 日志发送到异步备库。 异步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。
每个 Primary 或 Standby 模式的数据库最多可以配置 8 个异步备库，Normal 模式 下配置的异步备库会自动失效。异步备库可以级联配置，异步备库本身也可以作为源库配置 异步备库。
！！！！！！任意一个备库的实时归档/即时归档失败（即使其他备库归档成功了），主库 都会切换为 Suspend 状态。
归档状态
本地归档、实时归档和即时归档均包含两种状态：Valid和Invalid。异步归档只有一种归档状态：Valid。
Valid：归档有效，正常执行各种数据库归档操作。
Invalid：归档无效，主数据库不发送联机redo日志到备数据库。
在不同的归档类型中，归档状态转换时机不同
1、主备库启动后，主库到所有备库的归档默认为valid状态，守护进程Open主库前，根据主备库日志同步情况，将数据不一致备库的归档修改为Invalid状态。
2、备库故障恢复，从主库同步历史数据后，守护进程将主库修改为suspend状态，并将主库到备库的归档状态从invalid修改为valid，当守护进程再次open主库后，主备库数据重新恢复为一致状态。
3、主库发送日志到实时备库失败挂起，守护进程处理failover过程中，将主库到备库归档状态修改为invalid。
4、主库发送即时归档失败后，直接将主库到备库的归档改为invalid状态。
5、异步归档始终保持valid状态，一旦归档失败马上返回，等待下一次触发在继续发送。
！！！！！！！！实时归档、即时归档只对 Primary 模式的主库有效，备库上配置的实时归档、 即时归档状态没有实际意义，始终保持 Valid 状态。
内容来自官方文档！