【云原生进阶之数据库技术】第二章-Oracle-使用-3.3.2-Oracle Data Guard原理

2 DataGuard原理解析

2.1 数据同步原理

DG 的核心组件包括：

• 主数据库：负责处理所有的写操作，并将这些操作记录在重做日志（Redo Logs）中。
• 备用数据库：可以是物理备用数据库（Physical Standby）或逻辑备用数据库（Logical Standby）。物理备用数据库通常是只读的，而逻辑备用数据库可以进行读写操作。
• 归档日志：主数据库产生的重做日志会被发送到备用数据库，以便在必要时重新应用到备用数据库上。

DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库，然后在备用数据库上应用这些重做数据，以确保数据的一致性。

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

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

2.1.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.1.2 LGWR进程-传重做日志

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

2.1.2.1 ASYNC模式

• 主库：只要有新的重做日志产生，LGWR进程将触发LNSn（Log Network Server）进程把新生成的重做日志传输到备库（如果配置了3个备库，则有3个LNS进程）。ASYNC是redo buffer保存到 online redo log后，LNSn才开始传输。
• 备库：RFS进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用。

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

• 主库：redo log buferr中只要有新的变更产生，LGWR进程将触发LNSn进程把新生成的重做日志传输到备库。SYNC是在redo buffer时，LNSn进程就开始传输，也就是说是从内存中就开始传输，并不写入redo log。
• 备库：rfs进程负责接收日志。接收到日志后将其写入standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等standby重做日志归档后再应用。这种方式备库需要给主库一个回复，证明传输成功，如果有问题一直不回复就会导致主库的lgwr进程一直挂起，影响主库。

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

2.1.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/';

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

2.2 日志接收及应用

日志接收：备库使用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;

2.3 DataGuard三种保护模式及转换

2.3.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.3.2 最大可用（Maximum availability）

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

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

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

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

2.3.3 最大性能（maximum performan）

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

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

2.3.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 需要再次执行开启同步

2.4 Switchover和Failover的区别

在Oracle的DG中，Switchover和Failover的区别有哪些？

一个DG环境中只有两种角色：Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换，切换也分两种：Switchover和Failover，关于角色切换需要注意以下几点：

①　Switchover是指主库转换成备库，然后将原备库转换成新主库；而Failover是指将备库转换成主库。

②　使用场合不同：Switchover用于有准备的、计划之中的切换，通常是系统升级、数据迁移等常态任务；Failover用于意料之外的突发情况，例如异常断电、自然灾难等等。

③　数据丢失程度不同：Switchover不会丢失数据，Failover通常意味着有部分数据丢失。

④　善后处理的不同：Switchover之后DG环境不会被破坏，仍然有Primary、Standby两种角色的系统存在，但是Failover之后，DG环境就会被破坏，一般情况下需要重建。但是，若主库或备库开启了闪回功能，则都可以通过闪回数据库功能恢复DG环境。例如，PROD1为主库，SBDB1为备库；若PROD1意外宕机，则SBDB1执行Failover操作变为主库；此时若想恢复DG环境，则有3种处理办法：

a. 将PROD1利用闪回数据库功能闪回到SBDB1变为主库的SCN时间点，然后将PROD1转换为备库，最后利用switchover转换为最初的环境。在这种情况下，PROD1需要开启闪回。

b. 将SBDB1利用闪回数据库功能闪回到SBDB1变为主库的SCN时间点，此时SBDB1仍然是主库的角色，然后将SBDB1转换为备库。在这种情况下，SBDB1需要开启闪回，而且会丢失部分数据。

c. 利用RMAN重新搭建DG环境。

下面给出角色切换过程中常用的一些SQL语句。

(1) 物理DG在执行Switchover切换时的主要SQL语句为：

--在主库操作
alter database commit to switchover to physical standby with session shutdown;
startup force mount;
--在备库操作
select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name, flashback_on  from v$database;
alter database commit to switchover to primary with session shutdown;
alter database open;

物理DG在执行Failover切换的主要SQL语句为：

--在备库操作
alter database recover managed standby database finish force;
alter database commit to switchover to primary with session shutdown;
alter database open;

物理DG在执行Failover后，在原备库端查看V$DATABASE视图的STANDBY_BECAME_PRIMARY_SCN列，可以看到这个库成为primary的具体时间，如下所示：

--新主库
SELECT STANDBY_BECAME_PRIMARY_SCN FROM V$DATABASE;
--原主库或新主库
startup mount
flashback database to scn 1326995;

在原主库或新主库执行闪回数据库后，切换主库为备库的SQL语句为：

alter database convert to physical standby;
startup force;
alter database recover managed standby database using current logfile disconnect from session;

(2) 逻辑DG在执行Switchover切换时的主要SQL语句为：

select switchover_status,database_role,open_mode from gv$database;
--在主库操作
alter database prepare to switchover to logical standby;
select switchover_status from v$database;--PREPARING SWITCHOVER
--在备库操作
alter database prepare to switchover to primary;
select switchover_status from v$database;--PREPARING SWITCHOVER
--在主库操作
select switchover_status from v$database; --结果应该为：TO LOGICAL STANDBY，否则需要取消转换ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
alter database commit to switchover to logical standby; --开始转换主库为逻辑备库
--在备库操作
select switchover_status from v$database;--状态应该为为TO PRIMARY，若不是该状态，则不能转换为主库，可能出现ORA-16109错误，那么就得回退刚刚的操作
alter database commit to switchover to primary;--开始转换逻辑备库为主库
--新逻辑备库执行
alter database start logical standby apply immediate;--启动新逻辑standby的SQL应用

逻辑DG在执行Failover切换时的主要SQL语句为：

--在备库操作 
alter database activate logical standby database finish apply;

该语句主要是停止待转换的逻辑standby中RFS进程，并应用完当前所有已接收但并未应用的redo数据，然后停止SQL应用，将数据库转换成primary角色。在切换完成后，原主备库关系遭到破坏，已经不能再使用简单的命令修复了。

需要注意的是，要在primary和逻辑standby之间切换角色，一般是从操作primary开始。如果primary或逻辑standby是RAC架构，那么只保留一个实例启动，其它实例全部shutdown，等角色转换操作完成之后再启动其它实例，角色转换的操作会自动传播到这些实例上，并不需要再对这些实例单独做处理。

& 说明：

有关具体的Switchover和Failover切换的过程可以参考BLOG：

①　物理DG的Switchover切换：http://blog.itpub.net/26736162/viewspace-1753111/

②　物理DG的Failover切换：http://blog.itpub.net/26736162/viewspace-1753130/

③　利用闪回数据库（flashback）修复Failover后的DG环境：http://blog.itpub.net/26736162/viewspace-2146883/

④　Switchover和Failover的区别：http://blog.itpub.net/26736162/viewspace-2141207/