【DG】DataGuard架构和部分概念整理

甚至熊熊

发布于 2021-04-22 17:25:06

2.1K0

发布于 2021-04-22 17:25:06

文章被收录于专栏：数据库学习笔记

本篇梳理DG的架构和一些概念知识，重新梳理的目的是加强理解，也方便复习，基于11gR2版本写的，不包含12c新特性。如果能帮助到新接触DG的朋友，那就再好不过。

一、DataGuard概述

这是一种保障数据安全的高可用架构，搭建与主数据库同步的备用数据库，提供Oracle数据库的容灾、数据保护、故障恢复等，实现数据库快速切换与灾难性恢复。

原理是日志文件从主库传输到备库，然后在备库上应用这些日志，从而使备库与主库保持同步
DG由一个primary数据库及一个或多个standby数据库组成，备库最多9个
主库：即被大部分应用访问的生产数据库，该库即可以使单实例数据库，也可以使RAC
备库：备库也支持单机或RAC，备库正常为只读状态

二、DataGuard分类

DG分为物理DG、逻辑DG

物理DG（生产环境使用多）：

物理DG应用的是主库的归档日志，物理DG无论从逻辑结构和物理结构都是和主库保持一致；
通过块拷贝方式同步，使用数据库recovery恢复功能来应用主库的更改；
通过接收并应用主库的 redo log 以介质恢复的方式(Redo Apply)实现同步

逻辑DG：

逻辑DG应用的是主库归档日志中提取的SQL语句，逻辑DG则只需保证逻辑结构一致；
通过接收 primary数据库的 redo log并转换成 sql语句，然后在 standby 数据库上执行 SQL 语句(SQL Apply)实现同步

三、日志传输

DataGuard数据同步过程分为三个阶段：日志传输、日志接收、日志应用。

本节讲解日志传输概念，这部分参数与上一篇搭建时设置主备库：log_archive_dest1,log_archive_dest2参数相关

主库在运行过程中会不断地产生redo日志，这些日志需要发送到备库，这个发送动作有两种传输方式：ARCH进程（传归档日志）、LGWR进程（传重做日志）

1.ARCH进程-传归档日志

主库：产生日志后通过LGWR进程写入在线重做日志，当满足相关条件后在线重做日志会进行切换，ARC0进程归档该日志至主库本地的归档目录（log_archive_dest_1配置），归档完成后，ARC1进程就会将归档日志传输到备库(log_archive_dest_2配置)

备库：备库RFS进程负责接收日志。 1）如果备库有standby重做日志，则把日志复制到standby重做日志，接着把standby重做日志归档至备库本地归档目录，最后应用归档日志； 2）如果没有配置standby重做日志，rfs进程接收日志后，直接把它放到备库的归档目录下，再应用该日志

Arch方式是Oracle默认的传输方式，这种方式只有在主库日志归档的时候才会发送日志到备库。如果发生主库宕机的情况，则online redo log中的数据就会丢失，要想避免数据丢失，就需要使用LGWR

2.LGWR进程-传重做日志

LGWR分为SYNC(同步)和ASYNC（异步）两种模式，12c 增加fast sync模式

ASYNC模式

主库：只要有新的重做日志产生，LGWR进程将触发LNSn（Log Network Server）进程把新生成的重做日志传输到备库（如果配置了3个备库，则有3个LNS进程）。 ASYNC是redo buffer保存到 online redo log后，LNSn才开始传输

备库： RFS进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用

SYNC模式（不建议，会影响生产）

主库：redo log buferr中只要有新的变更产生，LGWR进程将触发LNSn进程把新生成的重做日志传输到备库。SYNC是在redo buffer时，LNSn进程就开始传输，也就是说是从内存中就开始传输，并不写入redo log。

备库：rfs进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用。这种方式备库需要给主库一个回复，证明传输成功，如果有问题一直不回复就会导致主库的lgwr进程一直挂起，影响主库

使用LGWR进程存在的问题使用LGWR SYNC方法的可能问题在于，如果日志发送给备库过程失败，LGWR进程就会报错。也就是说主库的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，推荐使用LGWR ASYNC方式

3.FAL（Fetch archive log）进程

搭建DG的时候配置了fal_client和fal_server参数，它是取回归档日志进程，只有物理备库才有该进程。

FAL进程提供了一个client/server的机制，用来解决检测在主库产生的连续归档日志，而在备库接受的归档日志不连续的问题。该进程只有在需要的时候才会启动，而当工作完成后就关闭了，因此在正常情况下，该进程是无法看见的。

该进程是通过fal_client,fal_server参数进行交互的。

当主库的某些日志没有成功发送到备库，这时候发生了Archive Gap，缺失的这些日志就是Gap。

DG能够自动检测，解决归档裂缝，不需要dba的介入，但是这需要配置fal_client,fal_server这两个参数

fal_client通过网络向fal_server发送请求 fal_server通过网络向fal_client发送缺失的日志

除了自动解决，dba也可以手工解决，把日志拷贝到备库再注册：

--注册单个
alter database register logfile '日志文件名';

--注册多个
rman>catalog start with '/u01/arch/';

--正常注册完，就应该开始自动应用日志，如果没有的话先关闭实时应用再打开

四、日志接收及应用

日志接收：备库使用RFS（remote file server）进程接收日志，该进程接收到日志后，就把日志写到standby redo log（有这个就先写这个，没有这个就直接写archived log文件中）或者archived log文件中。

如果写到standby redo log文件中，则当主库发生日志切换时，也会触发备库上的standby redo log的日志切换，并把这个standby redo log 归档

日志应用：应用接收到的主库日志，实现主备库的数据同步。

物理备库使用MRP（managed recovery process）进程应用日志
逻辑备库使用LSP（logical standby process）进程应用日志

日志应用服务分为两种方式：

redo应用物理备库数据库专用，通过介质恢复的方式保持与primary数据库的同步。
sql应用逻辑备库数据库专用，核心是通过logminer分析出sql语句在standby端执行。

日志应用模式：

实时应用（real-time apply）：这种方式必须使用standby redo log，每当日志被写入standby redo log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换（switchover或者failover）的时间，因为切换时间主要用在剩余日志的恢复上。

--开启实时应用
alter database recover managed standby database using current logfile disconnect;

非实时应用：这种方式在主库发生日志切换，触发备库归档操作，归档完成后触发恢复

--开启非实时应用，切换归档才应用日志
alter database recover managed standby database disconnect;

五、DataGuard三种保护模式及转换

1.最大保护（maximum protection）

可以保证主库和备库的同步，任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库宕机。

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其redo不仅被写入到本地的online redo log，还要同时提交到standby数据库的standby redo log，并确认redo数据至少在一个standby数据库可用(如果有多个的话)，然后才会在primary数据库上提交。如果出现了什么故障导致standby数据库不可用的话， primary数据库会被shutdown。

使用这种方式要求主库必须配置 Standby RedoLog，而备库必须使用LGWR，SYNC，AFFIRM 方式归档到 Standby Database。

2.最大可用（Maximum availability）

保证主库和备库的同步，与上面的区别是当网络或备库不可用时，主库仍可以继续使用。

这种模式和"最大保护"基本上差不多。正常情况下，主备库之间是同步的。当网络或者备库出现问题时，不会影响到主库的宕机，主库会自动转换库"最大性能"模式，等待备库可用时，将归档传输到备库做恢复。

可以把这种模式理解为"最大保护"和"最大性能"两种模式的中间体。这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障redo数据至少在一个standby数据库可用，不过与之不同的是，如果出现故障导致无法同时写入standby数据库redo log， primary数据库并不会shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，它又会再自动转换成最高可用性模式。

这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求备库必须配置 Standby RedoLog，而主库必须使用 LGWR，SYNC，AFFIRM 方式归档到备库.

3.最大性能（maximum performan）

缺省模式，主库和备库是异步的。这种模式可能在主库出现损坏时，丢失一部分数据。当时这种模式对主库负荷最小，因此具有最好的性能。

这种模式保证主库性能最大化，主备库之间数据是异步传输的。即主库日志归档以后才会传输到备用库，在备库上使用归档日志文件做恢复操作。这种模式提供在不影响主库性能前提下最高级别的数据保护策略。事务可以随时提交，当前主库的redo数据也需要至少写入一个standby数据库，不过这种写入可以是不同步的。这种方式可以使用 LGWR ASYNC 或者 ARCH 进程实现，备库也不要求使用 Standby RedoLog。

4.模式转换

--主备库都要执行
--转换为最高可用，log_archive_dest_2需要配置LGWR SYNC AFFIRM
alter database set standby database to maximize availability;

--转换为最大性能，log_archive_dest_2需要配置LGWR ASYNC
alter database set standby database to maximize performance;

--转换为最大保护，log_archive_dest_2需要配置LGWR SYNC AFFIRM
alter database set standby database to maximize protection;

注意：备库shutdown再启动的话，open_mode又变回read only 需要再次执行开启同步