Documentação do Oracle Cloud Infrastructure

Pré-verificações Executadas pela Recuperação Completa de Desastres de Pilha

A Recuperação de Desastres de Pilha Completa executa pré-verificações para recursos como Grupos de Proteção de DR, Planos de DR e Execuções de Planos de DR.

Pré-verificações da Instância de Computação

Primeiro, o Full Stack DR executa os seguintes pré-verificações de armazenamento para cada VM presente no DRPG principal. O Full Stack DR verifica se:
  • A replicação do grupo de volumes é configurada ou o backup é configurado com uma política de backup e a cópia entre regiões é ativada.
  • Existe uma réplica do grupo de volumes ou pelo menos um backup do grupo de volumes na região stand-by. Vários backups também podem existir, pois o Full Stack DR usa o backup de grupo de volumes mais recente.
  • Todos os volumes de inicialização e em blocos das VMs dos membros de um DRPG são adicionados ao grupo de volumes.
  • O grupo de volumes contém apenas os volumes de inicialização e em blocos anexados à VM dos membros em um DRPG.
  • Se o usuário está tentando adicionar instâncias de computação em movimento a um Grupo de Proteção de DR standby, o que não é permitido.

Pré-verificações do sistema de arquivos:

O Full Stack DR primeiro executa as seguintes pré-verificações para o sistema de arquivos:
  • Fazer Switchover/Failover/Iniciar Drill:
    • Valida se o sistema de arquivos de origem está no estado Ativo e deve ser exportado
    • Valida que o sistema de arquivos de origem não deve ter uma chave de criptografia personalizada
    • Valida se toda a exportação presente no sistema de arquivos de origem está mapeada com o ponto de acesso NFS de destino como parte da propriedade do membro do sistema de arquivos e deve ser exclusiva (evitar duplicação)
    • Valida que há pelo menos uma configuração de política de Replicação ativa no sistema de arquivos de origem
    • Valida se a propriedade do membro do sistema de arquivos domínio de disponibilidade de destino está na região de pareamento
    • Valida se todo o ponto de acesso NFS de destino configurado para exportações do sistema de arquivos de origem estão na região de mesmo nível e estão no mesmo domínio de disponibilidade que o domínio de disponibilidade de destino da propriedade do membro.
    • Valida se o sistema de arquivos de destino está no estado Ativo e deve ser um sistema de arquivos não exportado
    • Valida que pelo menos um snapshot de replicação deve estar presente no sistema de arquivos de destino
    • Valida se os pontos de acesso NFS de destino estão tendo o protocolo TCP/UDP correto ativado. Consulte Configurando Regras de Segurança da VCN para o Serviço File Storage.
    • Valida o OCID na política de snapshot de destino da propriedade do membro do sistema de arquivos.
    • Valida se a política de snapshot de destino na propriedade de membro do sistema de arquivos existe e tem um estado de ciclo de vida Ativo.
    • Valida se o vault de destino e a chave de criptografia de destino na propriedade do membro do sistema de arquivos existe e tem um estado de ciclo de vida Ativo.
    • Valida se a chave de criptografia de destino na propriedade do membro do sistema de arquivos é uma chave de criptografia AES simétrica (Advanced Encryption Standard) e tem um estado de ciclo de vida Ativada.
  • Interromper Drill
    • Valida se o sistema de arquivos clonado exportado está presente para limpeza
    • Valida se as exportações estão presentes no sistema de arquivos exportado clonado para limpeza

Pré-verificações para o Sistema de Arquivos de Montagem/Desmontagem na Instância de Computação:

O Full Stack DR primeiro executa as seguintes pré-verificações para o sistema de arquivos de montagem/desmontagem na instância de computação:
  • Validações para propriedade do membro de detalhe de montagem/desmontagem:
    • Detalhes da montagem:
      • Valida se o ponto de acesso NFS dos detalhes de montagem corresponde à região stand-by.
      • Valida que a combinação de ponto de montagem e exportação é exclusiva (evita várias montagens no mesmo ponto de montagem).
    • Detalhes da desmontagem:
      • Valida se o ponto de acesso NFS dos detalhes de desmontagem corresponde à região principal.
      • Valida se o caminho de exportação está presente no ponto de acesso NFS dos detalhes de desmontagem.
    • Valida se a instância de computação móvel/não móvel e o ponto de acesso NFS dos detalhes de montagem estão tendo o protocolo TCP/UDP correto ativado. Consulte Configurando Regras de Segurança da VCN para o Serviço File Storage.
    • Valida para instância de computação móvel/não móvel, o Grupo de Proteção de DR principal deve ter o sistema de arquivos montável ou o ponto de acesso NFS de destino deve ter o caminho de exportação correto para montar.
    • Observação

      Para um failover, a verificação a seguir é executada na etapa Sistema de Arquivos – Montagem na Instância de Computação com a instância de computação recém-iniciada em decorrência de indisponibilidade da região principal

    • Valida se a instância de computação tem o plug-in Comando de Execução da Instância de Computação ativado.
    • Valida se a instância de computação tem um acesso-raiz:
    • Somente para o sistema operacional Linux, valida se a instância de computação tem nfs-client instalado. Para obter informações sobre como instalar o nfs-client no Compute, consulte Montando Sistemas de Arquivos de Instâncias do Tipo UNIX.
    • Somente para o sistema operacional Linux, valide se o /etc/fstab no sistema operacional linux deve ter detalhes de montagem presentes com o endereço IP do ponto de acesso NFS correto/Nome de Domínio Totalmente Qualificado e ponto de montagem.
    • Para ambos os sistemas operacionais, valide se o ponto de montagem está presente na instância de computação

Pré-verificações para Grupos de Volumes (Armazenamento em Blocos)

Primeiro, o Full Stack DR executa as seguintes pré-verificações para todos os grupos de volumes adicionados ao DRPG principal. O Full Stack DR verifica se:
  • O grupo de volumes está em um estado Available.
  • O grupo de volumes tem replicação ou backups configurados na região stand-by. Se ambos estiverem configurados, o Full Stack DR usará réplicas e ignorará backups.
  • Para DR intra-região, todas as réplicas de região de destino (standby) não estão no mesmo AD (domínio de disponibilidade).
  • A réplica na região stand-by está em um estado Available ou, se os backups forem usados, esse pelo menos um backup existirá e será Available.
  • A lista de volumes do grupo de volumes de origem corresponde à lista de volumes na réplica ou no backup da região standby.
  • A Política de Backup de Destino é uma política de backup válida.
  • O vault e a chave de criptografia fornecidos em Chave de Destino Comum são válidos.
  • O vault fornecido na Chave de Destino Comum tem um estado de ciclo de vida Ativo.
  • A chave de criptografia fornecida na Chave de Destino Comum tem um estado de ciclo de vida Ativada
  • O volume de origem, o vault de destino e a chave de criptografia fornecidos em Mapeamentos de Volume de Origem para Chave de Criptografia de Destino são todos válidos.
  • Chave de Destino Comum ou Volume de Origem para Chave de Criptografia de Destino Mapeamentos são fornecidos, ambas as propriedades do membro não podem ser fornecidas.

Pré-verificações do volume em blocos para instâncias de computação não móveis

Primeiro, o Full Stack DR executa os seguintes pré-verificações para o volume em blocos de instâncias de computação não móveis:

Se a instância de computação for adicionada como membro a um DRPG com a atribuição Principal, execute as seguintes validações para cada ID de volume em blocos fornecido na nova lista de propriedades do membro:
  • O ID do volume em blocos deve ser um OCID válido de um volume em blocos.
  • O volume em blocos não deve ter duplicatas nas propriedades do membro da mesma instância de computação.
  • O volume em blocos já deve estar anexado à instância de computação.
  • O volume em blocos deve fazer parte de algum membro do grupo de volumes do DRPG.
  • Se um ID da instância de referência do anexo de volume for fornecido nos detalhes do anexo, essa instância deverá ser membro do Grupo de Proteção de DR standby e o ID do volume em blocos deverá ser adicionado em suas propriedades de membro.
  • Se o ID da instância de referência do anexo de volume não for fornecido nos detalhes do anexo, somente uma instância de computação no DRPG standby deverá ter uma propriedade de membro definida com esse ID de volume em blocos.
  • Os pontos de montagem definidos devem ser exclusivos.
Se a instância de computação for adicionada como membro a um DRPG com a atribuição Standby, execute as seguintes validações para cada ID de volume em blocos fornecido na nova lista de propriedades do membro:
  • O ID do volume em blocos deve ser um OCID válido de um volume em blocos.
  • O volume em blocos não deve ter duplicatas nas propriedades do membro da mesma instância de computação.
  • O volume em blocos deve ser proveniente da região do DRPG principal.
  • O volume em blocos deve fazer parte de algum membro do grupo de volumes do DRPG principal.
  • O AD de destino/destino do grupo de volumes (em que o backup ou a réplica será ativada) deve corresponder ao AD desta instância de computação stand-by.
  • Se um ID da instância de referência do anexo de volume for fornecido nos detalhes do anexo, essa instância de mesmo nível deverá ser membro do DRPG principal e o volume em blocos deverá ser anexado a ela.
  • Se o ID da instância de referência do anexo de volume não for fornecido nos detalhes do anexo, somente uma instância de computação no DRPG principal deverá ter o volume em blocos anexado a ele.
  • Os pontos de montagem definidos devem ser exclusivos.
  • Dois volumes em blocos não devem ser configurados para anexar usando o mesmo caminho do dispositivo.
  • Se o anexo usar caminhos de dispositivo, os caminhos de dispositivo não deverão estar em uso.
  • Se um volume em blocos for configurado para ser anexado a mais de uma instância de computação, o anexo deverá ter um acesso compartilhável.

Pré-verificações para Armazenamento de objetos com Switchover e Failover

O Full Stack DR executa as seguintes pré-verificações para o armazenamento de objetos:

  • Fazer switchover:

    • Bucket de Armazenamento de Objetos - Pré-verificação de Exclusão de Replicação (Principal)

      • Valida se o bucket de origem está presente.

      • Valida se a política de replicação está presente.

      • Valida se a política de replicação deve estar na região de mesmo nível.

    • Bucket de Armazenamento de Objetos - Pré-verificação de Configuração da Replicação Reversa (Stand-by)

      • Valida se o bucket de destino está presente

      • Valida se o bucket de origem está presente

  • Falha:

    • Bucket de Armazenamento de Objetos - Pré-verificação de Exclusão de Replicação (Principal)

      • Valida se o bucket de origem está em um estado Ativo.

      • Valida se a política de replicação está presente.

      • Valida se a política de replicação deve estar na região de mesmo nível.

      • Valida se o bucket de destino está em um estado Ativo.

    • Bucket de Armazenamento de Objetos - Pré-verificação de Configuração da Replicação Reversa (Stand-by) (Continuar com Erro)

      • Valida se o bucket de destino está presente.
      • Valida se o bucket de origem está presente.

Pré-verificações para o Banco de Dados (Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer)

O Full Stack DR executa as seguintes pré-verificações se um membro do banco de dados (Oracle BaseDatabase Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer) fizer parte do DRPG. O Full Stack DR verifica se:
  • As propriedades do membro do banco de dados não estão vazias ou são nulas e a localização do vault secreto da senha faz parte das propriedades do membro do banco de dados.
  • Você pode acessar o vault secreto no qual a senha do banco de dados é armazenada e o banco de dados de mesmo nível está em um estado Available.
  • O Banco de Dados e o Banco de Dados de mesmo nível têm o Data Guard ativado e são pares do Data Guard um do outro.
  • O Banco de Dados e o Banco de Dados de pareamento têm as atribuições corretas do Data Guard.
  • Banco de Dados e Banco de Dados de pareamento fazem parte dos dois grupos de proteção de DR associados que fazem parte da configuração. O banco de dados principal faz parte do grupo de proteção de DR principal e o banco de dados standby faz parte do grupo de proteção de DR standby.

Pré-verificações para o Oracle Autonomous Database Serverless

O Full Stack DR executa as seguintes pré-verificações se um membro do Autonomous Database Serverless fizer parte do DRPG. O Full Stack DR verifica se:
  • As propriedades do membro do banco de dados autônomo não estão vazias ou são nulas.
  • O Autonomous database principal não tem uma lista de bancos de dados stand-by vazia.
  • O Banco de Dados Autônomo standby não está na mesma região que a região do banco de dados principal e não é um par local.
  • O Autonomous database e o Autonomous database de pareamento fazem parte dos dois grupos de proteção de DR associados que fazem parte da configuração.
  • O Data Guard Remoto está configurado.
  • O banco de dados remoto de mesmo nível pertence ao DRPG remoto.
  • O estado do ciclo de vida do banco de dados principal é AVAILABLE.

    Para pré-verificações de switchover, o Full Stack DR executa as seguintes validações adicionais no banco de dados stand-by: Verifica se o stand-by de pareamento remoto está no estado correto (STANDBY).

  • Se o vault e a chave de criptografia fornecidos em Chave de Criptografia de Destino forem válidos.
  • O id do vault na Chave de Criptografia de Destino tem o estado do ciclo de vida como Ativo.
  • O id de criptografia na Chave de Criptografia de Destino tem o estado do ciclo de vida como Ativado.

Pré-verificações para o Oracle Autonomous Container Database

O Full Stack DR executa as pré-verificações a seguir se um membro do Autonomous Container Database fizer parte do DRPG. O Full Stack DR verifica se:
  • As propriedades do membro do Autonomous Container Database não estão vazias ou são nulas.
  • O Autonomous Container Database principal não tem uma lista de bancos de dados stand-by vazia.
  • O Autonomous database e o Autonomous database de pareamento fazem parte dos dois grupos de proteção de DR associados que fazem parte da configuração.
  • O Data Guard Remoto está configurado.
  • O banco de dados de pareamento remoto pertence ao DRPG remoto.
  • Os estados do ciclo de vida do Autonomous Container Database principal e stand-by são AVAILABLE.

    Para pré-verificações de switchover, o Full Stack DR executa as seguintes validações adicionais no banco de dados stand-by: Verifica se o stand-by de pareamento remoto está no estado correto (STANDBY).

Pré-verificações para o Kubernetes Engine (OKE)

O Full Stack DR executa as seguintes pré-verificações para o Kubernetes Engine (OKE).

Cluster Principal
  1. Verifica a conexão com o cluster principal.
  2. Verifica se o backup é mais antigo que um dia.
  3. Faz download e imprime log de backup.
  4. Valida se o estado do ciclo de vida do cluster do OKE principal é Ativo.
  5. Valida se o namespace e o bucket nas propriedades do membro principal existem e são válidos.
  6. Valida se a programação de backup nas propriedades do membro principal está no formato RFC 5545.
    • Valida para a parte da Regra não suportada.
    • Valida o intervalo de cada parte da Regra.
  7. Valida o mapeamento do balanceador de carga nas propriedades do membro principal das restrições a seguir.
    • SourceLoadBalancerId e DestinationLoadBalancerId têm OCIDs de LOADBALANCER.
    • O mapeamento do balanceador de carga deve ser exclusivo.
      • A-B, C-B -> Não permitido
      • A-B, A-D -> Não permitido
        Observação

        Por exemplo, se você tiver um conjunto de dois balanceadores de carga na região principal (como load_balancer_A and load_balancer_C). Você tem outro conjunto de dois balanceadores de carga na região stand-by (como load_balancer_B and load_balancer_D). Portanto, ao adicionar um cluster do OKE como membro, você deve adicionar a propriedade de mapeamentos do balanceador de carga. Neste mapa, apenas o mapeamento a seguir é permitido: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_D 
or load_balancer_C <--> load_balancer_B & load_balancer_A <--> load_balancer_D
        . No entanto, os seguintes mapeamentos não são permitidos, pois load_balancer_B está definido como o balanceador de carga de destino nos dois mapeamentos: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_B
  8. Valida o mapeamento do balanceador de carga de rede nas propriedades do membro principal das restrições a seguir.
    • SourceNetworkLoadBalancerId e DestinationNetworkLoadBalancerId têm OCIDs de NETWORKLOADBALANCER.
    • O mapeamento do balanceador de carga de rede deve ser exclusivo.
      • A-B, C-B -> Não permitido
      • A-B, A-D -> Não permitido
        Observação

        Por exemplo, se você tiver um conjunto de dois balanceadores de carga de rede na região principal (como network_load_balancer_A and network_load_balancer_C). Você tem outro conjunto de dois balanceadores de carga de rede na região stand-by (como network_load_balancer_B and network_load_balancer_D). Portanto, ao adicionar um cluster do OKE como membro, você deve adicionar a propriedade de mapeamentos do balanceador de carga de rede. Neste mapa, apenas o mapeamento a seguir é permitido: 
        network_load_balancer_A <--> network_load_balancer_B & network_load_balancer_C <--> network_load_balancer_D 
or network_load_balancer_C <--> network_load_balancer_B & network_load_balancer_A <--> network_load_balancer_D
  9. Valida o mapeamento do vault nas propriedades do membro principal das restrições a seguir.
    • SourceVaultId e DestinationVaultId têm OCIDs de VAULT.
    • O mapeamento do vault deve ser exclusivo.
      • A-B, C-B -> Não permitido.
      • A-B, A-D -> Não permitido.
        Observação

        Por exemplo, se você tiver um conjunto de dois vault na região principal (como vault_A and vault_C). Você tem outro conjunto de dois vault na região stand-by (como vault_B and vault_D). Portanto, ao adicionar um cluster do OKE como membro, você deve adicionar a propriedade de mapeamentos do vault. Neste mapa, apenas o mapeamento a seguir é permitido: 
        vault_A  <--> vault_B & vault_C <--> vault_D 
or vault_C <--> vault_B & vault_A <--> vault_D
  10. Valida se o ID do cluster de mesmo nível e o local de backup nas propriedades do membro principal não estão vazios.
  11. Valida o Jump host nas propriedades do membro principal para as restrições a seguir.
    • O Grupo de Proteção de DR deve conter a instância de computação com o mesmo OCID do jump host.
    • O Jump host deve ser uma instância de computação não móvel.
    • O Jump host deve ter o estado Lifecycle como RUNNING.
  12. Valida o ID do cluster de mesmo nível nas propriedades do membro principal das restrições a seguir.
    • Valida se o Grupo de Proteção de DR de mesmo nível tem cluster com ID de cluster de mesmo nível.
    • Valida se o próprio cluster membro não foi adicionado como cluster de pareamento.
    • Valida se o cluster de pareamento fornecido nas propriedades do membro não foi adicionado como cluster de pareamento para o outro cluster do OKE no Grupo de Proteção de DR.
  13. Valida os pools de nós no cluster do OKE da região principal para as restrições a seguir.
    • Valida se a contagem de nós em todos os pools de nós é pelo menos uma.
    • Valida se há pelo menos um nó ativo em todos os pools de nós.
    • Exemplo: Se houver dois pools de nós, um nó não tiver nenhum nó ativo, no entanto, outro tiver um nó ativo, isso resultará em uma exceção.
  14. Valida o ID do balanceador de carga de origem nas propriedades do membro principal das restrições a seguir.
    • O ciclo de vida deve estar Ativo.
    • O balanceador de carga só pode ter sub-rede regional.
  15. Valida o ID do balanceador de carga da rede de origem nas propriedades do membro principal para as restrições a seguir.
    • O ciclo de vida deve estar Ativo.
    • O balanceador de carga de rede só pode ter sub-rede regional.
  16. Valida se o ID do vault de origem nas propriedades do membro principal é Ativo.
  17. Valida a configuração do pool de nós gerenciados nas propriedades do membro principal para as restrições a seguir.
    • O tipo de membro deve ser GERENCIADO.
    • O ciclo de vida deve ser ATIVO.
    • A soma da contagem de nós ('máxima' na configuração do nó gerenciado ou a contagem de nós existente, o que for maior) de todos os pools de nós no cluster não deve exceder o Limite.
  18. Valida a configuração do pool de nós virtuais nas propriedades do membro principal para as restrições a seguir.
    • O tipo de membro deve ser VIRTUAL.
    • O ciclo de vida deve ser ATIVO.
    • A soma da contagem de nós ('máxima' na configuração do nó virtual ou a contagem de nós existente, o que for maior) de todos os pools de nós no cluster não deve exceder o Limite.

Cluster Stand-by

  1. Verifica se o(s) namespace(s) faz(m) parte do backup.
  2. Verifica se todos os volumes em blocos referenciados em volumes persistentes fazem parte do Grupo de Proteção de DR.
  3. Verifica se todos os sistemas de arquivos/alvos de montagem referenciados em volumes persistentes fazem parte do Grupo de Proteção de DR.
  4. Verifica se todos os balanceadores de Carga referenciados na classe de entrada fazem parte do Grupo de Proteção de DR.
  5. Verifica se todos os vaults referenciados em secretproviderclasses fazem parte do Grupo de Proteção de DR.
  6. Verifica se as definições de recursos Personalizados são compatíveis com a versão do cluster stand-by.
  7. Valida se o estado do ciclo de vida do cluster do OKE stand-by está Ativo.
  8. Valida se o ID do cluster de pareamento e o local de backup nas propriedades do membro stand-by não devem ficar vazios.
  9. Valida o Jump host nas propriedades do membro stand-by para as restrições a seguir.
    • O Grupo de Proteção de DR deve conter a instância de computação com o mesmo OCID do jump host.
    • O Jump host deve ser uma instância de computação não móvel.
    • O Jump host deve ter o estado Lifecycle como RUNNING.
  10. Valida o ID do cluster de pareamento nas propriedades do membro stand-by para as restrições a seguir.
    • Valida se o Grupo de Proteção de DR de mesmo nível tem cluster com ID de cluster de mesmo nível.
    • Valida se o próprio cluster membro não foi adicionado como cluster de pareamento.
    • Valida se o cluster de pareamento fornecido nas propriedades do membro não foi adicionado como cluster de pareamento para outro cluster do OKE no Grupo de Proteção de DR.
  11. Valida o ID do balanceador de carga de destino nas propriedades do membro principal das restrições a seguir.
    • O ciclo de vida deve estar Ativo.
    • O balanceador de carga só pode ter sub-rede regional.
  12. Valida o ID do balanceador de carga da rede de destino nas propriedades do membro principal para as restrições a seguir.
    • O ciclo de vida deve estar Ativo.
    • O balanceador de carga de rede só pode ter sub-rede regional.
    • Valida se o ID do vault de destino nas propriedades do membro principal é Ativo.
  13. Valida a configuração do pool de nós gerenciados nas propriedades do membro stand-by para as restrições a seguir.
    • O tipo de membro deve ser GERENCIADO.
    • O ciclo de vida deve estar Ativo.
    • A soma da contagem de nós ('máxima' na configuração do nó gerenciado ou a contagem de nós existente, o que for maior) de todos os pools de nós no cluster não deve exceder o Limite.
  14. Valida a configuração do pool de nós virtuais nas propriedades do membro stand-by para as restrições a seguir.
    • O tipo de membro deve ser VIRTUAL.
    • O ciclo de vida deve estar Ativo.
    • A soma da contagem de nós ('máxima' na configuração do nó virtual ou a contagem de nós existente, o que for maior) de todos os pools de nós no cluster não deve exceder o Limite.
  15. Valida os pools de nós no cluster do OKE da região stand-by para as restrições a seguir.
    • Valida se a contagem de nós em todos os pools de nós é pelo menos uma.
    • Valida se há pelo menos um nó ativo em todos os pools de nós.
  16. Valida se o pool de nós do cluster de destino deve ter pelo menos um nó em cada AD em que o FSS/Block será restaurado.
  17. Valida as regras securityList e NSG definidas no grupo de segurança de sub-rede/rede dos pools de nós e pools de nós virtuais fornecidos no cluster, garantindo que as regras a seguir sejam definidas.
    • Regras de entrada com monitoramento de estado
      • Portas TCP 111, 2048, 2049 e 2050, e
      • Portas UDP 111 e 2048
    • Regras de saída com monitoramento de estado
      • Portas de origem TCP 111, 2048, 2049 e 2050, e
      • Porta de origem UDP 111.
        Observação

        A validação só será aplicável se o Cluster do OKE tiver PV ou PVC para o sistema de arquivos. O Full Stack DR verifica apenas os seguintes cenários:
        • Cenário A: O ponto de acesso NFS e a instância estão em sub-redes diferentes (recomendado).
        • Cenário B: O ponto de acesso NFS e a instância estão na mesma sub-rede.
          O Full Stack DR não verifica os seguintes cenários:
          • Cenário C: O ponto de acesso NFS e a instância usam criptografia TLS em trânsito.
          • Cenário D: O ponto de acesso NFS usa LDAP para autorização.

Pré-verificações para o Sistema de BD do MySQL HeatWave

O Full Stack DR executa as seguintes pré-verificações para o Sistema de BD MySQL:

  • Switchover:
    • Valida se os estados do ciclo de vida dos Sistemas de BD MySQL HeatWave principais e stand-by estão no estado Ativo.
    • Valida se o Sistema de BD de destino está presente no Grupo de Proteção de DR de mesmo nível como membro, que também tem a propriedade do Sistema de BD de destino que corresponde ao OCID do Sistema de BD MySQL principal.
    • Valida se o Sistema de Banco de Dados MySQL principal está no modo Leitura/Gravação.
    • Valida se o Sistema de BD MySQL de destino está no modo Somente para leitura.
    • Valida se o segredo principal do vault do Sistema de Banco de Dados MySQL fornecido para o usuário Administrador e Replicação está no estado Disponível.
    • Valida se o segredo do vault do Sistema de Banco de Dados MySQL stand-by fornecido para o usuário Administrador e Replicação está no estado Disponível.
    • Valida se um canal Ativo está presente entre o Sistema de BD MySQL principal e o Sistema de BD MySQL de destino.
      Observação

      Em caso de falha, o Full Stack DR exibe uma advertência.
    • Valida a conectividade entre a instância do contêiner e os Nós do BD MySQL.
    • Valida se a execução do GTID está presente nos Sistemas de BD principal e de destino.
  • Failover:
    • Valida se o estado do ciclo de vida do Sistema de BD MySQL stand-by está no estado Ativo.
    • Valida se o Sistema de BD de destino está presente no Grupo de Proteção de DR de mesmo nível como membro, que também tem a propriedade do Sistema de BD de destino que corresponde ao OCID do Sistema de BD MySQL principal.
    • Valida se o Sistema de BD MySQL de destino está no modo Leitura.
    • Valida se o segredo do vault do Sistema de Banco de Dados MySQL stand-by fornecido para o usuário Administrador e Replicação está no estado Availabe.
    • Valida se um canal Ativo está presente entre o Sistema de BD MySQL principal e os Sistemas de BD MySQL de destino.
    • Valida a conectividade entre a instância do contêiner e os Nós do BD MySQL.
    • Valida se a execução do GTID está presente nos Sistemas de BD principal e de destino.
  • Iniciar Drill:
    • Valida se o estado do ciclo de vida do Sistema de BD MySQL para o Sistema de BD principal e stand-by está no estado Ativo.
    • Valida se o Sistema de BD de destino está presente no Grupo de Proteção de DR de mesmo nível como membro, que também tem a propriedade do Sistema de BD de destino que corresponde ao OCID do Sistema de BD MySQL principal.
    • Valida se o Sistema de Banco de Dados MySQL principal está no modo Leitura/Gravação.
    • Valida se o Sistema de BD MySQL de destino está no modo Leitura.
    • Valida se o backup está presente no Sistema de BD MySQL de destino a ser restaurado.
    • Valida se um canal Ativo está presente entre o Sistema de BD MySQL principal e os Sistemas de BD MySQL de destino.
  • Interromper Drill:

    Valida se o BD MySQL restaurado está presente na região de pareamento para ser limpo.

Tópico principal: Referência