Um cascading standby database é um physical standby database que recebe redo do banco primário e encaminha para outros standby databases, estes são chamados de terminal destinations.
Um terminal destination ou Cascaded Redo Destination recebe redo do banco primário de forma indireta, em vez de receber os redos diretamente do banco primário, recebe de um um physical standby database intermediário.
Um cascading standby database pode “cascatear” logs de redo do banco primário para até 30 terminais de destino. O cascateamento de redo pode acontecer em tempo real (reencaminha a medida que o redo é recebido do primary) ou em non-real-time (os redos são reencaminhados apenas após serem escritos em archive). O cascateamento em tempo real faz uso da option do Oracle Active Dataguard.
Um cascading standby se apresenta como solução alternativa para problemas comuns em alguns cenários de configuração de DG. Abaixo apresento dois desses cenários.
OBS: Os problemas que descrevo abaixo, podem ser resolvidos com uso de uma instância Far Sync. Para não me alongar na explicação, digo apenas que a escolha entre uma instância far sync e um cascading standby depende de alguns fatores. Possivelmente eu escreva algo explicando sobre isso em breve.
Cenário 01: Configuração em Max Protection com alta latência entre sites
Quando a configuração de DG requer máxima proteção (Max Protection), o commit no banco primário só acontece quando há uma confirmação de que o redo foi recebido e escrito no standby redolog de destino. Caso a latência seja muito alta entre site primário e o site de standby, o commit no banco primário será retardado em função da latência.
Para contornar esse problema, podemos adicionar um cascading standby geograficamente próximo ao banco primário para recebimento dos logs de redo em modo sync. Isso vai possibilitar o modo de máxima proteção sem impactar a performance do banco primário. O casdeding standby envia os redos recebidos do banco primário para os destinos finais. A imagem abaixo apresenta uma solução para o problema exposto.
Cenário 02: Custo de outbound de dados em cloud
Considere o cenário onde o banco primário possui vários bancos de standby e, o banco primário está em um provedor de cloud pública que cobra por tráfego que sai da rede - outbound. Considere também que o site primário está em uma região enquanto que os bancos de standby estão em outra região.
No cenário descrito acima, o tráfego de saída de redo é diretamente proporcional ao número de standby database. Como consequência o custo associado ao outbound de dados também é proporcional ao numero de destinos de redo, pois o numero de redo é multiplicado pelo número de destinos de standby configurado no primary database. Para minimizar o montante de dados que sai do site primário, os dados de redo podem ser direcionados unicamente para um physical standby intermediário, este por sua vez, encaminha os registros de redo para os demais destinos. A imagem abaixo descreve o cenário 2.
Mão na massa - Configurando o cenário 01
Nesta sessão mostro o passo a passo para criar uma configuração de dataguard com um cascading standby conforme descrito no cenário 01 apresentado acima.
Estou assumindo que o banco primário já existe, bem como os demais bancos. Segue a relação dos bancos desta configuração:
- orcl - Primary database
- orcldg - Physical standby database
- standby05 - Physical standby database
- orcldg2 - Logical standby database
Vamos criar uma configuração no broker para gerenciar os componentes da relação de dataguard.
Criando a configuração e adicionando os membros
DGMGRL> create configuration my_broker_config as primary database is orcl connect identifier is 'orcl' ;
Configuration "my_broker_config" created with primary database "orcl"
DGMGRL> show configuration
Configuration - my_broker_config
Protection Mode: MaxPerformance
Members:
orcl - Primary database
Fast-Start Failover: Disabled
Configuration Status:
DISABLED
DGMGRL>
Adicionar os membros da configuração
DGMGRL> add database standby05 as connect identifier is STANDBY05;
Database "standby05" added
DGMGRL> add database orcldg as connect identifier is standby;
Database "orcldg" added
DGMGRL> add database orcldg2 as connect identifier is orcldg2;
Database "orcldg2" added
Habilitar a configuração.
DGMGRL> enable database orcldg2
show configuration
Enabled.
Exibindo a configuração
Observe que a configuração possui quatro membros. O orcl é o primary database e os demais membros são standby database recebendo redo diretamente do banco orcl.
DGMGRL> show configuration verbose
Configuration - my_broker_config
Protection Mode: MaxPerformance
Members:
orcl - Primary database
standby05 - Physical standby database
orcldg - Physical standby database
orcldg2 - Logical standby database
Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS
Como podemos observar, até o momento não temos um “cascateamento” de redo. Temos apenas uma configuração convencional de dataguard.
Agora vamos iniciar a configuração das rotas para criar o cascateamento de redo do banco primario (orcl) para o physical standby local (orcldg). Por sua vez, o orcldg vai fazer o encaminhamento dos registros de redo recebidos do banco orcl para os destinos finais (standby05 e orcldg2).
Comecemos com a configuração das rotas de redo no banco primário.
OBS: Todas as configurações apresentadas nesta postagem podem ser feitas, também pelo sqlplus. Aqui estou fazendo todas pelo utilitário de linha de comando do broker (dgmgrl).
DGMGRL> edit database orcl set property 'RedoRoutes' = '(LOCAL : (orcldg sync priority=1, orcldg2 async priority=8, standby05 async priority=8))';
Property "redoroutes" updated
DGMGRL>O comando acima está definindo a propriedade RedoRoutes do banco primário.
LOCAL se refere os redologs do banco orcl
orcldg sync priority=1: Determina que os redologs sejam enviados de forma síncrona para o orcldg com prioridade 1. Isso significa que os redos serão enviados apenas para o orcldg enquanto ele estiver disponível.
Os demais bancos (standby05, orcldg2) são destinos alternativos de redolog do banco orcl. Quem determina que eles são destinos alternativos é a prioridade 8. A prioridade 8 determina que, em caso de indisponibilidade do orcldg os destinos alternativos recebem simultaneamente os redos gerados no banco primário.
Se olharmos o status da nossa configuração nesse momento, veremos que apenas o banco orcldg está recebendo redo. Os demais banco são apenas destinos alternativos. A indentação do orcldg em relação ao orcl indica que o orcldg recebe redo diretamento do orcl.
DGMGRL> show configuration
Configuration - my_broker_config
Protection Mode: MaxPerformance
Members:
orcl - Primary database
orcldg - Physical standby database
Members Not Receiving Redo:
standby05 - Physical standby database (alternate of orcldg)
orcldg2 - Logical standby database (alternate of orcldg)
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 50 seconds ago)
Agora precisamos garantir que os registros de redo recebidos pelo banco orcldg (nosso cascading standby) sejam encaminhados para os demais bancos da relação de dataguard. Para isso, vamos editar a propriedade RedoRoutes do cascading standby (orcldg) para fazer o encaminhamento de redo para os bancos orcldg2 e standby05.
Aqui cabe uma observação: Enquanto o banco primário for o orcl, o cascading standby deve encaminhar o redo recebido do primário para os bancos orcldg2 e standby05. Contudo, devemos considerar os cenários onde o orcldg2 ou o standby05 assumam a role de primary, nesse caso o orcldg (cascading standby) deve receber o redo do novo primary e encaminhar para os demais bancos de standby. Segue a configuração.
DGMGRL> edit database orcldg set property redoroutes = '(orcl : standby05 async, orcldg2 async)(standby05 : orcl async, orcldg2 async)(orcldg2 : standby05 async, orcl async)';
Property "redoroutes" updated
DGMGRL>
Neste comando, cada parêntese da propriedade RedoRoutes assume um banco diferente como primary e os demais como standby.
Agora observe o status da configuração focando na indentação dos bancos, onde o banco mais indentado recebe redo diretamente do banco imediatamente menos indentado.
DGMGRL> show configuration verbose
Configuration - my_broker_config
Protection Mode: MaxPerformance
Members:
orcl - Primary database
orcldg - Physical standby database
standby05 - Physical standby database (receiving current redo)
orcldg2 - Logical standby database (receiving current redo)
Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS
DGMGRL>- orcl→orcldg(SYNC)
- orcldg→standby05+orcldg2(ASYNC)
Vamos conferir as rotas de redo de todos os bancos.
DGMGRL> show database orcl RedoRoutes
RedoRoutes = '(LOCAL : (orcldg sync priority=1, orcldg2 async priority=8, standby05 async priority=8))'
DGMGRL> show database orcldg RedoRoutes
RedoRoutes = '(orcl : standby05 async, orcldg2 async)(standby05 : orcl async, orcldg2 async)(orcldg2 : standby05 async, orcl async)'
DGMGRL> show database standby05 RedoRoutes
RedoRoutes = ''
DGMGRL> show database orcldg2 RedoRoutes
RedoRoutes = ''
DGMGRL>
Observe que os bancos standby05 e orcldg2 não tem rotas de redo configuradas para enviar redo. Dessa forma, se o standby05 assumir a role de primary os demais bancos não serão sincronizados.
Considerando que o orcldg2 é um logical standby, não vou configurar rotas de redo para ele. Vou configurar rotas de redo apenas para o banco standby05.
DGMGRL> edit database standby05 set property 'RedoRoutes' = '(LOCAL : (orcldg sync priority=1, orcl async priority=8, orcldg2 async priority=8))';
Property "RedoRoutes" updated
A configuração acima garante que, caso o standby05 assuma a role de primary database, ele enviará redo para o banco orcldg de forma prioritária, enquanto define os demais bancos como destino alternativo de redo.
Veja o status da configuração após essa alteração.
DGMGRL> show configuration verbose;
Configuration - my_broker_config
Protection Mode: MaxPerformance
Members:
orcl - Primary database
orcldg - Physical standby database
standby05 - Physical standby database (receiving current redo)
orcldg2 - Logical standby database (receiving current redo)
orcldg2 - Logical standby database (alternate of orcldg)
standby05 - Physical standby database (alternate of orcldg)
Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
TraceLevel = 'USER'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
ObserverReconnect = '0'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
ObserverOverride = 'FALSE'
ExternalDestination1 = ''
ExternalDestination2 = ''
PrimaryLostWriteAction = 'CONTINUE'
ConfigurationWideServiceName = 'orcl_CFG'
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS
DGMGRL>
O diagrama abaixo mostra o orcl enviando redo com prioridade 1 para o banco orcldg e, caso o orcldg falhe, o redo é enviado simultaneamente para standby05 e orcldg2.
0 Comentários