Observação:

Este tutorial requer acesso ao Oracle Cloud. Para se inscrever em uma conta gratuita, consulte Conceitos Básicos do Oracle Cloud Infrastructure Free Tier.
Ele usa valores de exemplo para credenciais, tenancy e compartimentos do Oracle Cloud Infrastructure. Ao concluir seu laboratório, substitua esses valores por valores específicos do seu ambiente de nuvem.

Automatize o Cold Disaster Recovery para o Oracle HeatWave MySQL usando o OCI Full Stack Disaster Recovery

Introdução

O Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orquestra a transição de computação, banco de dados e aplicações entre regiões da OCI de todo o mundo com um único clique. Os clientes podem automatizar as etapas necessárias para recuperar um ou mais sistemas de negócios sem reprojetar ou rearquitetar a infraestrutura, os bancos de dados ou as aplicações existentes e sem precisar de servidores especializados de gerenciamento ou conversão.

O Oracle HeatWave MySQL é um serviço de banco de dados totalmente gerenciado implantado na Oracle Cloud Infrastructure (OCI) que suporta operadores e desenvolvedores que procuram implementar rapidamente aplicativos seguros e nativos da nuvem. O Oracle HeatWave MySQL é a única oferta do MySQL que inclui a capacidade de usar o HeatWave, um acelerador de consultas na memória integrado e de alto desempenho. O HeatWave permite que os clientes executem análises sofisticadas diretamente em seu banco de dados MySQL operacional, removendo o requisito de migração e integração de dados complexos, demorados e caros com um banco de dados de análise separado. O HeatWave acelera o desempenho do MySQL tremendamente para análises e cargas de trabalho mistas. O HeatWave é totalmente otimizado para a OCI e o Oracle HeatWave MySQL é 100% criado, gerenciado e suportado pelas equipes de engenharia da OCI e da MySQL.

Neste tutorial, você aprenderá a automatizar uma recuperação de desastres a frio para o Oracle HeatWave MySQL na OCI. Ele descreve os procedimentos para utilizar o serviço OCI Full Stack DR para gerenciar os processos de switchover e failover.

Observação: esse tipo de estratégia de DR (Recuperação de Desastre) depende de um mecanismo de Backup e Restauração, tornando-o mais adequado para aplicativos não críticos em que os requisitos de negócios para RTO (Recovery Time Objectives) e RPO (Recovery Point Objectives) não são excessivamente exigentes.

Descrição de Arquitetura

A arquitetura apresentada neste tutorial mostra uma aplicação WordPress em execução em máquinas virtuais (VMs) da OCI perfeitamente integradas ao Oracle HeatWave MySQL. Além disso, a configuração aproveita o serviço OCI File Storage como um compartilhamento NFS (Network File System) para armazenar o conteúdo WordPress. Esse armazenamento compartilhado é montado em cada VM, garantindo acesso imediato e sincronizado a todos os novos conteúdos em todo o ambiente.

Um Balanceador de Carga do OCI é implantado em uma sub-rede pública para gerenciar com eficiência conexões de usuários externos, distribuindo o tráfego de entrada nas VMs WordPress.

Descrição da Arquitetura da Recuperação de Desastres

A estratégia de DR para as VMs do aplicativo WordPress envolve uma abordagem abrangente, incluindo a replicação completa de cada volume de inicialização da VM com replicação do grupo de volumes e a utilização da replicação do File Storage para garantir a sincronização do conteúdo do WordPress.

Um balanceador de carga é pré-provisionado na região remota, garantindo que ele esteja pronto para lidar com o tráfego perfeitamente quando as VMs WordPress forem transferidas para a região remota durante um cenário de switchover ou failover.

Para o Oracle HeatWave MySQL, os backups são copiados regularmente para a região remota para garantir a proteção de dados e a prontidão para recuperação de desastres. Esse processo pode ser iniciado a partir de uma VM de aplicativo usando um script personalizado, que pode ser agendado por meio do crontab para execução automatizada e consistente.

O diagrama a seguir ilustra o workflow para copiar o backup MySQL mais recente disponível da região principal para a região remota.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

A seguinte configuração crontab foi configurada no usuário opc no Aplicativo WordPress VM1 para executar o script mds_copy_bkp.py a cada 4 horas. Isso garante a sincronização automática de backup para a região stand-by, contribuindo para a recuperação de desastres aprimorada:

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

Este job executa o script no minuto 15 passado a cada 4 horas.

Todos os scripts estão disponíveis em GitHub e são detalhados nas seções a seguir.

Observação: Certifique-se de programar este script (ou um semelhante) de acordo com seus requisitos de negócios para copiar regularmente o backup MySQL para a região remota. Sem essa etapa, o processo de restauração poderá falhar porque o backup não está disponível na região secundária.

Como funciona a recuperação?

Depois que um switchover planejado for executado, as atribuições serão revertidas: a carga de trabalho principal será executada na Região 2, enquanto o stand-by funcionará na Região 1. A arquitetura aparecerá da seguinte forma:

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

Na configuração atual, aproveitamos o serviço DNS privado do OCI para gerenciar um registro DNS que direciona o tráfego para o ponto final ativo do Oracle HeatWave MySQL. Durante o processo de recuperação, esse registro de DNS é atualizado por meio de um script personalizado para refletir o novo Oracle HeatWave MySQL, garantindo failover contínuo e continuidade do serviço.

O diagrama a seguir ilustra o workflow para restaurar o backup MySQL mais recente na região stand-by.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

A solução de recuperação para essa implantação requer que o OCI Full Stack DR execute uma série de scripts Python personalizados durante uma operação de recuperação, como um failover ou switchover. Os scripts mencionados neste tutorial são fornecidos pela equipe de Especialistas em Arquitetura de Nuvem da EMEA e disponíveis aqui: full-stack-disaster-recovery, especificamente adaptado para esta solução de DR.

Este tutorial explica como fazer download dos scripts e como usá-los em uma tarefa posterior.

Observação: Os scripts a seguir são fornecidos para orientação genérica. Você pode usar seus próprios scripts ou personalizar os scripts de acordo com a política corporativa e os requisitos de segurança.

Definições e Suposições ao longo do Tutorial

Regiões:
- Região 1 é Dubai: Dubai servirá inicialmente como a região principal. No entanto, essa atribuição fará a transição para stand-by durante o processo de switchover, que será executado nas tarefas posteriores como parte do plano de recuperação de desastres.
- A região 2 é Abu Dhabi: Abu Dhabi funcionará inicialmente como a região stand-by. Essa atribuição passará posteriormente para a principal após o processo de switchover, que será realizado nas tarefas subsequentes como parte do procedimento de recuperação de desastres.
Compartimentos: Você está livre para organizar essa implantação e o OCI Full Stack DR em qualquer esquema de compartimento que funcione dentro dos seus padrões de governança de TI. Escolhemos organizar todos os recursos do OCI para este tutorial em um único compartimento.

WordPress VMs de Aplicativos e Armazenamento de Arquivos do OCI

A arquitetura utilizada neste tutorial foi projetada em torno do OCI File Storage para garantir que todas as VMs de aplicativos tenham acesso compartilhado ao mesmo conteúdo WordPress.

Para obter mais informações sobre como montar corretamente o sistema de arquivos nas instâncias do Linux, consulte Configurando um Sistema de Arquivos para Montagem Automática (Instâncias do Linux).

Veja a seguir um exemplo da configuração do arquivo /etc/fstab para montar o sistema de arquivos na VM do aplicativo WordPress.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

Substitua xxx.xxx.xxx.xxx pelo endereço IP do ponto de acesso NFS localizado na Região 1 para garantir a conectividade adequada.

Objetivos

As seguintes tarefas serão abordadas neste tutorial:

Tarefa 1: Preparar o ambiente para Recuperação de Desastres
Tarefa 2: Criar Grupos de Proteção de DR (DRPG) em ambas as Regiões
Tarefa 3: Adicionar Membros ao Grupo de Proteção de DR
Tarefa 4: Criar Planos de DR Básicos na Região 2
Tarefa 5: Personalizar o Plano de Switchover na Região 2
Tarefa 6: Personalizar o Plano de Failover na Região 2
Tarefa 7: Executar as Pré-verificações dos planos de DR na Região 2
Tarefa 8: Executar o plano de switchover na Região 2
Tarefa 9: Criar e Personalizar os planos de DR na Região 1

Tarefa 1: Preparar o Ambiente para Recuperação de Desastres

Tarefa 1.1: Criar Grupos de Volumes e Ativar Replicação

Crie um grupo de volumes para as VMs de aplicativos WordPress na Região 1 e certifique-se de que ele seja replicado na Região 2. Certifique-se de que o volume de inicialização de cada VM de aplicativo (WordPress) seja um membro do grupo de volumes e que o grupo de volumes seja replicado para a Região 2.

A imagem a seguir ilustra a exibição do grupo de volumes criado, que inclui os volumes de inicialização das duas VMs de aplicativos WordPress, com a replicação ativada com sucesso para a Região 2. Para obter mais informações, consulte Criando um Grupo de Volumes.

Tarefa 1.2: Ativar Replicação do Serviço File Storage para Conteúdo WordPress

Na Região 2, crie um sistema de arquivos especificamente designado para replicação. Esse sistema de arquivos será usado para replicar dados perfeitamente da Região 1 para a Região 2.
Na Região 2, crie um ponto de acesso NFS que será usado durante o processo de recuperação da Região 1 para a Região 2.
Use o sistema de arquivos criado na etapa 1 para ativar e configurar a replicação do OCI File Storage de origem na Região 1.

A imagem a seguir ilustra os detalhes da replicação do File Storage para a Região 2.

Para obter mais informações, consulte Replicação do Sistema de Arquivos.

Tarefa 1.3: Preparar VMs de Aplicativos para Executar a Automação Personalizada

Instalar e configurar a Interface de Linha de Comando do Oracle Cloud Infrastructure (CLI do OCI). Para este tutorial, o Oracle Linux 8 é usado para a VM do aplicativo WordPress. Para obter mais informações, consulte Instalando a CLI.
Implante o script do repositório GitHub (mds_colddr_scripts) na pasta /home/opc.
Instale os pandas e tabule os módulos usados pelo script fornecido.
```
pip install pandas
pip install tabulate
```
Atualize o arquivo config.csv com os detalhes necessários para o Oracle HeatWave MySQL na Região 1.
- Substitua MYSQL_DB_SYSTEM_OCID pelo OCID do Oracle HeatWave MySQL. Você pode manter ou personalizar o label MySQL para se alinhar aos seus requisitos específicos.
- Substitua COMPARTMENT_OCID pelo OCID do compartimento no qual o sistema MySQL está localizado.
- Substitua PRIMARY_SUBNET_OCID e STANDBY_SUBNET_OCID pelos OCIDs da sub-rede nas duas regiões.
- Substitua PRIMARY_DNS_VIEW_OCID e STANDBY_DNS_VIEW_OCID pelos OCIDs das views DNS privadas associadas à zona DNS privada que gerencia o registro de ponto final do Oracle HeatWave MySQL.
Observação: certifique-se de que todos os valores sejam atualizados com precisão.

Como parte do tutorial, usaremos essa mesma VM para executar scripts definidos pelo usuário. Certifique-se de que a VM que atua como o Nó de Controle de DR tenha sido configurada para executar comandos. Para obter mais informações, consulte Chamar scripts personalizados usando o comando de execução com o Oracle Cloud Infrastructure Full Stack Disaster Recovery.

Tarefa 1.4: Criar Políticas do OCI IAM para o OCI Full Stack DR

Configure as políticas necessárias do OCI IAM para o OCI Full Stack DR conforme descrito nos documentos a seguir.

Tarefa 1.5: Criar Políticas do OCI IAM para outros Serviços gerenciados pelo OCI Full Stack DR

O OCI Full Stack DR deve ter a capacidade de controlar e gerenciar outros serviços importantes da OCI, como computação, rede, armazenamento e outros serviços diversos. Para configurar as políticas necessárias do OCI IAM para outros serviços, consulte Políticas de Outros Serviços Gerenciados pelo Full Stack Disaster Recovery e políticas do OCI IAM.

Tarefa 2: Criar Grupos de Proteção de DR (DRPG) em ambas as Regiões

Crie grupos de proteção de DR nas Regiões 1 e 2 se os grupos de proteção para esta pilha de aplicativos ainda não existirem.

Tarefa 2.1: Criar um Grupo de Proteção na Região 1

Vá para a Console do OCI e navegue até Grupos de Proteção de DR, conforme mostrado na Figura 2.1.
1. Certifique-se de que o contexto da região do OCI esteja definido como Região 1 (Dubai).
2. Clique em Migração e Recuperação de Desastre.
3. Clique em Grupos de Proteção de DR.
Figura 2.1: Navegue até grupos de proteção de DR
Crie um grupo básico de proteção de DR (DRPG) na Região 1, conforme mostrado na Figura 2.2. O par, a atribuição e os membros serão designados em etapas posteriores.
1. Selecione o compartimento no qual você deseja que o DRPG seja criado.
2. Clique em Criar grupo de proteção de DR para abrir a caixa de diálogo.
3. Use um nome significativo para o DRPG.
4. Selecione o bucket do OCI Object Storage para logs do OCI Full Stack DR.
5. Clique em Criar.
Figura 2.2: Parâmetros necessários para criar o grupo de proteção de DR na região 1

Tarefa 2.2: Criar um Grupo de Proteção na Região 2

Vá para a Console do OCI, navegue até Grupos de Proteção de DR, conforme mostrado na Figura 2.3.
1. Certifique-se de que o contexto da região do OCI esteja definido como Região 2 (Abu Dhabi).
2. Clique em Migração e Recuperação de Desastre.
3. Clique em Grupos de Proteção de DR.
Figura 2.3: Navegue até grupos de proteção de DR
Crie um grupo básico de proteção de DR (DRPG) na Região 2, conforme mostrado na Figura 2.4. O par, a atribuição e os membros serão designados em etapas posteriores.
1. Selecione o compartimento no qual você deseja que o DRPG seja criado.
2. Clique em Criar grupo de proteção de DR para abrir a caixa de diálogo.
3. Use um nome significativo para o DRPG.
4. Selecione o bucket do OCI Object Storage para logs do OCI Full Stack DR.
5. Clique em Criar.
Figura 2.4: Parâmetros necessários para criar o grupo de proteção de DR na região 2

Tarefa 2.3: Associar Grupos de Proteção na Região 1 e Região 2

Associe os DRPGs em cada região como pares entre si e designe as atribuições de pares principal e stand-by. As atribuições principal e stand-by são alteradas automaticamente pelo OCI Full Stack DR como parte de qualquer operação de DR/execução de plano de DR; não há necessidade de gerenciar as atribuições manualmente a qualquer momento.

Vá para a página Detalhes do grupo de proteção de DR.
1. Certifique-se de que o contexto da região do OCI esteja definido como Região 1 (Dubai).
2. Clique em Associar para iniciar o processo.
Figura: Iniciar associação de DRPG
Informe os parâmetros conforme mostrado na imagem a seguir.
1. Atribuição: Selecione a atribuição Principal. O OCI Full Stack DR designará a atribuição stand-by à Região 2 automaticamente.
2. Região de pareamento: Selecione a Região 2 (Abu Dhabi), na qual o outro DRPG foi criado.
3. Grupo de proteção de DR de pareamento: Selecione o DRPG de pareamento que foi criado.
4. Clique em Associar.
Fig: Parâmetros necessários para associar os DRPGs

O OCI Full Stack DR mostrará algo como mostrado na imagem a seguir, assim que a associação for concluída.

O DRPG principal atual é Dubai (região 1).
O atual DRPG stand-by é Abu Dhabi (região 2).

drpg-assoc-concluído-dxb.png
Figura: Mostrando o relacionamento de pares da perspectiva DRPG individual

As mesmas informações podem ser encontradas sempre que o contexto/view é de uma perspectiva global mostrando todos os grupos de proteção de DR, conforme mostrado na imagem a seguir.

O DRPG principal atual é Dubai (região 1).
O atual DRPG stand-by é Abu Dhabi (região 2).

drpg-assoc-concluído-dxb.png
Figura: Mostrando o relacionamento de pares da perspectiva DRPG global

Tarefa 3: Adicionar Membros ao Grupo de Proteção de DR

Nesta tarefa, adicionaremos os seguintes recursos do OCI ao DRPG principal na Região 1.

As duas instâncias de computação que hospedam o aplicativo WordPress serão adicionadas como VMs móveis. Além disso, certifique-se de que a seção Sistemas de Arquivos nas Opções Avançadas esteja configurada corretamente.
O grupo de volumes que contém o volume de inicialização dos nós de computação do aplicativo WordPress.
O Armazenamento de Arquivos do OCI contendo o conteúdo WordPress.
O balanceador de carga principal.

Tarefa 3.1: Adicionar Membros ao DRPG na Região 1

Selecione o DRPG na Região 1 conforme mostrado na imagem a seguir.
1. Certifique-se de que o contexto da região do OCI seja a Região 1 (Dubai).
2. Selecione o DRPG na Região 1.
3. Selecione Membros.
4. Clique em Adicionar Membro para iniciar o processo.
Fig: Como começar a adicionar membros ao grupo de proteção de DR na região 1
Adicione uma instância de computação para as VMs de aplicativos WordPress.
1. Confirmar aviso sobre planos de DR.
2. Informe o serviço Compute como um Tipo de recurso de membro.
3. Selecione a instância de computação que hospeda o aplicativo WordPress.
4. Selecione Instância móvel.
5. Clique em Adicionar mapeamento de VNIC para selecionar qual VCN e sub-rede designar à(s) VNIC(s) na Região 2 durante uma recuperação.
6. Clique em Mostrar opções avançadas.
7. Em Definições, selecione Manter domínio de falha.
8. Em Sistemas de Arquivos, conclua a seção de mapeamento de exportação de acordo com sua configuração, conforme mostrado nas imagens a seguir.
Fig: Parâmetros necessários para adicionar a VM do Aplicativo WordPress

Figura: Parâmetros necessários para mapear a VNIC na região 2

Fig: Opções avançadas, Manter domínio de falha

Figura: Opções avançadas, mapeamento de Sistemas de Arquivos

Figura: Instância de Computação Adicionada ao DRPG na Região 1

Observação: Repita as subetapas anteriores para todas as instâncias de computação das VMs do aplicativo WordPress.

Figura: Duas Instâncias de Computação Adicionadas ao DRPG na Região 1
Adicione o grupo de volumes em blocos que contém o volume de inicialização das VMs dos aplicativos WordPress.
1. Confirmar aviso sobre planos de DR.
2. Selecione Grupo de volumes como membro Tipo de recurso.
3. Certifique-se de que o compartimento correto que contém o grupo de volumes esteja selecionado e selecione o grupo de volumes.
Fig: Parâmetros necessários para adicionar o Grupo de Volumes para o serviço Compute WordPress

Figura: Grupo de Volumes para Computação WordPress Adicionada ao DRPG na Região 1
Adicione o Armazenamento de Arquivos do OCI que contém o conteúdo WordPress.
1. Confirmar aviso sobre planos de DR.
2. Selecione Sistema de Arquivos como membro Tipo de recurso.
3. Certifique-se de que o compartimento correto que contém o sistema de arquivos esteja selecionado e selecione o sistema de arquivos.
4. Selecione o Domínio de disponibilidade de destino a ser usado na Região 2.
5. Selecione Caminho de exportação de origem para este sistema de arquivos. Este caminho de exportação é criado na Região de destino 2 após restaurar o sistema de arquivos.
6. Selecione Destino de acesso NFS na Região 2 usada para criar uma exportação para o sistema de arquivos restaurado.
Fig: Parâmetros necessários para adicionar o conteúdo do Sistema de Arquivos para WordPress

Fig: Sistema de Arquivos para conteúdo WordPress Adicionado ao DRPG na Região 1
Adicione o OCI Load Balancer.

Neste exemplo, adicionaremos o balanceador de carga como membro do DRPG na Região 1.
1. Confirmar aviso sobre planos de DR.
2. Selecione Balanceador de Carga como Tipo de recurso do membro.
3. Certifique-se de que os compartimentos corretos para o balanceador de carga estejam selecionados e selecione o balanceador de carga que você deseja adicionar.
4. Selecione o Balanceador de carga de destino a ser usado na Região 2.
5. Selecione Conjunto de Backend de Origem; esse é o conjunto de backend usado pelas VMs dos aplicativos WordPress. Um Balanceador de Carga do OCI pode ser compartilhado entre vários aplicativos e pode ter vários conjuntos de backend configurados. Durante um switchover de DR, somente os conjuntos de backend especificados aqui terão sua configuração movida para a região stand-by.
6. Selecione Conjunto de Backend de Destino; este é o conjunto de backend vazio criado na Região 2.
Fig: Parâmetros necessários para adicionar o Balanceador de Carga

Fig: Balanceador de Carga Adicionado ao DRPG na Região 1

Tarefa 3.2: Adicionar Membros ao DRPG na Região 2

Selecione o DRPG na Região 2 conforme mostrado na imagem a seguir.
1. Certifique-se de que o contexto da região do OCI seja a Região 1 (Abu Dhabi).
2. Selecione o DRPG na Região 2.
3. Selecione Membros.
4. Clique em Adicionar Membro para iniciar o processo.
Fig: Como começar a adicionar membros ao grupo de proteção de DR na região 2
Adicione o OCI Load Balancer.

Neste exemplo, adicionaremos o balanceador de carga como membro do DRPG na Região 2.
1. Confirmar aviso sobre planos de DR.
2. Selecione Balanceador de Carga como Tipo de recurso do membro.
3. Certifique-se de que o compartimento correto para o balanceador de carga esteja selecionado e selecione o balanceador de carga que você deseja adicionar.
4. Selecione o Balanceador de carga de destino a ser usado na Região 1.
5. Selecione Conjunto de Backend de Origem; esse é o conjunto de backend usado pelas VMs dos aplicativos WordPress. Um Balanceador de Carga do OCI pode ser compartilhado entre vários aplicativos e pode ter vários conjuntos de backend configurados. Durante um switchover de DR, somente os conjuntos de backend especificados aqui terão sua configuração movida para a região stand-by.
6. Selecione Conjunto de Backend de Destino. Esse conjunto de backend é criado na Região 2.
Fig: Parâmetros necessários para adicionar o Balanceador de Carga

Fig: Balanceador de Carga Adicionado ao DRPG na Região 2

Tarefa 4: Criar Planos de DR Básicos na Região 2

Nesta tarefa, criaremos os planos de switchover e failover iniciais associados ao grupo de proteção de DR stand-by na Região 2 (Abu Dhabi).

O objetivo desses planos é fazer a transição perfeita da carga de trabalho da região principal (Região 1) para a região stand-by (Região 2). Como parte de qualquer operação de DR, as atribuições dos grupos de proteção de DR em ambas as regiões são automaticamente revertidas: o grupo de proteção na Região 1 torna-se o stand-by, enquanto o grupo de proteção na Região 2 assume a atribuição principal após um failover ou switchover.

O OCI Full Stack DR preencherá esses planos previamente com etapas incorporadas derivadas dos recursos de membro adicionados durante as tarefas anteriores. Posteriormente, esses planos serão personalizados para gerenciar tarefas específicas do Oracle HeatWave MySQL durante o processo de recuperação.

Os planos de switchover sempre são criados dentro do grupo de proteção que mantém a atribuição stand-by. Como a Região 2 (Abu Dhabi) é atualmente o grupo de proteção em espera, começaremos a criar os planos lá.

Tarefa 4.1: Criar Planos de DR

Crie um plano básico selecionando o DRPG na Região 2 (Abu Dhabi)
1. Certifique-se de que o contexto da região do OCI seja a Região 2 (Abu Dhabi).
2. Selecione o DRPG stand-by na Região 2.
3. Selecione Planos.
4. Clique em Criar Plano para iniciar o processo.
Fig: Como começar a criar planos básicos de DR na Região 2
Crie um plano de switchover.
1. Informe um Nome simples, mas significativo, para o plano de switchover. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
2. Selecione Tipo de plano como Switchover (planejado).
Fig: Os parâmetros necessários para criar o plano de switchover de DR
Criar um plano de failover.

Siga o mesmo processo para criar um plano de failover básico, conforme mostrado na imagem a seguir.
1. Informe o Nome do plano de failover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
2. Selecione Tipo de plano como Failover (não planejado).
Fig: Os parâmetros necessários para criar o plano de failover de DR

O grupo de proteção de DR stand-by na Região 2 agora deve ter os dois planos de DR, conforme mostrado na imagem a seguir. Eles tratarão da transição de cargas de trabalho da Região 1 para a Região 2. Você criará planos semelhantes na Região 1 para fazer a transição das cargas de trabalho da Região 2 de volta para a Região 1 em uma tarefa posterior.

Figura: Mostrando os dois planos básicos de DR que devem existir na região 2 antes de prosseguir

Tarefa 5: Personalizar o Plano de Switchover na Região 2

Os planos básicos de DR criados na Tarefa 4 contêm etapas pré-preenchidas para tarefas de recuperação que são incorporadas ao OCI Full Stack DR e não contêm nada para gerenciar tarefas de recuperação específicas do Oracle HeatWave MySQL. Esta tarefa explica como adicionar grupos de planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um switchover:

Crie um backup de banco de dados após o shutdown normal das VMs do aplicativo para garantir a consistência dos dados.
Transfira o backup de banco de dados mais recente para a OCI Region 2 remota para redundância e recuperação de desastres.
Restaure o backup de banco de dados mais recente na Região 2 para preparar o ambiente para switchover.
Atualize o registro de DNS do banco de dados privado, permitindo que as VMs dos aplicativos se conectem perfeitamente ao banco de dados na Região 2.
Encerre o banco de dados MySQL de origem na Região 1.

Tarefa 5.1: Selecionar o Plano de Switchover

Navegue até o plano de alternância criado na Tarefa 4.

Fig: Como começar a personalizar o plano de switchover na região 2

Tarefa 5.2: (Opcional) Ativar Grupos de Planos de DR que Encerram Artefatos

Há três grupos de planos que são desativados por padrão nos planos de switchover, conforme mostrado na imagem a seguir. Esses grupos de planos são desativados para fornecer segurança durante o teste, garantindo que nenhum artefato seja excluído e que uma cópia de backup viável permaneça intacta em caso de problemas durante a fase de teste.

No entanto, esses três grupos de planos foram projetados para encerrar (excluir) artefatos que não serão mais necessários para quaisquer operações futuras de DR. Sem esses grupos de planos ativados, os artefatos não utilizados continuarão a se acumular ao longo do tempo à medida que você executa alternâncias entre as duas regiões, o que pode levar a confusão sobre quais instâncias de computação, o OCI File Storage e os grupos de volumes devem estar ativos.

Opcionalmente, ativar esses grupos de planos agora ajudará a evitar a necessidade de limpeza manual de artefatos desnecessários antes de entrar em produção. Essa etapa proativa pode agilizar a transição para a produção e manter um ambiente mais limpo e gerenciável.

Figura: Grupos de planos desativados por padrão

Para ativar os grupos de planos, selecione Ativar todas as etapas no menu de contexto à direita do nome do grupo de planos.

Fig: Como ativar o encerramento do sistema de arquivos

Fig: Clique em Ativar para validar.

Fig: Como ativar o encerramento de instâncias de computação

Fig: Clique em Ativar para validar.

Fig: Como ativar o encerramento do Grupo de Volumes

Fig: Clique em Ativar para validar.

Tarefa 5.3: Reordenar Grupos de Planos de DR

É necessário montar o sistema de arquivos nas novas VMs movidas para a Região 2 antes de atualizar os conjuntos de backend do balanceador de carga. Isso garante que o aplicativo tenha acesso adequado aos recursos de armazenamento necessários, facilitando uma transição tranquila durante o processo de switchover.

Fig: Captura de tela mostrando a ordem inicial do plano de Switchover e como começar a reordenar

Fig: Inicie a reordenação

Mova Sistemas de Arquivos - Montagem em Instâncias do Serviço Compute antes de Balanceadores de Carga - Atualizar Conjuntos de Backend de Destino.
Clique em Salvar alterações.

Figura: Ordem do plano de Switchover Final

Tarefa 5.4: Criar um grupo de Planos para Executar Scripts Personalizados

Comece adicionando grupos de planos de DR personalizados e definidos pelo usuário para adaptar o workflow de DR às necessidades específicas do processo de DR de Backup/Restauração MySQL.

Esses grupos de planos chamarão os scripts necessários do WordPress VM1 na Região 1 e deverão ser posicionados no workflow de DR antes de iniciar as VMs do aplicativo WordPress. Isso garante que o banco de dados MySQL seja totalmente restaurado e operacional antes que as VMs dos aplicativos sejam colocadas on-line.

O seguinte plano personalizado deve ser adicionado ao plano de switchover pré-preenchido: Criar Backup do MySQL Database, Copiar Backup do MySQL Database, Restaurar Backup do MySQL Database, Atualizar DNS do MySQL Database e Encerrar Origem do MySQL Database.

Adicione um grupo de planos personalizado para criar o backup do banco de dados MySQL.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Create MySQL DB Backup.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Instâncias do Serviço Compute - Iniciar.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para criar o backup do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Criar Backup do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Create MySQL DB Backup. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione Instância de destino, que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar Adicionar uma Etapa Criar Backup de BD MySQL

Clique em Adicionar.

Fig: Adicione um grupo de planos Criar Backup do BD MySQL
Adicione um grupo de planos personalizado para copiar o backup do banco de dados MySQL.
1. Clique em Adicionar grupo.
2. Informe o Nome do grupo de planos simples, mas descritivo. Neste exemplo, usaremos Copy MySQL DB Backup.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Criar Backup do BD MySQL.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para copiar o Backup do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Copiar Backup do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Copy MySQL DB Backup. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para Adicionar um Backup de BD de Cópia de Etapa MySQL

Clique em Adicionar.

Fig: Adicione um grupo de planos Copiar MySQL Backup do BD
Adicione um grupo de planos personalizado para restaurar o backup do banco de dados MySQL.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Restore MySQL DB Backup.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Copiar Backup do BD MySQL.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para restaurar o backup do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Restaurar Backup do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Restore MySQL DB Backup. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para Adicionar um Backup de BD de Restauração de Etapa MySQL

Clique em Adicionar.

Fig: Adicione um grupo de planos Restaure o Backup do BD MySQL
Adicione um grupo de planos personalizado para atualizar o DNS do banco de dados MySQL.
1. Clique em Adicionar grupo.
2. Informe o Nome do grupo de planos simples, mas descritivo. Neste exemplo, usaremos Update MySQL DB DNS.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Restaurar Backup do BD MySQL.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para atualizar o DNS do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Atualizar o DNS do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Update MySQL DB DNS. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para Adicionar um DNS de BD de Atualização de Etapa MySQL

Clique em Adicionar.

Fig: Adicione um grupo de planos Atualizar o DNS do BD MySQL
Adicione um grupo de planos personalizado para encerrar o banco de dados de origem MySQL.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Terminate MySQL DB Source.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Sistemas de Arquivos - Remover do Grupo de Proteção de DR.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para encerrar a origem do banco de dados MySQL.
Figura: Parâmetros para criar o grupo de planos Encerrar o BD de Origem MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Terminate MySQL Source DB. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para Adicionar um Encerramento de Etapa MySQL Banco de Dados de Origem

Clique em Adicionar.

Fig: Adicione um grupo de planos Encerrar BD de Origem MySQL
(Opcional) Adicione um grupo de planos personalizado para interromper o aplicativo WordPress.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Application - Stop.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário no final após o grupo de planos incorporado Balanceadores de Carga - Atualizar Conjuntos de Backend de Origem.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para interromper o aplicativo.
Figura: Parâmetros para criar o grupo de planos Aplicativo - Interromper

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Stop - VM1.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_stop.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Interromper - VM1

Clique em Adicionar Etapa para adicionar uma segunda etapa para interromper o aplicativo em VM2.

Fig: Adicionar um Aplicativo de Etapa - Interromper - VM2

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Stop - VM2.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM2 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM2 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_stop.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Interromper - VM2

Clique em Adicionar.

Fig: Adicionar um grupo de planos Aplicativo - Interromper
(Opcional) Adicione um grupo de planos personalizado para iniciar o aplicativo WordPress.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Application - Start.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, selecione Adicionar Após para inserir nosso grupo de planos definido pelo usuário no final, após o grupo de planos incorporado Sistemas de Arquivos - Montagem em Instâncias do Serviço Compute.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para iniciar o aplicativo.
Figura: Parâmetros para criar grupo de planos Aplicativo - Iniciar

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Start - VM1.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Nesse caso, o script será executado no Aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_start.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Iniciar - VM1

Clique em Adicionar Etapa para adicionar uma segunda etapa para iniciar o aplicativo em VM2.

Fig: Adicione um Aplicativo de Etapa - Iniciar - VM2

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Start - VM2.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Nesse caso, o script será executado no Aplicativo WordPress VM2 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM2 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_start.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Iniciar - VM2

Clique em Adicionar.

Fig: Adicionar um grupo de planos Aplicativo - Iniciar

A personalização do plano de switchover foi concluída com sucesso.

Tarefa 6: Personalizar o Plano de Failover na Região 2

Nesta tarefa, adicione grupos de planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um failover.

Restaure o backup de banco de dados mais recente na Região 2 para preparar o ambiente para switchover.
Atualize o registro de DNS do banco de dados privado, permitindo que as VMs dos aplicativos se conectem perfeitamente ao banco de dados na Região 2.

Tarefa 6.1: Selecionar o Plano de Failover

Navegue até o plano de failover criado na Tarefa 4.

Fig: Como começar a personalizar o plano de Failover na região 2

Tarefa 6.2: Criar um grupo de Planos para Executar Scripts Personalizados na Região 2

Comece adicionando grupos de planos de DR personalizados e definidos pelo usuário para adaptar o workflow de DR às necessidades específicas do processo de DR de Backup/Restauração MySQL.

Esses grupos de planos chamarão os scripts necessários da VM do aplicativo WordPress e deverão ser posicionados no workflow de DR antes de reiniciar as VMs do aplicativo WordPress. Isso garante que o banco de dados MySQL seja totalmente restaurado e operacional antes que as VMs dos aplicativos sejam colocadas on-line.

O seguinte plano personalizado deve ser adicionado ao plano de failover pré-preenchido: Restaurar Backup do MySQL Database e Atualizar DNS do MySQL Database.

Adicione um grupo de planos personalizado para restaurar o backup do banco de dados MySQL.
1. Clique em Adicionar grupo para começar.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Restore MySQL DB Backup.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Instâncias do Serviço Compute - Iniciar.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para restaurar o backup do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Restaurar Backup do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Restore MySQL DB Backup. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para Adicionar um Backup de BD de Restauração de Etapa MySQL

Clique em Adicionar

Fig: Adicione um grupo de planos Restaure o Backup do BD MySQL
Adicione um grupo de planos personalizado para atualizar o DNS do banco de dados MySQL.
1. Clique em Adicionar grupo para começar.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Update MySQL DB DNS.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Restaurar Backup do BD MySQL.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para atualizar o DNS do banco de dados MySQL.
Fig: Parâmetros para criar o grupo de planos Atualizar o DNS do BD MySQL

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Update MySQL DB DNS. Igual ao nome do grupo de planos.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar Adicionar uma Atualização de Etapa MySQL DB DNS

Clique em Adicionar.

Fig: Adicione um grupo de planos Atualizar o DNS do BD MySQL
(Opcional) Adicione um grupo de planos personalizado para reiniciar o aplicativo WordPress.
1. Clique em Adicionar grupo.
2. Informe um Nome de grupo de planos simples, mas descritivo. Neste exemplo, usaremos Application - Restart.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Neste exemplo, selecione Adicionar após para inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado Sistemas de Arquivos - Montagem em Instâncias do Serviço Compute.
4. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para iniciar o aplicativo.
Figura: Parâmetros para criar grupo de planos Aplicativo - Reiniciar

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Restart - VM1.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM1 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM1 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_restart.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Reiniciar - VM1

Clique em Adicionar Etapa para adicionar uma segunda etapa para reiniciar o aplicativo em VM2.

Fig: Adicione um Aplicativo de Etapa - Reiniciar - VM2

Em Adicionar etapa do grupo de planos, especifique as informações a seguir.
1. Informe um Nome da etapa simples, mas descritivo. Neste exemplo, usaremos Application - Start - VM2.
2. Selecione uma região que contenha a instância na qual essa etapa será executada. Neste exemplo, o script será executado no aplicativo WordPress VM2 na Região 1.
3. Selecione Executar script local.
4. Selecione a Instância de destino que é o aplicativo WordPress VM2 na Região 1.
5. Em Parâmetros de script, informe o caminho completo do script com os parâmetros. Por exemplo: /home/opc/fsdrscripts/wdp_restart.sh.
6. Em Executar como usuário, digite opc.
7. Clique em Adicionar Etapa.
Fig: Parâmetros para criar um Aplicativo de Etapa - Reiniciar - VM2

Clique em Adicionar.

Fig: Adicionar um grupo de planos Aplicativo - Reiniciar

A personalização do plano de failover foi concluída com sucesso.

Tarefa 7: Executar Pré-verificações na Região 2

Os planos de DR de switchover e failover foram criados com sucesso na Região 2 stand-by. Esses planos permitem que o OCI Full Stack DR faça a transição de cargas de trabalho da Região 1 para a Região 2. A tarefa subsequente envolve a execução das pré-verificações para os planos de switchover e failover para garantir a prontidão e validar o processo de transição.

Tarefa 7.1: Iniciar Pré-verificações para o Plano de Switchover

Execute pré-verificações para o plano de DR de switchover.

Certifique-se de que o contexto da região esteja definido como Região stand-by 2.
Certifique-se de que o grupo de proteção de DR correto na Região 2 esteja selecionado; ele deve ser a atribuição stand-by.
Clique no nome do plano de switchover.
Clique em Run prechecks.

pré-verificações-so-auh-begin.png
Fig: Mostrando como executar pré-verificações do plano de switchover

pré-verificações-so-auh-complete.png
Fig: Mostrando pré-verificações Concluídas do plano de switchover

Tarefa 7.2: Iniciar Pré-verificações para o Plano de Failover

Execute as pré-verificações para o plano de DR de failover.

Certifique-se de que o contexto da região esteja definido como região stand-by 2.
Certifique-se de que o grupo de proteção de DR correto na Região 2 esteja selecionado; ele deve ser a atribuição stand-by.
Clique no nome do plano de failover.
Clique em Run prechecks.

pré-verificações-fo-auh-begin.png
Fig: Mostrando como executar pré-verificações do plano de failover

pré-verificações-fo-auh-complete.png
Fig: Mostrando pré-verificações Concluídas do plano de failover

Tarefa 8: Executar o Plano de Switchover na Região 2

Execute o plano de DR de switchover para iniciar o processo de transição do aplicativo WordPress com o Oracle HeatWave MySQL da Região 1 para a Região 2.

Certifique-se de que o contexto da região esteja definido como Região stand-by 2.
Certifique-se de que o grupo de proteção de DR correto na Região 2 esteja selecionado; ele deve ser a atribuição stand-by.
Clique no nome do plano de switchover.
Clique em Executar plano.

Esta tarefa executa o plano de switchover na Região 2.

Desmarque Ativar pré-verificações, pois elas já foram executadas na Tarefa 7.
Clique em Executar plano de DR para começar.

Fig: Mostrando como Executar o plano de switchover

Figura: Mostrando o plano de switchover em Andamento

Monitore o plano de switchover até que a carga de trabalho completa tenha sido totalmente alterada da Região 1 para a Região 2.

A execução do plano de switchover foi concluída com êxito em aproximadamente 52 minutos.

Fig: Mostrando uma execução do plano de switchover Concluído.

Tarefa 9: Criar e Personalizar planos de DR na Região 1

Com a conclusão bem-sucedida do switchover pelo OCI Full Stack DR, a Região 2 agora assumiu a função de região principal, enquanto a Região 1 fez a transição para servir como a região stand-by.

Siga a mesma abordagem detalhada na Tarefa 1 a 8, continue criando e personalizando os planos de switchover e failover no grupo de proteção de DR para a Região 1, que agora serve como a região de pareamento stand-by.

criação do plano-dxb.png
Fig: Captura de tela mostrando planos Criados na Região 1

Figura: Captura de tela mostrando o plano de Switchover na Região 1

Fig: Captura de tela mostrando o plano de Failover na Região 1

Próximas Etapas

Para obter mais informações, consulte a documentação do OCI Full Stack DR e do Oracle HeatWave MySQL na seção Links Relacionados.

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery
Oracle HeatWave MySQL
Full Stack Disaster Recovery do OCI
HeatWave MySQL
Participe do canal de folga #full-stack-dr

Confirmações

Autor - Antoun Moubarak (Hiperescalador para Especialista em OCI)
Colaborador - Suraj Ramesh (Gerente de Produto do OCI Full Stack DR)

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24414-01

January 2025

Oracle e/ou suas empresas afiliadas.