Opções de recuperação de desastres para cargas de trabalho de bancos de dados Oracle
Este guia descreve as opções de recuperação de desastres disponíveis para os usuários que executam cargas de trabalho de bancos de dados Oracle de missão crítica em um ambiente da Solução Bare Metal.
Este guia pressupõe que você esteja executando o Oracle Enterprise Edition. Alguns dos recursos descritos neste guia são licenciados separadamente fora de uma licença Enterprise Edition. Alguns desses recursos incluem, entre outros:
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Consulte seus contratos de licença da Oracle para determinar quais recursos você tem direito de usar ao planejar a recuperação de desastres e a alta disponibilidade.
RTO e RPO do aplicativo
A recuperação de desastres para tecnologias de banco de dados do Oracle precisa ser determinada com base no objetivo de tempo de recuperação (RTO) e no objetivo do ponto de recuperação (RPO) de um aplicativo. Em geral, o RTO descreve o tempo de inatividade aceitável para um sistema, e o RPO descreve a quantidade de perda de dados aceitável. O custo e a complexidade de um sistema aumentam à medida que cada um desses valores diminui. Para mais informações sobre RTO e RPO, consulte Noções básicas do planejamento de DR.
As arquiteturas marcadas como "RPO = 0" ou "perda de dados zero" exigem que os dados sejam gravados em vários locais antes de serem considerados "confirmados" no banco de dados. A latência se torna um problema à medida que o RPO se aproxima de zero.
A implementação de uma arquitetura de perda zero de dados pode ter efeitos adversos no desempenho geral do aplicativo, a menos que seja devidamente considerada durante a fase de design.
Alta disponibilidade x recuperação de desastres
Alta disponibilidade e recuperação de desastres são conceitos complementares ao projetar arquiteturas de banco de dados confiáveis. No contexto deste guia, alta disponibilidade se refere à capacidade de um sistema se recuperar automaticamente de falhas individuais ou em cascata no sistema. Por outro lado, a recuperação de desastres faz parte de um plano geral de continuidade de negócios e se aplica a falhas maiores que podem deixar grupos inteiros de sistemas indisponíveis. A recuperação de desastres abrange um escopo maior devido ao número de componentes integrados que precisam ser recuperados em caso de desastre.
A alta disponibilidade precisa ser considerada a "primeira linha de defesa" ao projetar um sistema confiável. Uma arquitetura de banco de dados altamente disponível precisa ser capaz de suportar falhas individuais e continuar funcionando sem causar inatividade para o aplicativo. Os componentes de alta disponibilidade de um sistema precisam incluir, entre outros:
- Alimentação redundante em servidores, redes ou hardwares de armazenamento
- Várias interfaces de rede, switches e cabos
- Tecidos, controladores e dispositivos de disco de armazenamento redundantes
- Interconexões por parceiro tolerantes a falhas entre o Google Cloud e a extensão regional da Solução Bare Metal
- Oracle RAC para evitar que falhas no servidor desativem um banco de dados
Um design de recuperação de desastres precisa incluir processos para se recuperar de várias falhas em cascata que deixam os componentes indisponíveis. O planejamento de recuperação de desastres precisa considerar o seguinte:
- Interrupções regionais
- Desastres naturais
- Incidentes que resultam na interrupção total de um ou mais componentes de um aplicativo
Ferramentas de recuperação de desastres e alta disponibilidade do Oracle
Confira a seguir algumas ferramentas de recuperação de desastres e alta disponibilidade do Oracle:
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- banco de dados flashback
- Oracle GoldenGate
Oracle Real Application Clusters
O Oracle Real Application Clusters (RAC) é usado para escalonar horizontalmente as cargas de trabalho do banco de dados para serem atendidas por vários servidores de banco de dados. Os bancos de dados que usam o RAC permitem uma configuração ativa/ativa entre servidores em uma extensão de região.
O RAC geralmente é usado para fornecer alta disponibilidade a sistemas que precisam se proteger contra a falha de um único servidor. Devido à abordagem "tudo compartilhado" (armazenamento e redes compartilhados) para agrupamento, um cluster RAC em execução no ambiente da Solução Bare Metal precisa existir em um único pod da Solução Bare Metal. Isso torna o RAC uma solução para problemas de alta disponibilidade, mas não resolve o requisito de recuperação de desastres.
Para saber como configurar o RAC para a Solução Bare Metal, consulte Instalar o Oracle RAC na Solução Bare Metal.
Oracle Recovery Manager
O Oracle Recovery Manager (RMAN) é a ferramenta principal para backup e recuperação de bancos de dados Oracle devido à capacidade de ler o formato de arquivo de dados proprietária do Oracle. Ele pode ser usado para realizar clones de banco de dados, recuperação pontual ou até mesmo a recuperação de uma única tabela em um banco de dados Oracle.
O RMAN é a única ferramenta que pode ser usada para fazer backups enquanto o banco de dados está aberto. Ele também é usado para manter o catálogo de arquivos de backup disponíveis para recuperação.
Oracle Data Guard
O Oracle Data Guard executa a replicação de bancos de dados para clusters RAC remotos ou outras instalações de banco de dados. O Data Guard oferece suporte a bancos de dados de espera em uma configuração física ou lógica.
Os bancos de dados de reserva físicos são cópias de bloco por bloco que permitem que uma cópia do banco de dados seja aberta para gravação. Todas as outras são montadas (mas não abertas) para aplicar mudanças ou abertas somente leitura para oferecer suporte a aplicativos de relatórios.
Para saber como configurar o Data Guard na Solução Bare Metal, consulte Implantar o Oracle Data Guard na Solução Bare Metal.
FLASHBACK DATABASE
O recurso FLASHBACK DATABASE do Oracle Enterprise Edition permite que os administradores
retornem rapidamente um banco de dados para um ponto específico no tempo sem precisar
realizar restaurações de banco de dados demoradas.
No contexto da recuperação de desastres, o FLASHBACK DATABASE é usado com frequência em
conjunto com o Data Guard durante operações de failover para restabelecer o banco de dados
mais rapidamente. O banco de dados com falha é revertido para um ponto específico no tempo
que é consistente com os registros no novo primário, e a repetição é enviada para que ele
possa se ressincronizar totalmente.
Oracle GoldenGate
O Oracle GoldenGate é uma ferramenta de replicação lógica usada com frequência para
ativar implantações multisite ativas/ativas ou mover dados entre plataformas
de hardware. Ao usar o GoldenGate, um processo extract no banco de dados de origem
captura as mudanças nos registros de repetição on-line e as grava em mudanças para arquivos de trilha, que são transportados para o banco de dados de destino. Um processo replicat no banco de dados de destino converte transações dos arquivos de cauda em SQL e executa o SQL no banco de dados de destino.
Essa arquitetura torna o GoldenGate uma ferramenta poderosa para mover dados entre plataformas de banco de dados ou transformar dados conforme eles são replicados. Ao contrário do Data Guard, o GoldenGate exige que um software separado seja instalado e mantido nos sistemas de origem e de destino. O GoldenGate não pode ser usado para a replicação síncrona porque as transações são traduzidas e aplicadas como SQL no banco de dados de destino. Embora o GoldenGate possa fornecer um atraso mínimo para a replicação, ele sozinho não pode garantir um RPO de zero.
Modelos de implantação de recuperação de desastres (somente banco de dados)
A Oracle criou a estrutura de arquitetura de disponibilidade máxima (MAA) para fornecer modelos de recuperação de desastres recomendados para implantar seus aplicativos e bancos de dados.
Cada um dos modelos a seguir fornece metas específicas de RTO e RPO:
Os modelos são mapeados para padrões de implantação específicos que atendem ao RPO e RTO em eventos de falhas planejadas e não planejadas. Cada carga de trabalho do banco de dados precisa ser avaliada quanto aos requisitos de disponibilidade e projetada com um modelo correspondente. É comum que os bancos de dados de desenvolvimento usem um modelo com nível de proteção menor do que os de produção e de controle de qualidade.
O modelo Bronze é destinado a bancos de dados que não precisam de um RTO medido em minutos. Os modelos de nível Prata e superior incluem bancos de dados reserva em execução em um site remoto. Cada modelo incorpora a funcionalidade dos modelos de nível inferior. Por exemplo, o modelo Bronze usa conceitos de backup e recuperação que ainda precisam ser seguidos, mesmo que um banco de dados reserva seja implantado.
Modelo de cobre
O modelo Copper oferece uma implantação mínima para fazer backup de bancos de dados em mídias de armazenamento local e copiar para armazenamento que fica fora da extensão da região. Essa implantação requer uma abordagem em dois estágios, mas pode ser programada para usar o SDK Google Cloud para automatizar a transmissão de backups.
O uso dessa implantação também aumenta o RTO devido à recuperação em duas etapas que é necessária. O RMAN não pode acessar os backups diretamente. Portanto, eles precisam ser movidos para um local disponível para o RMAN antes que a recuperação possa começar.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupção | O último backup completo, incremental ou de registro de log que foi transferido para fora do RE | Horas, dependendo do tamanho do banco de dados e da largura de banda atribuída à Interconexão por parceiro | |
| Desastres: falhas na extensão da região | O último backup completo, incremental ou de registro em arquivo que foi transferido para fora do RE | Dias ou semanas, dependendo do tempo necessário para colocar a extensão da região on-line novamente | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas |
Modelo de bronze
O modelo Bronze oferece duas opções de implantação. Ambos usam o armazenamento nativo do Google Cloud para manter backups do banco de dados.
Implantação Bronze 1: backup no armazenamento regional
Nessa implantação, os backups são gravados diretamente em mídias externas. Na maioria dos casos, o destino de backup preferencial é o Cloud Storage com o Cloud Storage FUSE, que apresenta um bucket do Cloud Storage como um sistema de arquivos.
As recomendações para usar o Cloud Storage FUSE podem ser encontradas em Backups do Oracle com NFS e Cloud Storage. O Google Cloud Filestore, que apresenta compartilhamentos NFS às instâncias da Solução Bare Metal, também pode ser usado.
O diagrama a seguir mostra um exemplo de implantação.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupção | Último backup completo, incremental ou de registro de arquivo | Horas, dependendo do tamanho do banco de dados e da largura de banda atribuída à Interconexão por parceiro | |
| Desastres: falhas na extensão da região | Último backup completo, incremental ou de registro de arquivo | Dias ou semanas, dependendo do tempo necessário para colocar a extensão da região on-line novamente | |
| Planejado | Correções de banco de dados, atualizações do SO/FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas |
Implantação Bronze 2: backup usando o serviço de backup e DR
Nesta implantação, o serviço de backup e DR é usado para armazenar backups no Google Cloud. O backup e a DR oferecem uma abordagem incremental para backups, que são armazenados em mídias de alto desempenho com suporte do Cloud Storage para retenção de longo prazo.
O backup e a recuperação de desastres também oferecem um RTO mais rápido do que o armazenamento de backups no Filestore ou no Cloud Storage, já que podem disponibilizar imediatamente imagens de arquivos de banco de dados para a instância do Oracle. O recurso de montagem e migração coloca um banco de dados on-line rapidamente enquanto copia de volta para a mídia de armazenamento de produção, reduzindo drasticamente o RTO.
O diagrama a seguir mostra um exemplo de implantação.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupção | Último backup completo, incremental ou de registro de arquivo | De minutos a horas, dependendo dos requisitos de desempenho, do tamanho do banco de dados e da largura de banda atribuída à Interconexão por parceiro | |
| Desastres: falhas na extensão da região | Último backup completo, incremental ou de registro de arquivo | Dias ou semanas, dependendo do tempo necessário para colocar a extensão da região de volta on-line ou a capacidade do cliente de mudar para outra extensão da região. | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas |
Silver
O modelo Silver apresenta a replicação de banco de dados usando o Oracle Data Guard. O Data Guard fornece replicação de banco de dados em tempo real com um ou mais bancos de dados atuando como um banco de dados de espera. Como o Data Guard depende do transporte e da aplicação de mudanças no banco de dados à medida que elas ocorrem, o RPO pode ser próximo de zero. O modelo Silver depende da replicação assíncrona. O uso da replicação síncrona garante a perda zero de dados, mas o tempo necessário para enviar dados entre regiões normalmente aumenta o tempo de resposta do aplicativo além dos limites aceitáveis.
O recurso de failover de inicialização rápida do Data Guard tem a capacidade de realizar operações de failover automático se um banco de dados primário ficar indisponível por um período definido pelo usuário. A configuração é monitorada por um processo de observador do Data Guard, que pode ser executado.
O modelo Silver tem a vantagem de garantir que o banco de dados esteja disponível no caso de uma falha regional total, mas as operações de failover e switchover podem afetar o desempenho do aplicativo à medida que a latência da rede entre os servidores do aplicativo e o banco de dados aumenta. Raramente é recomendável executar aplicativos e bancos de dados de suporte em diferentes regiões. Embora o RTO do banco de dados possa ser inferior a um minuto, casos de failover de aplicativo podem levar de minutos a horas para que os serviços funcionem totalmente. Na maioria dos casos, a execução de planos de failover de recuperação de desastres entre regiões geralmente envolve processos manuais devido ao número de componentes que estão sendo movidos.
No modelo Silver, ainda é possível ter inatividade ou janelas de manutenção durante as atividades de correção de bugs trimestrais. A introdução do Oracle RAC pode reduzir o tempo de inatividade para correções ou falhas do servidor.
O diagrama a seguir mostra um exemplo de configuração.
O exemplo de configuração no diagrama mostra bancos de dados RAC em execução nas regiões us-west2 e us-east4. A replicação é configurada usando o DataGuard
assíncrono. Todo o tráfego entre a Solução Bare Metal e o Google Cloud
transita por uma Interconexão por parceiro, e o tráfego entre regiões viaja
pela backbone da rede do Google. Os servidores de aplicativos são configurados em cada
região, mas geralmente são encerrados na região de recuperação de desastres até que um
evento de failover seja declarado.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupção | < 60s | De minutos a horas, dependendo do failover do aplicativo. | |
| Desastres: falhas na extensão da região | < 60s | De minutos a horas, dependendo do failover do aplicativo. | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos se estiver usando a RAC |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas
Minutos se você usar |
Modelo de ouro
Se você estiver preocupado com a perda de dados no modelo Silver, escolha o modelo Gold, que usa uma instância de sincronização remota para fornecer replicação síncrona a uma instância em execução no Google Cloud Compute Engine.
Uma instância de sincronização remota inclui um arquivo de controle de banco de dados e um conjunto de registros de refazer de espera que são executados geograficamente perto do banco de dados principal. Essa instância é configurada para receber a repetição de forma síncrona com baixa latência, permitindo que todas as mudanças sejam registradas fora da extensão da região do banco de dados principal. A instância de sincronização remota encaminha a repetição para o banco de dados de espera na região remota para ser aplicada de forma assíncrona.
Uma instância de sincronização remota não é uma cópia completa do banco de dados e, portanto, não pode atender ao tráfego do aplicativo. A instância de sincronização remota é usada para fornecer um local tolerante a falhas para que as mudanças no banco de dados sejam gravadas de maneira síncrona, permitindo uma solução de perda de dados zero. Ao realizar a replicação síncrona na instância de sincronização remota, as transações não são confirmadas no banco de dados principal até que as mudanças sejam recebidas e confirmadas na instância de sincronização remota.
As instâncias do Compute Engine geralmente são selecionadas como candidatas para hospedar uma instância de sincronização remota. Colocar a instância de sincronização remota em uma zona do Compute Engine perto do banco de dados principal adiciona latência mínima (normalmente menos de 1,5 ms) e protege contra falhas na extensão da região.
O diagrama a seguir mostra um exemplo de implantação.
O exemplo de configuração no diagrama mostra um banco de dados RAC principal em execução em
us-west2 com aplicativos em execução no Compute Engine. Uma instância do Compute Engine
em us-west2 está executando uma instância de sincronização remota, recebendo uma repetição
síncrona. A instância de sincronização remota é configurada para enviar refazer de forma assíncrona para um banco de dados
RAC executado na região us-east4. As instâncias do aplicativo são configuradas
na região us-east4 do Compute Engine para processar o tráfego do aplicativo em
caso de desastre.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupção | 0 | De minutos a horas, dependendo do failover regional do aplicativo. | |
| Desastres: falhas na extensão da região | 0 | De minutos a horas, dependendo do failover regional do aplicativo. | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos se estiver usando a RAC |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas
Minutos se você usar |
Modelo Platinum
O modelo Platinum oferece duas opções de implantação. Cada opção de implantação oferece proteção usando uma tecnologia diferente e tem características diferentes de RTO e RPO.
Implantação Platinum 1: Data Guard com failover de inicialização rápida
A implantação Platinum 1 é baseada na implantação do modelo Gold e adiciona um segundo banco de dados de espera do Data Guard na região local que é executado em uma instância do Compute Engine. Essa configuração usa a replicação síncrona entre o banco de dados principal e o de espera em execução no Compute Engine, garantindo a ausência de perda de dados na região principal.
A criação de um banco de dados de espera na região permite que as operações de failover e de switchover do banco de dados ocorram sem afetar os aplicativos. Durante as mudanças de função do banco de dados, os aplicativos configurados de acordo com as considerações do cliente da Oracle se reconectam automaticamente ao novo banco de dados principal sem requerer intervenção manual. Os aplicativos configurados corretamente têm menos de dois minutos de inatividade durante um evento de failover.
Embora o banco de dados de espera no Compute Engine não execute o RAC, ele precisa ser dimensionado para oferecer suporte ao tráfego normal do aplicativo quando estiver sendo executado como o banco de dados principal. Essa instância pode ser executada com uma forma menor enquanto opera como standby e é dimensionada para cima durante eventos de failover ou pode ser executada com a capacidade total o tempo todo. O redimensionamento da instância durante um evento de failover afeta negativamente o RTO, já que a instância precisa ser reiniciada durante a operação de redimensionamento.
O failover de inicialização rápida é configurado em uma instância do Compute Engine que executa o corretor do Data Guard com um observador. O observador executa um cliente Oracle básico com conexões para todos os bancos de dados principais e de espera. Se o observador detectar uma falha no banco de dados principal, ele iniciará um failover para um dos bancos de dados em espera. O banco de dados reserva em execução no Compute Engine precisa ser configurado como o destino de failover preferencial ao usar a implantação do nível Gold.
A Oracle recomenda que o observador seja colocado em uma região separada dos bancos de dados principal e de espera. Isso oferece a melhor proteção contra falhas regionais e eventos de particionamento de rede. Se não for possível usar uma terceira região, o observador precisa ser instalado na região principal, em uma zona diferente da standby local.
O diagrama a seguir mostra um exemplo de implantação.
O exemplo de implantação mostrado no diagrama consiste no seguinte:
- Um banco de dados principal que executa RAC no servidor da Solução Bare Metal na região
us-west2. - Um banco de dados de reserva near-site em execução na instância do Compute Engine na região
us-west2. - Um banco de dados de espera remoto em execução no servidor da Solução Bare Metal na região
us-east4. - O observador do Data Guard em execução na instância do Compute Engine na região
us-central1.
A replicação síncrona é configurada para o banco de dados de reserva na região em execução
na instância do Compute Engine, e a replicação assíncrona é configurada para
a região remota. Em cada caso, a repetição é enviada do banco de dados principal para o
de espera. Ela não é encaminhada de um banco de dados de espera para o outro. O
observador é configurado em uma terceira região e mantém a conectividade com todos
os bancos de dados na configuração. As instâncias de aplicativo são configuradas na
região principal e se conectam ao banco de dados principal no servidor da Solução Bare Metal
(ou ao banco de dados na instância do Compute Engine durante operações de failover e switchover). As instâncias do aplicativo são configuradas na região us-east4 no
Compute Engine para processar o tráfego do aplicativo em caso de desastre.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupção | 0 | < 60s | |
| Desastres: falhas na extensão da região | 0 | < 60s | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos se estiver usando a RAC |
| Upgrade principal do banco de dados | 0 | De 1 a 2 horas
Minutos se você usar |
Implantação Platinum 2: GoldenGate para replicação
A implantação Platinum 2 depende do uso do Oracle GoldenGate para a replicação. Como o GoldenGate não replica no nível do bloco. Ele permite que cada banco de dados leia e grave sessões de aplicativos de forma independente. Ele replica as mudanças de forma bidirecional, permitindo uma configuração de banco de dados ativo/ativo.
Os aplicativos precisam ser validados completamente antes de serem implantados de forma ativa/ativa, e você precisa considerar a detecção e resolução de conflitos.
Ao contrário do Data Guard, o GoldenGate exige a instalação e manutenção de outros softwares nos servidores de banco de dados Oracle. As implantações ativas/ativas normalmente exigem um esquema e um design de aplicativo sofisticados para aproveitar uma implantação de banco de dados em vários sites. Muitos aplicativos pré-empacotados não têm suporte a esse tipo de arquitetura.
As implantações que dependem do GoldenGate para toda a replicação não podem ter um RPO de perda de dados zero devido à natureza assíncrona da replicação lógica. Bancos de dados locais em espera em execução no Compute Engine usando o Data Guard podem ser implantados para fornecer um RPO de zero com replicação síncrona.
O diagrama a seguir mostra um exemplo de implantação.
| Falha temporária | Tipo de falha | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupção | Segundos para minutos
0 se o Data Guard estiver sendo usado em cada local |
0 | |
| Desastres: falhas na extensão da região | Segundos para minutos
0 se o Data Guard estiver sendo usado em cada local |
0 | |
| Planejado | Correções de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância.
Segundos se estiver usando a RAC |
| Upgrade principal do banco de dados | 0 | 0 |