Failover e Recuperação do Local

Um failover do site será necessário se sua infraestrutura tiver sofrido um evento não planejado que faça com que o site principal fique indisponível e completamente inacessível por um período de tempo que afetará negativamente os negócios. Nesse cenário, o stand-by assume a atribuição principal.

Um site principal pode ficar indisponível por vários motivos, incluindo, entre outros:

Problemas que podem fazer com que as instâncias primárias do banco de dados não sejam iniciadas, como mídia com falha ou amplamente corrompida, ou um upgrade de sistema operacional ou firmware com falha
Falha de infraestrutura, como uma interrupção total do sistema de energia ou refrigeração na infraestrutura da região do OCI
Falhas de rede completas
Desastres naturais, como terremotos, incêndios e inundações

Embora eventos não planejados sejam raros, eles podem e ocorrem.

Executar Failover do Local

Como um verdadeiro failover é disruptivo e pode resultar em uma pequena perda de dados, teste o failover do seu site em um ambiente de TESTE.

O exemplo a seguir usa nomes de nosso ambiente de teste para o banco de dados Principal em Ashburn (CDBHCM_iad1dx) e o banco de dados Stand-by em Phoenix (CDBHCM_phx5s).

Forçar uma interrupção de todas as instâncias do banco de dados Oracle Real Application Clusters (Oracle RAC) no principal.

Observação:
Não realize este teste em um ambiente de produção.
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
A partir deste ponto, o nosso primário é assumido (simulado) para ser completamente indisponível. Tornaremos nossa região secundária nosso novo site principal.
As etapas a seguir usam nossa implementação de teste e todas as etapas são executadas no local secundário (novo principal).

No site secundário, faça log-in em qualquer um dos Oracle Exadata Database Service on Dedicated Infrastructure domUs, torne-se o usuário do SO oracle e chame a interface da linha de comando do Data Guard Broker.

Nó: Um Oracle Exadata Database Service on Dedicated Infrastructure domU
Usuário: oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

Observe o erro.

Execute um failover usando a interface de linha de comando do Oracle Data Guard Broker.
- Nó: Um Oracle Exadata Database Service on Dedicated Infrastructure domU no site secundário
- Usuário: oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
Se as camadas intermediárias principais (incluindo o sistema de arquivos compartilhados) ainda estiverem intactas, execute manualmente um rsync "forçado" do site principal com falha para o site de DR.

As camadas de aplicativo e Web ainda podem estar funcionais, mas os processos de aplicativo e do Process Scheduler começarão a falhar ao tentar estabelecer conexão com o banco de dados com falha. Isso fará com que o script rsync pare de executar rsync.
- Nó: Uma camada intermediária, site principal com falha
- Usuário: psadm2
1. Execute um rsync forçado. Um script rsync_psft.sh de amostra está disponível no diretório de scripts.
  Se o script rsync estiver desativado, o parâmetro -f solicitará que você continue com um rsync forçado. Um rsync forçado não consultará o banco de dados para determinar a atribuição do site; em seguida, executará o rsync solicitado.
  
  Observação:
  Isso só deve ser feito ao forçar uma atualização final durante um failover do site. O uso da opção FORCE é registrado.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Por exemplo,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Monitore o log do processo rsync para verificar se o processo foi concluído com sucesso.
Se a falha do site estiver concluída e um processo rsync final não puder ser executado, desative rsync no novo principal executando o script disable_psft_rsync.sh.
- Nó: Uma camada intermediária, novo site principal
- Usuário: psadm2
```
disable_psft_rsync.sh
```
Se você tiver configurado o suporte do Active Data Guard ao configurar seus servidores de banco de dados principal e stand-by, certifique-se de que o serviço Active Data Guard para PeopleSoft (PSQUERY) tenha sido iniciado no novo banco de dados principal.
- Nó: Um Oracle Exadata Database Service on Dedicated Infrastructure domU no site secundário
- Usuário: oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
Esse serviço deve estar em execução em todas as instâncias do Oracle Real Application Clusters (Oracle RAC).

Observação:
Esse serviço deve ser iniciado antes de iniciar o process scheduler. Caso contrário, o process scheduler falhará na inicialização.
Verifique se os serviços de banco de dados baseados em atribuição estão ativos no novo principal.
- Site: Site 2
- Nó: Todos os Oracle Exadata Database Service on Dedicated Infrastructure domUs
- Usuário: oracle
Por exemplo, execute o seguinte comando em cada domU que hospeda uma instância de banco de dados Oracle RAC PeopleSoft:
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
Este serviço deve estar em execução em todas as instâncias do Oracle RAC.

Inicie o servidor de aplicativos e os domínios do Process Scheduler.

Site: Site 2
Nó: Instâncias de computação do servidor do programador de aplicativos e processos
Usuário: psadm2

Faça log-in nas instâncias de computação que hospedam os servidores de aplicativos PeopleSoft e o process scheduler e torne-se psadm2.
Use o script startPSFTAPP.sh do diretório Wrapper em GitHub.
```
$ startPSFTAPP.sh
```

Monitore a inicialização.

Você pode usar a consulta nos Domínios do Application e do Process Scheduler PeopleSoft.

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

Se você não tiver uma falha completa no site, conforme descrito na Etapa 5, vá para a próxima etapa. Se você tiver uma falha completa no site, execute o script disable_psft_rsync.sh novamente, pois o script startPSTAPP.sh ativará rsync.
Observação:

Em um evento de falha real em que o site principal é perdido ou se torna inacessível, você precisará realizar uma avaliação do escopo e do impacto. Aqui estão alguns itens a serem considerados:
- Possível perda de dados do banco de dados
- Artefatos do sistema de arquivos ausentes (relatórios, logs, arquivos de entrada e saída e assim por diante)
Dependendo da interrupção, você pode ou não ser capaz de recuperar todas as transações confirmadas no principal original. Se possível, peça aos usuários para verificar as últimas transações em que estavam trabalhando.

É provável que haja artefatos ausentes do sistema de arquivos, desde que a saída seja gravada ou transmitida quando o acesso ao principal original cessar. Use o log de relatório no banco de dados para identificar artefatos do sistema de arquivos criados perto do momento da interrupção e, em seguida, determine o que precisa ser feito, caso a caso, para arquivos ausentes ou incompletos.
Inicie os serviços Web.
- Site: Site 2
- Nó: Todas as instâncias de computação do servidor Web PIA (Internet Architecture) PeopleSoft
- Usuário: psadm2
Se o Coherence*Web estiver configurado, você primeiro iniciará o cluster de cache em todas as instâncias de computação que hospedam os servidores Web PIA e, em seguida, iniciará os servidores Web PIA. Neste exemplo, um script é usado para iniciar ambos na ordem correta.
1. Faça log-in nos servidores web do PIA e torne-se psadm2.
2. Usando o script de startPSFTAPP.sh, inicie os servidores Web.
```
$ startPSFTWEB.sh
```
Verifique o balanceador de carga.
- Site: Região do Site 2
- Nó: Console do OCI
- Usuário: Administrador da tenancy
1. Faça log-in na Console do OCI e altere a região para seu novo principal.
2. Selecione Rede e, em seguida, Balanceador de Carga no menu principal.
3. Selecione o compartimento apropriado.
4. Clique em Conjunto de Backend e, em seguida, clique em Backends.
  Cada backend deve mostrar OK. Pode levar alguns minutos após cada servidor web PIA ter sido iniciado.

Reintegrar a Principal com Falha como o Novo Stand-by

Você vai querer proteger seu novo ambiente de produção com um stand-by. Idealmente, você poderá restabelecer o principal com falha como um novo stand-by restabelecendo o banco de dados e os sistemas de arquivos.

Reintegrar o Antigo Banco de Dados Principal como Stand-by

O Oracle Data Guard impedirá que o banco de dados principal antigo seja aberto quando for disponibilizado novamente após uma falha no site principal. Qualquer tentativa de iniciar o banco de dados normalmente falhará, com mensagens gravadas em seu log de alerta indicando que a reintegração é necessária. Se o Flashback Database tiver sido ativado nesse banco de dados antes da falha, você poderá restabelecer o banco de dados principal antigo como o novo stand-by.

Execute o seguinte para restabelecer o principal antigo como um stand-by da produção atual:

Faça log-in em um dos domUs que hospedam o banco de dados principal antigo e inicie o banco de dados:
```
$ srvctl start database -db CDBHCM_phx5s
```

Faça log-in na interface da linha de comando do Data Guard Broker na nova região principal e mostre a configuração.

Observe o erro ORA-16661 em negrito abaixo.

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

Restabeleça o stand-by.
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
Observação:
O processo de recuperação do banco de dados com falha e de criação de um stand-by válido é iniciado e pode levar algum tempo para ser concluído.
Use a interface da linha de comando do Data Guard Broker para verificar o status do seu ambiente.
Por exemplo,
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
O banco de dados restabelecido agora está servindo como stand-by, protegendo o principal e disponível para switchover e failover.

Se você tiver configurado o suporte ao Active Data Guard ao configurar seus servidores de banco de dados principal e stand-by, o serviço Active Data Guard para PeopleSoft (PSQUERY) poderá ser realocado do banco de dados principal de volta para o banco de dados stand-by.

Reintegrar os Níveis Intermediários Primários Antigos como Standby

Restaure as camadas intermediárias primárias antigas com base no seu evento de failover.

Se seus servidores antigos da camada intermediária principal permanecerem disponíveis enquanto o evento de failover do banco de dados ocorreu, você deverá ter feito um rsync final forçado do site principal com falha para o stand-by no momento da falha e, em seguida, revertido a direção dos processos rsync da mesma maneira que quando você faz um switchover.

As camadas de aplicativo e Web ainda podem estar funcionais, mas os processos de aplicativo e do Process Scheduler começarão a falhar ao tentar estabelecer conexão com o banco de dados com falha. Isso fará com que o script rsync pare de executar rsync.
1. Se as camadas intermediárias principais, incluindo o sistema de arquivos compartilhados, ainda estiverem intactas, execute manualmente um rsync "forçado" do site principal com falha para o site de DR.
  Se o script rsync estiver desativado, o parâmetro -f solicitará que você continue com um rsync forçado. Uma rsync forçada não consultará o banco de dados para determinar a função do local e, em seguida, executará a rsync solicitada.
  
  Observação:
  Isso só deve ser feito ao forçar uma atualização final durante um failover do site. O uso da opção FORCE será registrado.
  
  Você pode usar o script de amostra no diretório de scripts rsync_psft.sh, como usuário psadm2:
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Por exemplo,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Monitore o log do processo rsync para verificar se o processo foi concluído com sucesso.
Se o site principal antigo estiver completamente inacessível mesmo para rsync, execute o seguinte:
1. Desative os scripts rsync no novo site principal com disable_psft_rsync.sh para todos os sistemas de arquivos que estão sendo replicados.
2. Se você puder retomar a atividade nas camadas intermediárias originais posteriormente, reative os scripts rsync e permita que eles se recuperem.
Se você precisar reconstruir suas camadas intermediárias, siga os processos descritos anteriormente.