Far Sync Standby 能不能支持 max protection

2023-11-30 21:30

本文主要是介绍Far Sync Standby 能不能支持 max protection,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

GOAL

 This Note explains the new Standby Type Far Sync Standby

SOLUTION

Far Sync Standby Database:

A Far Sync Standby Database is a cascading Standby Database which acts as a Redo Log Repository for a Terminal Database. It does not contain any datafiles. Only Log Transport Services are active on a Far Sync Standby Database. The Advantage of a Far Sync Standby Database is that it can be a local ArchiveLog Repository for the Primary Database acting in Maximum Availability Mode where the Physical or Logical Standby Database can be on a far remote Site. 

Creating a Far Sync Standby Instance 

You can prepare your Environment for a Far Sync Instance the same Way like for a Physical Standby Database, see

Note 1475344.1 Creating a Physical Standby Database on Oracle 11.2.0.x

-> Preparing the Environment and Standby Instance

for an Example.

Instead of a Physical Standby Controlfile we are creating a Far Sync Standby Controlfile from the Primary Database and use this Controlfile to mount the Far Sync Instance:

SQL> alter database create far sync instance controlfile as ‘<File Specification>’;

 You can then setup Log Transport Services to the Cascaded Standby just like for normal Cascaded Standby Databases. 

Data Guard Broker and Far Sync Standby Database 

The Data Guard Broker also supports Far Sync Standby Databases and Cascaded Standby Databases. You can add a Far Sync Standby to your Data Guard Broker Configuration using

DGMGRL> add far_sync <Name> as connect identifier is <Connect Identifier>;

 Then set the Data Guard Broker Property ‘RedoRoutes’ for the Databases accordingly. You can find an Explanation about ‘RedoRoutes’ in

Note 1542969.1 Cascaded Standby Databases in Oracle 12c

Technical Briefs:

Oracle Active Data Guard Far Sync Zero Data Loss at Any Distance
https://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf

REFERENCES

NOTE:1475344.1 - Creating a Physical Standby Database
NOTE:1578787.1 - 12c Data guard Switchover Best Practices using SQLPLUS
NOTE:1582837.1 - 12c Dataguard Switchover Best Practices using DGMGRL(Dataguard Broker Command Prompt)
NOTE:1542969.1 - Cascaded Standby Databases in Oracle 12c

PURPOSE

 This Documents explains the Enhancements for Cascaded Standby Databases in Oracle 12c.

DETAILS

There are new Possibilities for cascading Standby Databases in Oracle 12c. The main Differents between Oracle 12c and the previous Releases are:

  1. Real-Time Cascading
  2. Far Sync Standby Database
  3. Data Guard Broker now supports cascaded Standby Database

However, you can still only cascade a Standby Database from a Physical Standby Database. It is not supported to cascade a Standby Database from a Logical Standby Database.

Real-Time Cascading

It is now possible to forward Redo in Real-Time Mode from the first to the cascaded Standby Database. So the Redo Record is forwarded to the cascaded Standby Database once written into a Standby RedoLog of the first Standby Database.

Non Real-Time Cascading means that the whole Log Sequence is transferred to the terminal Standby Database(s) after a Log Switch on the Primary Database.

Prerequisites

  • First (Cascading) Standby must be a Physical or Far Sync Standby Database
  • Standby RedoLogs must be in Place and used at least on the Cascading Standby Database
  • Active Data Guard Option must be licensed
  • Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases

Setup

First of all setup a Data Guard Environment as usual to the cascading Standby Database. The Log Transport Method should be ‘SYNC’ and Standby RedoLogs must be configured on the cascading Standby Database. Once you created the cascaded Standby Database you can now setup the cascading Log Transport Services. Here are some Hints for correct Setup:

  • Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases
  • Setup log_archive_dest_n on the cascading Standby Database to serve the cascaded (terminal) Standby Databases using the Attribute ‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’
  • You can toggle between Real-Time and Non Real-Time Cascading using the Log Transport Method.

ASYNC = Real-Time Cascading

SYNC = Non Real-Time Cascading

  • You can only use log_archive_dest_1 until log_archive_dest_10 for Non Real-Time Cascading Destinations where all log_archive_dest_n’s can be used for Real-Time Cascading on the Cascading Standby Database
  • The Cascading Standby Standby can be in any Protection Mode
  • A Cascading Standby Database can serve one or multiple terminal Standby Databases
  • FAL_SERVER on the cascading Standby Database should be set to the Primary or any other Standby Database served by the Primary Database directly
  • FAL_SERVER on the terminal Standby Database should be set to the cascading Standby Database or the Primary Database

Far Sync Standby Database

A Far Sync Standby Database is a cascading Standby Database which acts as a Redo Log Repository for a Terminal Database. It does not contain any Datafiles. Only Log Transport Services are active on a Far Sync Standby Database. The Advantage of a Far Sync Standby Database is that it can be a local ArchiveLog Repository for the Primary Database acting in Maximum Protection Mode where the Physical or Logical Standby Database can be on a far remote Site. See

Note 1565071.1: Data Guard 12c New Feature: Far Sync Standby

for further Details and Setup of a Far Sync Standby Database.

Data Guard Broker and Cascaded Standby Database

There is a new Data Guard Broker Property called ‘RedoRoutes’ used to build and implement a cascaded Data Guard Broker Configuration. It has the following Format:

RedoRoutes = ‘(<Redo Source> : <Redo Destination>)’

Redo Source: This is the Source the Redo is coming from. It can be a db_unique_name or the ‘LOCAL’-Keyword which is an Alias for the local Database Name (Cannot be used for a Far Sync Standby Database)

Redo Destination: This is the Destination where the Redo is shipped to from this Database. It can be one or more (comma separated) db_unique_name’s or the ‘ALL’-Keyword which is an Alias for all possible Destinations inside the Data Guard Broker Configuration. Optional you can also specify the Transport Method to be used to the Destination. This can be

  • SYNC:                   corresponds to log_archive_dest_n Attributes ‘SYNC AFFIRM’ or Non Real Time Cascade
  • ASYNC:                corresponds to log_archive_dest_n Attribute ‘ASYNC’ or Real Time Cascade
  • FASTSYNC :        corresponds to log_archive_dest_n Attributes ‘SYNC NOAFFIRM’

Example:

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the
Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual
environments, actual persons, living or dead, is purely coincidental and not intended in any manner.

For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:

Primary Database:                               prim
Cascading Standby Database:               local_stdby
Cascaded (terminal) Standby Database: remote_stdby

We want to serve the local Standby Database with ‘SYNC NOAFFIRM’ and the remote Standby Database in Real-Time Cascade Mode. So the setting would be:

Primary Database (prim)

RedoRoutes = ‘(LOCAL : local_stdby FASTSYNC)’

 -> So the Primary Database only ships Redo to the local Standby Database, but has Archive Destination to the remote Standby Database

Local Standby Database (local_stdby)

RedoRoutes = ‘(prim : remote_stdby ASYNC)’

 -> Here we configure that the Redo coming from ‘prim’ is forwarded in Real-Time Cascade (ASYNC) to the remote Standby Database

---------------far sync 配置

PURPOSE

 Use of the terminal standby as an alternate destination in a Far Sync configuration requires accepting that, provided the terminal standby database is not within acceptable sync network range, the configuration will run in asynchronous mode during the entire period required to resolve the Far Sync instance outage.  The advantage of this approach is that it requires no additional hardware or software to deploy or manage.  Applications that can tolerate increased data loss potential during a Far Sync instance outage and where low cost is the main consideration may be best served by configuring the terminal standby as an alternate location using ASYNC redo transport.

SCOPE

APPLIES TO:

Oracle Database versions 12.1.0.1 and 12.1.0.2

Active Data Guard Far Sync 

Data Guard Broker

Data Guard Role Transitions

DETAILS

Using the terminal standby database as an alternate of a far sync instance can result in the following errors when attempting a role transition using Oracle Data Guard Broker.

DGMGRL> switchover to standbyDB;
Performing switchover NOW, please wait...
Error: ORA-16778: redo transport error for one or more databases

Failed.
Unable to switchover, primary database is still "primaryDB"

DGMGRL> failover to standbyDB;
Performing failover NOW, please wait...
Error: ORA-16600: not connected to target standby database for failover

Failed.
Unable to failover

Here is an example of an affected configuration:

DGMGRL> create configuration 'DGconfig' as primary database is 'primaryDB' connect identifier is primaryDB;
Configuration "DGconfig" created with primary database "primaryDB"

DGMGRL> ADD FAR_SYNC farsync1 as connect identifier is farsync1;
far sync instance "farsync1" added

DGMGRL> add database standbyDB as connect identifier is standbyDB;
Database "standbyDB" added

DGMGRL> edit far_sync farsync1 set property redoroutes='(primaryDB:standbyDB ASYNC)';
Property "redoroutes" updated

DGMGRL> edit far_sync farsync1 set property maxfailure=1;
Property "maxfailure" updated

DGMGRL> edit far_sync farsync1 set property nettimeout=8;
Property "nettimeout" updated

DGMGRL> edit far_sync farsync1 set property reopensecs=5;
Property "reopensecs" updated

DGMGRL> edit database primaryDB set property redoroutes='(LOCAL:farsync1 sync alt=(standbyDB async fallback))';
Property "redoroutes" updated

DGMGRL> edit database standbyDB set property redoroutes='(LOCAL:primaryDB async)';
Property "redoroutes" updated

DGMGRL> show configuration

Configuration - DGconfig

Protection Mode: MaxPerformance
Members:
primaryDB - Primary database
 farsync1 - Far sync instance
  standbyDB - Physical standby database
 standbyDB - Physical standby database (alternate of farsync1)

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

To avoid this error apply the patch for bug 19399918 in all environments(Primary, Far Sync, Standby).

GOAL

From the definition of Application Continuity (AC), the AC replays support Data Guard environments, and it replays the uncommitted transactions in the standby when primary fails.

Scenario:
Application is connected to the Primary Database. Application executes transactions and commits the data. However, the committed data does not reach the standby database due to network latency.
In such scenario, if a failover to the standby database from the primary database is performed, will the replay drivers continue to replay the transaction that was committed but not replicated to the standby site?
What level of protection does Application continuity gives in such scenario?
 

SOLUTION

An Application Continuity-aware configuration uses Transaction Guard to know if the last user submission committed or not. When a failure occurs, the replay driver receives a failure notification and reconnects to the new primary database. Then Application Continuity performs sanity checks to verify that is the correct database and able to safely receive replay requests. Next, Transaction Guard is invoked to determine the state of in-flight transactions. If uncommitted changes exist, they are replayed.
So, if the transaction is already committed, Transaction Guard will avoid already-committed transactions being replayed again,causing potential for logical data corruption.
Data Guard has features such as maximize protection modes to handle committed data changes written to redo logs when there are communication issues with the standby.
To find out the protection mode you use in DataGuard, you could query v$database.
 

SQL>select database_role, open_mode, protection_level, protection_mode from v$database;


For MAXIMUM PROTECTION mode, the lgwr sync affirm log transport mode would be used.
So the transaction won't be committed on the primary database until the standby receives the redo from the primary and send acknowledge back to the primary saying the standby receives the redo. In case there is a communication issue between the primary and the standby, the transaction will not be committed on the primary database which could cause the primary hanging.

Reference: 
Data Guard Concepts and Administration

这篇关于Far Sync Standby 能不能支持 max protection的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/438631

相关文章

k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)

《k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)》本文记录在K8s上运行的MySQL/MariaDB备份方案,通过工具容器执行mysqldump,结合定时任务实... 目录前言一、获取需要备份的数据库的信息二、备份步骤1.准备工作(X86)1.准备工作(arm)2.手

华为鸿蒙HarmonyOS 5.1官宣7月开启升级! 首批支持名单公布

《华为鸿蒙HarmonyOS5.1官宣7月开启升级!首批支持名单公布》在刚刚结束的华为Pura80系列及全场景新品发布会上,除了众多新品的发布,还有一个消息也点燃了所有鸿蒙用户的期待,那就是Ha... 在今日的华为 Pura 80 系列及全场景新品发布会上,华为宣布鸿蒙 HarmonyOS 5.1 将于 7

golang 对象池sync.Pool的实现

《golang对象池sync.Pool的实现》:本文主要介绍golang对象池sync.Pool的实现,用于缓存和复用临时对象,以减少内存分配和垃圾回收的压力,下面就来介绍一下,感兴趣的可以了解... 目录sync.Pool的用法原理sync.Pool 的使用示例sync.Pool 的使用场景注意sync.

电脑软件不能安装到C盘? 真相颠覆你的认知!

《电脑软件不能安装到C盘?真相颠覆你的认知!》很多人习惯把软件装到D盘、E盘,刻意绕开C盘,这种习惯从哪来?让我们用数据和案例,拆解背后的3大原因... 我身边不少朋友,在使用电脑安装软件的时候,总是习惯性的把软件安装到D盘或者E盘等位置,刻意避开C盘。如果你也有这样的习惯,或者不明白为什么要这么做,那么我

vscode不能打开终端问题的解决办法

《vscode不能打开终端问题的解决办法》:本文主要介绍vscode不能打开终端问题的解决办法,问题的根源是Windows的安全软件限制了PowerShell的运行,而VSCode默认使用Powe... 遇到vscode不能打开终端问题,一直以为是安全软件限制问题,也没搜到解决方案,因为影响也不大,就没有管

SpringKafka消息发布之KafkaTemplate与事务支持功能

《SpringKafka消息发布之KafkaTemplate与事务支持功能》通过本文介绍的基本用法、序列化选项、事务支持、错误处理和性能优化技术,开发者可以构建高效可靠的Kafka消息发布系统,事务支... 目录引言一、KafkaTemplate基础二、消息序列化三、事务支持机制四、错误处理与重试五、性能优

一文教你解决Python不支持中文路径的问题

《一文教你解决Python不支持中文路径的问题》Python是一种广泛使用的高级编程语言,然而在处理包含中文字符的文件路径时,Python有时会表现出一些不友好的行为,下面小编就来为大家介绍一下具体的... 目录问题背景解决方案1. 设置正确的文件编码2. 使用pathlib模块3. 转换路径为Unicod

定价129元!支持双频 Wi-Fi 5的华为AX1路由器发布

《定价129元!支持双频Wi-Fi5的华为AX1路由器发布》华为上周推出了其最新的入门级Wi-Fi5路由器——华为路由AX1,建议零售价129元,这款路由器配置如何?详细请看下文介... 华为 Wi-Fi 5 路由 AX1 已正式开售,新品支持双频 1200 兆、配有四个千兆网口、提供可视化智能诊断功能,建

Go中sync.Once源码的深度讲解

《Go中sync.Once源码的深度讲解》sync.Once是Go语言标准库中的一个同步原语,用于确保某个操作只执行一次,本文将从源码出发为大家详细介绍一下sync.Once的具体使用,x希望对大家有... 目录概念简单示例源码解读总结概念sync.Once是Go语言标准库中的一个同步原语,用于确保某个操

解决Office Word不能切换中文输入

我们在使用WORD的时可能会经常碰到WORD中无法输入中文的情况。因为,虽然我们安装了搜狗输入法,但是到我们在WORD中使用搜狗的输入法的切换中英文的按键的时候会发现根本没有效果,无法将输入法切换成中文的。下面我就介绍一下如何在WORD中把搜狗输入法切换到中文。