Tarefas do Ciclo de Vida

É necessária uma manutenção regular do ciclo de vida para manter o site secundário sincronizado com o site principal. Durante todo o ciclo de vida, você poderá fazer um switchover planejado para alternar as funções dos sites principal e secundário e responder a operações inesperadas ou não planejadas.

Sobre a Replicação de Configuração

Uma replicação inicial do conteúdo que reside nos sistemas de arquivos foi executada durante a configuração do DR. Você deve repetir a replicação do sistema de arquivos regularmente para manter o site secundário atualizado com o site principal.

Você pode usar os mesmos scripts criados durante a configuração do DR, Replicar os Artefatos do Sistema de Arquivos ao OCI, e programar a réplica dos sistemas de arquivos com as seguintes considerações para cada artefato:

Replicação dos Oracle Homes durante o ciclo de vida
Este é um artefato estático. Não muda com frequência, por isso não há necessidade de replicá-lo regularmente. Somente quando você executa uma modificação no Oracle Home (como atividade de aplicação de patch) é necessário replicá-la.
Replicação da configuração compartilhada do domínio WebLogic durante o ciclo de vida
Este é um artefato dinâmico. Entre outras coisas, ele contém o ASERVER_HOME, que é a origem da verdade da configuração do domínio do SOA, e o APPLICATION_HOME, que é atualizado toda vez que um aplicativo é implantado, não implantado, atualizado etc.

Espera-se que essa configuração compartilhada do domínio WebLogic seja alterada com frequência. Programe uma réplica regular deste artefato, que deve ser mais ou menos frequente, dependendo da frequência com que as alterações de configuração ocorrem no sistema. Outra abordagem controlada é executar uma réplica sempre que você executa uma alteração de configuração no principal.
Replicação da configuração privada do domínio WebLogic durante o ciclo de vida
Esse também é um artefato dinâmico, que contém MSERVER_HOME e NM_HOME. Não é esperado que haja atualizações frequentes no home nodemanager após a configuração inicial. O conteúdo do MSERVER_HOME será alterado com a frequência que o ASERVER_HOME, porque ele contém a pasta de domínio usada pelos servidores gerenciados. No entanto, a maioria de seu conteúdo (o ASERVER_HOME/config) é atualizada e baixada do AdminServer quando os servidores gerenciados são iniciados e quando as alterações de configuração são aplicadas usando a WebLogic Scripting Tool (WLST) ou a Console de Administração do Oracle WebLogic Server. Não é tão crítico replicar esse artefato com frequência como a configuração compartilhada. É obrigatório replicar isso somente quando as modificações são feitas em outras pastas no MSERVER_HOME (por exemplo, uma modificação na pasta MSERVER_HOME/bin).
Replicação da pasta de runtime compartilhada
Se você armazenar qualquer artefato de runtime nesta pasta, programe a réplica para stand-by, de acordo com as necessidades do seu negócio.

Em vez de usar o sistema de arquivos do Oracle Cloud Infrastructure File Storage e replicar com rsync, você pode usar uma montagem do Oracle Database File System (DBFS) para o conteúdo de runtime compartilhado. Dessa forma, o conteúdo reside no banco de dados e é automaticamente replicado para o secundário com a réplica subjacente do Oracle Data Guard. Consulte Sobre o Oracle Database File System em Saiba Mais para obter detalhes sobre como usar o DBFS.

A tabela a seguir é um resumo das recomendações para a replicação de artefatos do sistema de arquivos durante o ciclo de vida.

Artefato	Contém	Recomendação
Oracle Homes	FMW home, JDK, inventário	Replicar somente sob demanda (Por exemplo, após a aplicação de patches)
WebLogic Configuração Compartilhada do Domínio	`ASERVER_HOME`, aplicativos, planos de implantação, armazenamentos de chaves	Programar replicação, talvez alta frequência seja necessária. A frequência depende da frequência com que as alterações de configuração são realizadas no sistema SOA.
WebLogic Configuração Privada do Domínio	`MSERVER_HOMES`, `nodemanager config`	Programar replicação. Normalmente, a alta frequência não é necessária.
Runtime Compartilhado	Artefatos de runtime específicos do cliente (não JMS, não TLOGS)	Determinado pelos seus requisitos. Se esta for uma montagem do DBFS, o conteúdo será replicado automaticamente pelo Oracle Data Guard.

Executar um Switchover

Um switchover é uma operação planejada na qual um administrador reverte as funções dos dois sites. Depois de um switchover, o sistema principal se torna secundário e o sistema secundário se torna principal. A execução de um switchover causará tempo de inatividade no site principal.

Antes de executar um switchover em uma configuração de DR Híbrida SOA, propague todas as alterações de configuração pendentes. Certifique-se de que não haja alterações replicadas para o site secundário pendente.

Desative qualquer replicação programada enquanto o switchover for executado, pois pode falhar e interferir na própria operação de switchover.
Interrompa os sistemas Oracle HTTP Server no site principal.
Interrompa os servidores no site principal.
Use a Console do Servidor de Administração WebLogic ou scripts para interromper os servidores WebLogic no site principal.

Observação:
O servidor Admin no site principal pode permanecer ativo durante o switchover. No entanto, é recomendável interrompê-lo quando o site estiver na atribuição stand-by porque é esperado que a configuração do domínio no site stand-by seja substituída pela configuração principal durante o ciclo de vida. Se o servidor Admin estiver ativo enquanto isso acontecer, ele será executado com uma configuração desatualizada.
Alterne o nome do DNS front-end.

Execute a operação de push de DNS necessária no servidor DNS que hospeda os nomes usados pelo sistema ou altere a resolução do host de arquivo em clientes para apontar o nome virtual de front-end do sistema para o IP público usado pelo Balanceador de Carga no site secundário.

Para cenários em que o DNS é usado para a resolução de front-end externa (como DNS do OCI ou DNS comercial), você pode usar uma API para enviar a alteração. Para ver um exemplo que envia essa alteração em um DNS do OCI, vá para GitHub, por exemplo, scripts.

Observe que o valor TTL da entrada de DNS afetará o RTO da alternância: se o TTL for alto (exemplo, 20 min), a alteração de DNS levará esse tempo para ser efetivo nos clientes. O uso de valores de TTL mais baixos fará com que isso seja mais rápido; no entanto, isso pode causar uma sobrecarga porque os clientes afetarão o DNS com mais frequência, em vez de usar nomes armazenados em cache. Uma boa abordagem é definir o TTL para um valor baixo temporariamente (por exemplo, 1 min), antes da alteração no DNS. Em seguida, execute a alteração e, depois que o procedimento de switchover for concluído, reverta o TTL para o respectivo valor original novamente.
Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados principal para executar o switchover do banco de dados.
Você precisará da senha do sistema e do nome exclusivo do banco de dados principal.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário (novo principal).
Inicie o Servidor Admin no site secundário (novo principal) ou reinicie o servidor se ele já tiver sido iniciado.
A inicialização do Servidor Admin permite alterações de configuração que foram replicadas enquanto este era um stand-by para entrar em vigor.
Inicie os servidores gerenciados secundários no site secundário (novo principal).
Use a Console WebLogic ou scripts para iniciar os servidores gerenciados secundários.

Executar um Failover

Uma operação de failover normalmente é uma operação não planejada executada quando o site principal fica indisponível. Você pode fazer a transição de uma atribuição de banco de dados stand-by para a atribuição de banco de dados principal quando o banco de dados principal original falhar e não houver possibilidade de recuperá-lo em tempo hábil. Pode haver perda de dados, dependendo de seus bancos de dados stand-by principais e de destino estarem consistentes no momento da falha do banco de dados principal.

Propagar qualquer alteração de configuração pendente, se possível.
Consulte Replicar os Artefatos do Sistema de Arquivos ao OCI para replicar alterações no site secundário.
Desative qualquer replicação programada enquanto o switchover for executado, pois pode falhar e interferir na própria operação de switchover.
Interrompa os sistemas Oracle HTTP Server no site principal.
Interrompa os servidores gerenciados no site principal, se possível.

Use a Console do Servidor de Administração WebLogic ou scripts para interromper servidores gerenciados no principal.
Alterne o nome do DNS front-end.

Execute a operação de push de DNS necessária no servidor DNS que hospeda os nomes usados pelo sistema ou altere a resolução do host de arquivo em clientes para apontar o nome virtual de front-end do sistema para o IP público usado pelo Balanceador de Carga no site secundário.

Para cenários em que o DNS é usado para a resolução de front-end externa (OCI DNS, DNS comercial etc.), use a API apropriada para enviar a alteração. Para ver um exemplo que envia essa alteração em um DNS do OCI, vá aqui.

Observação:
o valor TTL da entrada de DNS afetará o RTO do switchover. Se o TTL for alto (por exemplo, 20 min), a alteração do DNS levará esse tempo para ser eficaz nos clientes. O uso de valores de TTL mais baixos tornará isso mais rápido; no entanto, isso pode causar uma sobrecarga porque os clientes afetarão o DNS com mais frequência, em vez de usar nomes armazenados no cache. Uma boa abordagem é definir o TTL para um valor baixo temporariamente (por exemplo, 1 min), antes da alteração no DNS. Em seguida, execute a alteração e, depois que o procedimento de switchover for concluído, reverta o TTL para seu valor original.
Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados secundário para executar o failover.
Você precisará da senha do sistema e do nome exclusivo do banco de dados principal.
```
[oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover to secondary_db_unqname
```
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário (novo principal).
Inicie o Servidor Admin no site secundário (novo principal) ou reinicie o servidor se ele já tiver sido iniciado.
A inicialização do Servidor Admin permite alterações de configuração que foram replicadas enquanto este era um stand-by para entrar em vigor.
Inicie os servidores gerenciados secundários no site secundário (novo principal).
Use a Console WebLogic ou scripts para iniciar os servidores gerenciados secundários.

Abrir o Secundário para Validação

Você pode validar o site stand-by sem executar um switchover completo convertendo o banco de dados stand-by no snapshot standby. Isso permite que os servidores SOA secundários sejam iniciados no site stand-by e verifique o sistema secundário. Qualquer alteração executada no banco de dados do site stand-by enquanto ele estiver no modo stand-by de snapshot será descartada assim que for convertido para stand-by físico novamente. Os dados principais não são afetados por validações de sites secundários.

Observação:

Esta operação deve ser feita com cuidado: se houver mensagens ou compostos pendentes no banco de dados quando ele for convertido em snapshot, os servidores SOA do site stand-by os processarão quando iniciarem. Verifique se não há ações pendentes no banco de dados principal ao converter em stand-by snapshot. Caso contrário, remova registros das tabelas SOA de runtime no banco de dados stand-by depois que ele for convertido em banco de dados stand-by snapshot e antes de iniciar os servidores SOA do site secundário. Consulte Removendo Registros das Tabelas de Runtime sem Eliminar as Tabelas para obter as etapas para validar o site stand-by sem executar um switchover.

Como usuário oracle, use o broker do Oracle Data Guard no host do bd principal e converta o secundário em um standby de snapshot.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Use o comando show configuration para verificar se a conversão foi executada corretamente.
Verifique se não há ações pendentes no ambiente secundário.
Se houver ações pendentes (transações, mensagens) no banco de dados principal quando o stand-by for convertido em snapshot, os servidores SOA secundários tentarão processá-los quando start.You puderem usar o script de truncamento SOA para remover os registros das tabelas de runtime SOA no banco de dados secundário para limpar os dados de runtime antes de iniciar os servidores secundários. Execute esta ação com CUIDADO; não trunque tabelas no banco de dados principal. Consulte Removendo Registros das Tabelas de Runtime sem Eliminar as Tabelas.
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário.
Inicie o Servidor Admin no site secundário.
Inicie os servidores gerenciados secundários no site secundário.
Use a Console WebLogic ou scripts para iniciar os servidores gerenciados secundários.
Validar o site secundário.

Como esse não é um switchover e o site principal ainda está ativo, o nome do front-end virtual será resolvido para o endereço IP do balanceador de carga do site principal; portanto, qualquer acesso do browser será, por padrão, redirecionado para o site principal ativo.

Para acessar diretamente os serviços SOA do site secundário, atualize o arquivo /etc/hosts em um cliente controlado (por exemplo, um laptop), defina o nome do front-end virtual para resolver o endereço IP do balanceador de carga front-end do site secundário e execute qualquer validação desse cliente.

Observação:
Verifique se o cliente usado para validações não acessa o sistema por meio de um proxy HTTP, porque o proxy HTTP pode continuar a resolver o nome front-end virtual com o endereço IP do balanceador de carga do site principal, independentemente do nome no /etc/hosts do cliente.

Clientes não Linux podem exigir uma redefinição de seu cache DNS local antes que um navegador resolva o endereço IP usando a entrada personalizada do arquivo do host.

Depois que o site secundário tiver sido validado, vá para a próxima etapa para revertê-lo para a atribuição standby.

Observação:
Pode levar algum tempo para validar o site secundário.
Interrompa os servidores gerenciados e os servidores de administração no site secundário.
Use a Console secundária WebLogic para fazer shutdown dos servidores gerenciados e do servidor Admin no site secundário.
Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados principal e converta o secundário em standby físico novamente.
Você precisará da senha do sistema e do nome exclusivo do banco de dados principal.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Use show configuration para verificar a conversão.
Reverta todos os arquivos /etc/hosts atualizados.
Se você atualizou quaisquer arquivos /etc/hosts em um cliente para apontar para o site secundário para validações, reverta para que o nome do front-end virtual aponte para o endereço IP do front-end principal novamente.

Observação:

ORA-01403: nenhum dado encontrado erros ORA-06512

Ao validar o site secundário conforme descrito aqui (sem executar um switchover completo, ou seja, apenas abrir stand-by no modo stand-by de snapshot) "ORA-01403: nenhum dado encontrado ORA-06512" erros podem aparecer nos logs dos servidores SOA stand-by. Esses erros estão relacionados ao job de expurgação automática SOA. Esses erros surgem porque os jobs no banco de dados podem ter dependências de atribuição de bd (eles são definidos para serem ativados somente quando o banco de dados está na atribuição principal). Esse é um comportamento esperado e desejado que impede que os jobs sejam executados duas vezes (uma vez no principal e outra no stand-by). O job de expurgação automática SOA é definido com a atribuição principal; portanto, ele não é mostrado na view DBA_SCHEDULER_JOBS quando o banco de dados está no modo stand-by de snapshot. A database_role definida para cada job pode ser vista na view DBA_SCHEDULER_JOB_ROLE. Em resumo, esses erros podem ser ignorados desde que apareçam no sistema stand-by. O job do programador para expurgação automática SOA será executado no banco de dados se, e somente se, a instância alterar sua atribuição para PRIMARY.

Failover Local do Servidor de Administração no OCI

Você pode iniciar o Servidor de Administração em um nó diferente no mesmo site quando houver uma falha no host em que o Servidor de Administração estava sendo executado originalmente. Não é necessário ter uma alternância completa do sistema para outro site.

Observação:

Esta tarefa do ciclo de vida só é aplicável quando WebLogic Servidores de Administração usam um VIP para fins de alta disponibilidade local e a pasta de configuração do Servidor de Administração (ASERVER_HOME) está em um local compartilhado.

O procedimento para fazer isso é explicado em Verificando Failover Manual do Servidor de Administração. Isso fornece proteção de failover local para o servidor de Administração. Observe que isso não é necessário para os servidores gerenciados, que têm proteção local de alta disponibilidade com base no recurso de Migração Automática de Serviço.

Se você precisar executar um failover do Servidor de Administração para outro host quando o principal estiver em execução no site do OCI, poderá seguir esse procedimento. No entanto, ações adicionais são necessárias relacionadas à etapa "Migrar o endereço IP virtual ADMINVHN para o segundo host".

Execute as seguintes etapas para desanexar o VIP do host do SOA no qual o Servidor de Administração estava em execução e anexá-lo ao host do SOA no qual a Administração está sendo movida (desanexe o VIP do SOAHOST1 e anexe-o ao SOAHOST2 no site do OCI):

Como usuário root, execute os comandos a seguir em SOAHOST1 para remover o VIP do Servidor de Administração da interface de rede.
1. Interromper o Servidor de Administração caso ele ainda esteja em execução
2. Confirme onde o VIP está sendo executado.
```
ip addr show dev ens3
```
3. Remova o IP da interface de rede.
```
ip addr del 100.70.8.120/20 dev ens3
```
Desanexe o VIP do Servidor de Administração do SOAHOST1 .
1. Conecte-se à Console do OCI e selecione a região e o compartimento apropriados.
2. Navegue até a instância de computação. Clique em Compute, Instâncias e, em seguida, clique em SOAHOST1.
3. Clique em VNICs Anexadas e selecione a VNIC na qual o VIP do Servidor de Administração está anexado.
4. Clique em Endereços IPv4 e edite o VIP que o Servidor de Administração usa.
5. Salve o endereço IP e o nome fqdn do VIP em uma nota (por exemplo: 100.70.8.120, hidrsoa-vip.midtiersubnet.hydrvcn.oraclevcn.com).
6. Clique em Excluir IP Privado.
Anexe o VIP do Servidor de Administração ao SOAHOST2.
1. Navegue até a instância de computação. Clique em Compute, Instâncias e, em seguida, clique em SOAHOST2.
2. Clique em VNICs Anexadas e selecione a VNIC na qual o VIP do Servidor de Administração está anexado.
3. Clique em Designar endereço IP privado secundário.
4. Clique em Endereços IPv4 e, em seguida, clique em Designar endereço IP privado secundário.
5. Informe os valores de endereço IP Privado e nome do host que foram usados antes. Por exemplo: 100.70.8.120 para o IP e hydrsoa-vip como o nome do host.
Faça log-in em SOAHOST2 como usuário raiz e, em seguida, execute os comandos a seguir para anexar o VIP do servidor de administração à interface de rede.
1. Confirme onde a interface de rede está sendo executada.
```
ip addr show dev ens3
```
2. Adicione o VIP do Servidor de Administração à interface de rede.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Execute o restante das etapas, conforme descrito em Verificando Failover Manual do Servidor de Administração.