Um cascading standby database é um physical standby database que recebe redo do banco primário e ao mesmo tempo em que aplica as mudanças em seus arquivos locais, encaminha o redo para outros standby databases, estes são chamados de terminal destinations.
Um Cascaded Redo Transport Destination também conhecido como terminal 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 (quando os Standby Redo Log Files completos são arquivados). 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: Em alguns casos o uso de uma instância Far Sync pode substituir, sem prejuízo, o uso de um cascading standby. Para outros cenários o cascading standby é uma alternativa mais apropriada. 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 o transporte de redo em modo SYNC, 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 usar uma instancia far sync ou um cascading standby database.
Com base no que foi descrito no parágrafo anterior, temos duas opções para resolver o problema de latência, contudo é importante considerar que no Oracle database 19c, a configuração do dataguard com modo de proteção em MaxProtection não é permitida com uso de uma instancia Far Sync. Dessa forma, se o transporte síncrono e modo de proteção MaxProtection for um requisito da arquitetura faz se necessário o uso de um cascading standby database para atender os requisitos de modo de transport, modo de proteção e minimizar o impacto de performance resultante da latência entre o banco primários e os terminais destinations.
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 cascading 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 configuration;
Enabled.
DGMGRL>
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 enviar os registros de redo do banco primário (orcl) para o physical standby local (orcldg). Por sua vez, o orcldg vai fazer o “cascateamento” 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.
Quase pronto. Temos nosso cascading standby database perfeitamente configurado e funcional, contudo o Protection Mode da configuração ainda está MaxPerformance. Para que o ambiente fique fidedigno ao proposto para o cenário 01, vamos ajustar o mode de proteção.
Um dos requisitos para definir o modo de proteção da configuração para MaxProtection é que pelo menos um dos standby databases esteja recebendo redo de forma síncrona. Esse requisito já está sendo atendido, pois o transporte de redo do banco primário para o cascading standby está sendo feito no modo sync.
IMPORTANTE: Não é possível sair do modo de proteção MaxPerformance diretamente para MaxProtection. É necessário saltar primeiro para o modo MaxAvailability e depois para o MaxProtection.
DGMGRL> edit configuration set protection mode as MaxAvailability;
Succeeded.
DGMGRL>
DGMGRL> edit configuration set protection mode as MaxProtection;
Succeeded.
DGMGRL>
Veja o status da configuração. Observe que o modo de proteção está definido como MaxProtection.
Finalmente temos nosso cenário com cascading standby database recebendo redo de forma síncrona do banco primário e reencaminhando os registros de redo para os terminais de destino de modo assíncrono e dando suporte para o modo de proteção em MaxProtection.
0 Comentários