Planejar DR para Bancos de Dados
Você pode usar o Oracle GoldenGate, o Active Data Guard e o Autonomous Data Guard para implementar o DR para seus bancos de dados implantados no Oracle Cloud.
- O Active Data Guard oferece proteção de dados abrangente, alta disponibilidade e recuperação de desastres para o Oracle Database de forma simples e econômica, mantendo uma réplica física (standby) sincronizada de um banco de dados de produção em um local remoto. O banco de dados standby é aberto somente para leitura durante a transferência de redo, validação e recuperação.
Ao contrário dos métodos típicos de replicação de armazenamento, o Active Data Guard replica apenas os redo logs na memória e valida a replicação para evitar qualquer chance de corrupção.
- O Oracle GoldenGate é um produto de replicação lógica avançada que suporta replicação multimestre, implantação de hub e spoke e transformação de dados. O GoldenGate oferece aos clientes opções flexíveis para tratar da gama completa de requisitos de replicação, incluindo plataformas de hardware heterogêneas.
- O Autonomous Data Guard fornece proteção de dados e recuperação de desastres para suas instâncias de banco de dados autônomas no Oracle Cloud. Quando você ativa o Autonomous Data Guard para uma instância de banco de dados autônomo, um banco de dados standby é criado na mesma região. Em regiões com mais de um domínio de disponibilidade, o stand-by é provisionado em um domínio de disponibilidade diferente do banco de dados principal. Em regiões com um único domínio de disponibilidade, o stand-by é provisionado em uma máquina física diferente do banco de dados principal. O Autonomous Data Guard monitora a instância principal e faz failover automaticamente para o banco de dados stand-by se o banco de dados principal ficar indisponível.
Sobre o Oracle Maximum Availability Architecture
Cada uma das camadas MAA a seguir usa um conjunto ideal de recursos da Oracle que, quando implantados juntos, atingem de forma confiável os níveis de serviço de destino para interrupções não planejadas e eventos de manutenção planejados:
- Bronze
A camada Bronze fornece o serviço de banco de dados básico com o menor custo possível. Um nível reduzido de alta disponibilidade e proteção de dados é aceito em troca da complexidade de custo e implementação reduzida. Essa arquitetura pode ser adequada para bancos de dados usados para teste, desenvolvimento e aplicativos e bancos de dados de produção menos críticos.
A arquitetura usa os recursos de alta disponibilidade incluídos no Oracle Enterprise Edition. O padrão Bronze é a arquitetura de instância única ou multitenant do Oracle Database. Os recursos de alta disponibilidade do Oracle Restart ou do Oracle Clusterware são usados para reiniciar uma instância com falha, um servidor de banco de dados ou qualquer serviço gerenciado relevante. Para corrupções lógicas, como erro humano, você pode usar operações de Flashback para "reenviar" o banco de dados para um ponto específico no tempo. No pior cenário de uma interrupção completa do site, há tempo adicional necessário para restaurar e recuperar o sistema e o banco de dados dos backups que podem resultar em horas ou dias de inatividade.
Um backup local dentro do mesmo data center é sempre recomendado para a recuperação mais rápida. A Oracle também recomenda a manutenção de uma segunda cópia dos backups em um data center remoto para se proteger contra interrupções e desastres do site. Você pode usar o Oracle Database Backup Cloud Service para manter um backup baseado em nuvem de bancos de dados locais.
- Silver
A camada Silver foi projetada para bancos de dados que não podem esperar uma reinicialização a frio ou uma restauração do backup, caso haja uma falha irrecuperável no servidor ou na instância do banco de dados. Essa arquitetura pode ser adequada para aplicativos de produção que são essenciais aos negócios e precisam reduzir o tempo de inatividade para falhas locais e atividades de manutenção planejadas mais comuns.
A arquitetura Silver é criada com base na arquitetura Bronze e adiciona o cluster ativo/ativo do Oracle Real Application Clusters (Oracle RAC) para tempo de inatividade mínimo ou zero no caso de falha no servidor ou na instância do banco de dados, bem como tempo de inatividade zero no banco de dados para os eventos de manutenção planejados mais comuns.
Assim como na arquitetura Bronze, o Recovery Manager (RMAN) fornece backups otimizados para o banco de dados para restaurar a disponibilidade caso haja uma interrupção completa do cluster ou um desastre.
- Ouro
O nível Ouro foi projetado para requisitos de nível de serviço que não podem tolerar longos períodos de inatividade e perda de dados. Esse conjunto de padrões de arquitetura fornece alta disponibilidade e proteção de dados abrangente para todos os tipos de paralisações não planejadas, incluindo danos a dados, falhas no banco de dados e paralisações no local. Aplicativos de produção de missão crítica que exigem tempo de recuperação rápido e perda de dados mínima ou zero para todas as paralisações de banco de dados e sistema e atividades de manutenção planejadas se beneficiarão dos recursos incluídos na arquitetura de referência Gold.
A arquitetura de referência Gold, baseada na arquitetura de referência Silver, fornece quatro padrões de arquitetura usando o Oracle Active Data Guard. Os padrões variam de um stand-by ativo remoto único com Failover de Início Rápido e Observador de HA, para várias configurações de banco de dados stand-by, incluindo propriedades do leitor stand-by, e finalmente uma configuração stand-by de perda de dados zero (entre regiões).
- Platina
O nível Platinum tem o potencial de fornecer tempo de inatividade zero para interrupções e atividades de manutenção planejadas que não podem ser alcançadas com a arquitetura Gold. A arquitetura Platinum se baseia na arquitetura Gold adicionando a replicação do Oracle GoldenGate para eliminar o tempo de inatividade para migrações, upgrades de aplicativos e upgrades de bancos de dados. Cada banco de dados Oracle GoldenGate é protegido por um banco de dados standby para permitir zero perda de dados no caso de falha no banco de dados, no cluster ou no site.
Diferentemente de outras arquiteturas MAA, considerações de aplicativo são necessárias para integrar o Oracle GoldenGate à arquitetura, a fim de garantir que a detecção e a resolução de conflitos sejam executadas corretamente. O Global Data Services, ou o gerenciamento de serviços de aplicativos personalizados, também pode ser necessário para obter um período de indisponibilidade zero dos aplicativos para atividades como upgrades de migração e banco de dados.
Usar Data Guard Ativo
Benefícios do Active Data Guard
O Active Data Guard oferece vários benefícios.
- Replicação física segura.
O banco de dados standby é aberto somente para leitura, e sua consistência é garantida.
Observe que, a partir do Oracle Database 19c, você pode emitir atualizações ocasionais e inserir instruções no banco de dados standby, o que redireciona as instruções para o banco de dados principal.
- Replicação simples, rápida e unidirecional de um Oracle Database completo.
A configuração padrão trata a maioria das cargas de trabalho; portanto, há pouca sobrecarga administrativa.
- Sem restrições.
O Oracle Data Guard Redo Apply suporta todos os recursos da Oracle e replica de forma transparente todos os tipos de dados e armazenamento, pacotes PL/SQL e DDL sem considerações especiais.
- Melhor proteção de dados.
A replicação direta da memória isola o banco de dados stand-by do corrompimento de Entrada/Saída que pode ocorrer no banco de dados principal. Detecta corrupção silenciosa de gravação perdida que pode ocorrer de forma independente no banco de dados principal ou standby. Detecta e repara automaticamente a corrupção do bloco físico que pode ocorrer de forma independente no banco de dados principal ou standby.
- Opção síncrona com perda de dados zero ou assíncrona com proteção de perda de dados quase zero.
- RoI aprimorado.
Você pode descarregar cargas de trabalho somente para leitura, como aplicativos de relatório, consultas ad-hoc e extrações de dados para um standby físico sincronizado.
- Um único comando converte um banco de dados stand-by físico como um sistema de teste para abrir a leitura/gravação. Um segundo comando o converte de volta para um banco de dados standby físico e o ressincroniza com o banco de dados principal. Os dados primários são sempre protegidos.
- Gerenciamento integrado de uma configuração completa com a linha de comando do Oracle Data Guard Broker e failover automático do banco de dados.
- Suportado para banco de dados de nó único ou banco de dados de vários nós (Cluster de Aplicativo Real).
- Continuidade do aplicativo, para proteção in-flight de suas transações.
O Active Data Guard mascara interrupções de banco de dados de usuários finais e aplicativos, recuperando o trabalho em andamento para sessões de banco de dados afetadas.
Modos de Configuração
- Proteção MáximaEste modo de proteção não fornecerá perda de dados se o banco de dados principal falhar. Para garantir que haja perda de dados, o banco de dados será encerrado se uma falha o impedir de gravar seu fluxo de redo no redo log stand-by de pelo menos um banco de dados stand-by.
Observação:
Este modo não está disponível para bancos de dados autônomos. Para o Exadata Cloud Service e o Exadata Cloud@Customer, você pode configurar esse modo manualmente, mas o plano de controle da nuvem não o refletirá. - Disponibilidade Máxima
Este modo de proteção fornece o mais alto nível de proteção de dados possível sem comprometer a disponibilidade do banco de dados principal. Assim como no modo de Proteção Máxima, uma transação é submetida a commit apenas depois que o redo necessário para recuperar essa transação é gravado no redo log on-line local e no redo log stand-by de pelo menos um banco de dados stand-by transacionalmente consistente. Diferentemente do modo Proteção Máxima, o banco de dados principal não faz shutdown se uma falha impedir que ele grave seu fluxo de redo em um redo log stand-by remoto. Em vez disso, o banco de dados principal e a configuração do Data Guard têm downgrade para o estado
UNSYNCHRONIZED
. Quando pelo menos um standby estiver disponível, o standby será ressincronizado automaticamente. - Desempenho Máximo
Este modo de proteção (o padrão) fornece o mais alto nível de proteção de dados possível sem afetar o desempenho do banco de dados principal. Isso é feito permitindo que uma transação seja submetida a commit quando os dados de redo necessários para recuperar essa transação forem gravados de forma assíncrona no redo log on-line local. Quando links de rede com largura de banda suficiente são usados, este modo fornece um nível de proteção de dados que se aproxima do do modo de Disponibilidade Máxima com impacto mínimo no desempenho do banco de dados principal.
Considerações sobre Posicionamento do BD
Para melhorar a disponibilidade e a recuperação de desastre, coloque o sistema de BD do banco de dados standby em um domínio de disponibilidade diferente do sistema de BD do banco de dados principal.
Se você ativar o Data Guard para um banco de dados e seu banco de dados stand-by estiver no mesmo domínio de disponibilidade que o principal (por opção ou porque a região tem um único domínio de disponibilidade), coloque o banco de dados stand-by em um domínio de falha diferente daquele do banco de dados principal.
Se seus bancos de dados principal e standby forem sistemas de BD de máquina virtual de 2 nós e ambos estiverem no mesmo domínio de disponibilidade, recomendamos distribuir todos os quatro nós (dois para principal e dois para standby) entre os três domínios de falha do domínio de disponibilidade. Essa configuração garante a mais alta disponibilidade possível, aproveitando todos os três domínios de falha. Nesse cenário, apenas um dos dois nós do banco de dados standby pode estar em um domínio de falha que não inclua outros nós do banco de dados principal ou standby.
Para garantir transições de atribuição ideais entre o banco de dados principal e o standby, a Oracle recomenda que você dimensione e configure os dois bancos de dados de forma simétrica.
Melhores Práticas de Configuração
Consulte "Oracle Data Guard Best Practices" no Oracle Database High Availability Overview and Best Practices.
Usar o Oracle GoldenGate
- Requisitos avançados de replicação, como replicação multimestre e bidirecional, replicação de subconjunto, replicação muitos para um, replicação cross-endian e transformações de dados
- Manutenção e migrações que exigem zero tempo de inatividade usando replicação bidirecional
- Migração entre plataformas que não é suportada pelo Data Guard (por exemplo, migração de plataforma cross-endian)
- Suporte para sistemas distribuídos de versão do BD cruzado (por exemplo, a réplica 1 está na versão 12.2 e a réplica 2 está na versão 19c)
- Suporte para plataformas de BD cruzado (por exemplo, a réplica 1 está no Oracle e a réplica 2 não é no Oracle DB)
Modos de Configuração
Use a arquitetura de Microsserviços do Oracle GoldenGate, que fornece uma plataforma de replicação segura, abrangente e escalável na nuvem. Para minimizar a sobrecarga nos servidores de banco de dados, a Oracle recomenda que você implante GoldenGate na configuração do hub.
GoldenGate suporta várias topologias, conforme mostrado no diagrama a seguir. Escolha um modo adequado ao seu caso de uso.
Melhores Práticas de Configuração
Como o Oracle GoldenGate replica dados no nível transacional, recomendamos implementar o CDR (Conflict Detection and Resolution) para obter consistência de dados entre dois sites. Os conflitos são identificados imediatamente e tratados com scripts automatizados.
Se você estiver usando GoldenGate principalmente para fins de DR e a replicação for apenas uma forma, recomendamos adicionar o Data Guard entre duas regiões. Isso fornece uma solução sem perda de dados com forte consistência de dados entre a instância principal e o Data Guard. Essa configuração também alivia a sobrecarga da execução da extração GoldenGate do banco de dados principal.

Descrição da ilustração db-dg-gg.png
Observação:
A arquitetura mostra vários domínios de disponibilidade (ADs). Para uma região que tenha um único AD, ajuste a arquitetura para distribuir seus recursos entre os domínios de falha dentro do AD.
Implante o Oracle GoldenGate também em uma configuração de HA. Você pode usar a replicação do Oracle ASM Cluster File System (ACFS) para arquivos críticos GoldenGate.
Usar o Active Data Guard e o GoldenGate
O Oracle GoldenGate e o Active Data Guard não são mutuamente exclusivos. Você pode usá-los juntos para obter um RPO (Recovery Point Objective) de zero (ou seja, sem risco de perda de dados), porque GoldenGate é por natureza assíncrona, enquanto o Active Data Guard pode fornecer replicação síncrona, juntamente com outros recursos-chave, como validação de bloqueio de dados, reparo automático em blocos e continuidade de aplicativos.
- Use um standby Active Data Guard para proteção de desastre e upgrades contínuos do banco de dados para um banco de dados OLTP essencial. Use GoldenGate para extrair dados do banco de dados principal do Data Guard (ou do banco de dados standby usando o modo ALO GoldenGate) para atualização ETL de um data warehouse empresarial.
- Use a replicação de subconjunto GoldenGate para extrair, transformar e agregar dados de diversas origens de dados em um armazenamento de dados operacional central (ODS). O ODS suporta sistemas de aplicativos de missão crítica que geram receita significativa para a empresa. Use um banco de dados standby Active Data Guard para proteger o ODS, fornecendo proteção e disponibilidade ideais para os dados.
- Use a replicação multimestre GoldenGate para sincronizar vários bancos de dados, cada um localizado em diferentes regiões geográficas. Cada cópia GoldenGate tem seu próprio banco de dados stand-by do Data Guard síncrono local que permite failover de perda de dados zero se ocorrer uma interrupção.
Observação:
Para implementar a arquitetura de disponibilidade máxima no nível Platinum, use o Oracle Real Application Clusters (Oracle RAC), o Active Data Guard, bem como o Oracle GoldenGate.