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 essenciais 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 da 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 Oracle precisa ser determinada com base no objetivo do tempo de recuperação (RTO) e no objetivo do ponto de recuperação (RPO) de um aplicativo. Em geral, o RTO descreve a quantidade aceitável de tempo de inatividade para um sistema, e o RPO descreve a quantidade aceitável de perda de dados. 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 rotuladas como "RPO = 0" ou "perda zero de dados" 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 menos que seja devidamente considerada durante a fase de design, a implementação de uma arquitetura de perda zero de dados pode ter efeitos adversos no desempenho geral do aplicativo.
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, a alta disponibilidade se refere à capacidade de um sistema se recuperar automaticamente de falhas individuais ou em cascata. 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 tornar 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 de alta disponibilidade 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 hardware de servidor, rede ou 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 Google Cloud e a extensão regional da Solução Bare Metal
- Oracle RAC para evitar que falhas de 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 tornam os componentes indisponíveis. O planejamento de recuperação de desastres precisa considerar o seguinte:
- Falhas 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 da Oracle
Confira algumas ferramentas de recuperação de desastres e alta disponibilidade do Oracle:
- Oracle Real Application Clusters
- Oracle Recovery Manager (em inglês)
- 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 e ser atendido 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 oferecer alta disponibilidade a sistemas que precisam de proteção contra falhas de um único servidor. Devido à abordagem de "tudo compartilhado" (armazenamento e redes compartilhados) para clustering, um cluster RAC em execução no ambiente da Solução Bare Metal precisa estar 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 a necessidade de recuperação de desastres.
Oracle Recovery Manager
O Oracle Recovery Manager (RMAN) é a principal ferramenta para backup e recuperação de bancos de dados Oracle devido à capacidade de ler o formato de arquivo de dados proprietário da Oracle. Ele pode ser usado para realizar clones de banco de dados, recuperação pontual ou até mesmo 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 realiza a replicação de bancos de dados em clusters RAC remotos ou outras instalações de banco de dados. O Data Guard é compatível com bancos de dados em espera em uma configuração física ou lógica.
Os bancos de dados de espera física são cópias bloco a 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 geração 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
reverta rapidamente um banco de dados para um ponto específico no tempo sem precisar
realizar restaurações 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 momento específico
que é consistente com os registros no novo principal, e a refação é enviada para que ela
possa ser totalmente ressincronizada.
Oracle GoldenGate
O Oracle GoldenGate é uma ferramenta de replicação lógica usada com frequência para
ativar implantações ativas/ativas em vários sites 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 redo logs on-line e as grava em arquivos de
rastreamento, 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 à medida que 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 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 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, na sigla em inglês) para fornecer modelos de recuperação de desastres recomendados para implantação de aplicativos e bancos de dados.
Cada um dos modelos a seguir oferece 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 ao RTO em eventos de interrupções planejadas e não planejadas. Cada carga de trabalho de banco de dados precisa ser avaliada de acordo com os 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 controle de qualidade.
O modelo Bronze é destinado a bancos de dados que não precisam de um RTO medido em minutos. Os modelos Silver e de nível superior incluem bancos de dados em espera executados 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 em espera seja implantado.
Modelo Copper
O modelo Copper oferece uma implantação mínima para fazer backup de bancos de dados em mídia de armazenamento local e copiar para o armazenamento que reside fora da extensão da região. Essa implantação exige uma abordagem de duas etapas, mas pode ser programada para usar o SDK Google Cloud e automatizar a transmissão de backups.
O uso dessa implantação também aumenta o RTO devido à recuperação em duas etapas 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 interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Último backup completo, incremental ou de arquivamento 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 de extensão da região | Último backup de arquivamento, incremental ou completo transferido do RE | Dias / semanas, dependendo do tempo necessário para colocar a extensão de região on-line novamente | |
| Planejado | Patches de banco de dados, atualizações de SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | 1 a 2 horas |
Modelo Bronze
O modelo Bronze oferece duas opções de implantação. Ambos usam o armazenamento nativo do Google Cloudpara reter backups de banco de dados.
Implantação Bronze 1: backup no armazenamento regional
Nessa implantação, os backups são gravados diretamente em mídia externa. Na maioria dos casos, o destino de backup preferido é 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" Google Cloud .O Filestore, que apresenta compartilhamentos NFS para as 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 interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Último backup completo, incremental ou de arquivamento | Horas, dependendo do tamanho do banco de dados e da largura de banda atribuída à Interconexão por parceiro | |
| Desastres: falhas de extensão da região | Último backup completo, incremental ou de arquivamento | Dias / semanas, dependendo do tempo necessário para colocar a extensão de região on-line novamente | |
| Planejado | Patches de banco de dados, atualizações de SO/FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | 1 a 2 horas |
Implantação Bronze 2: backup usando o Backup e DR
Neste implantação, o serviço de Backup e DR é usado para armazenar backups em Google Cloud. O Backup e DR oferece uma abordagem de backup incremental permanente, que é armazenada em mídia de alto desempenho com suporte do Cloud Storage para retenção de longo prazo.
O Backup e DR também oferece um RTO mais rápido do que o armazenamento de backups no Filestore ou no Cloud Storage, já que pode 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 interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupções | Último backup completo, incremental ou de arquivamento | 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 de extensão da região | Último backup completo, incremental ou de arquivamento | Dias / semanas, dependendo do tempo necessário para colocar a extensão regional on-line novamente ou da capacidade do cliente de mudar para outra extensão regional. | |
| Planejado | Patches de banco de dados, atualizações de SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade principal do banco de dados | 0 | 1 a 2 horas |
Prata
O modelo Silver apresenta a replicação de banco de dados usando o Oracle Data Guard. O Data Guard oferece replicação de banco de dados em tempo real com um ou mais bancos de dados atuando como um banco de dados em 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. Usar a replicação síncrona garante perda zero de dados, mas o tempo necessário para enviar dados entre regiões geralmente 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 pode realizar operações de failover automáticas 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 garante que o banco de dados esteja disponível em caso de 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 de aplicativos e o banco de dados aumenta. Raramente é recomendável executar aplicativos e bancos de dados de suporte em regiões diferentes. Embora o RTO do banco de dados possa ser inferior a 1 minuto, os casos de failover de aplicativos podem levar de minutos a horas antes que os serviços estejam totalmente funcionais. Na maioria dos casos, a execução de planos de failover de recuperação de desastres entre regiões envolve processos manuais devido ao número de componentes que estão sendo movidos.
No modelo Silver, ainda é possível ter tempo de inatividade ou janelas de manutenção durante as atividades trimestrais de aplicação de patch. A introdução do Oracle RAC pode reduzir o tempo de inatividade para aplicação de patch ou falhas de 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 Data Guard assíncrono. Todo o tráfego entre a Solução Bare Metal e Google Cloud
passa por uma Interconexão por parceiro, e o tráfego entre regiões viaja
pelo backbone da rede do Google. Os servidores de aplicativos são configurados em cada
região, mas geralmente são desligados na região de recuperação de desastres até que um
evento de failover seja declarado.
| Falha temporária | Tipo de interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupções | < 60s | Minutos a horas, dependendo do failover do aplicativo. | |
| Desastres: falhas de extensão da região | < 60s | Minutos a horas, dependendo do failover do aplicativo. | |
| Planejado | Patches de banco de dados, atualizações de 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 | 1 a 2 horas
Minutos se você usar |
Modelo Gold
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 Compute Engine do Google Cloud.
Uma instância de sincronização distante inclui um arquivo de controle de banco de dados e um conjunto de registros de refazer em espera que são executados geograficamente perto do banco de dados principal. Essa instância é configurada para receber refazer de maneira 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 refazimento para o banco de dados de espera na região remota para aplicação assíncrona.
Uma instância de sincronização distante não é uma cópia completa do banco de dados e, portanto, não pode atender ao tráfego de aplicativos. A instância de sincronização distante é usada para fornecer um local tolerante a falhas para que as mudanças no banco de dados sejam gravadas de forma 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 distante em uma zona do Compute Engine próxima ao banco de dados principal adiciona uma 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 distante, recebendo refazimento síncrono. A instância de sincronização distante é configurada para enviar refazer de maneira assíncrona para um banco de dados RAC
em execução na região us-east4. As instâncias de aplicativo são configuradas na região us-east4 do Compute Engine para processar o tráfego de aplicativos em caso de desastre.
| Falha temporária | Tipo de interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupções | 0 | De minutos a horas, dependendo do failover regional do aplicativo. | |
| Desastres: falhas de extensão da região | 0 | De minutos a horas, dependendo do failover regional do aplicativo. | |
| Planejado | Patches de banco de dados, atualizações de 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 | 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 de RTO e RPO diferentes.
Implantação Platinum 1: Data Guard com failover de inicialização rápida
A implantação do Platinum 1 se baseia na implantação do modelo Gold ao adicionar um segundo banco de dados standby 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 em espera em execução no Compute Engine, garantindo zero perda de dados na região principal.
Criar um banco de dados em espera na região permite que as operações de failover e switchover 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 exigir intervenção manual. Aplicativos configurados corretamente têm menos de dois minutos de inatividade durante um evento de failover.
Embora o banco de dados em espera no Compute Engine não execute o RAC, ele precisa ser dimensionado para oferecer suporte ao tráfego normal de aplicativos quando estiver em execução como o banco de dados principal. Essa instância pode ser executada com uma forma menor enquanto opera como um standby e é ampliada durante eventos de failover ou executada na capacidade total em todos os momentos. Redimensionar a 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 broker do Data Guard com um observador. O observador executa um cliente Oracle básico com conexões a todos os bancos de dados primários e em espera. Se o observador detectar uma falha no banco de dados principal, ele vai iniciar um failover para um dos bancos de dados de espera. O banco de dados em espera em execução no Compute Engine precisa ser configurado como o destino de failover preferido 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 primário e em espera. Isso oferece a melhor proteção contra falhas regionais e eventos de particionamento de rede. Se uma terceira região não for possível, o observador precisará ser instalado na região principal, executado em uma zona diferente da espera quase no 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 executando RAC no servidor da Solução Bare Metal na região
us-west2. - Um banco de dados standby quase local em execução em uma instância do Compute Engine na região
us-west2. - Um banco de dados remoto em espera 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 espera 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, o redo é enviado do banco de dados primário para o
em espera, e não de um banco de dados em espera para 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 de aplicativo são configuradas na região us-east4 no Compute Engine para processar o tráfego de aplicativos em caso de desastre.
| Falha temporária | Tipo de interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância
Segundos se estiver usando a RAC |
| Desastres: corrupções | 0 | < 60s | |
| Desastres: falhas de extensão da região | 0 | < 60s | |
| Planejado | Patches de banco de dados, atualizações de 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 | 1 a 2 horas
Minutos se você usar |
Implantação do Platinum 2: GoldenGate para replicação
A implantação Platinum 2 depende do uso do Oracle GoldenGate para replicação. Como o GoldenGate não replica no nível do bloco. Isso permite que cada banco de dados atenda sessões de aplicativos de leitura e gravação 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 antes de serem implantados em um ambiente ativo/ativo, 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 software adicional nos servidores de banco de dados Oracle. As implantações ativas/ativas geralmente exigem um esquema sofisticado e um design de aplicativo para aproveitar uma implantação de banco de dados em vários sites. Muitos aplicativos pré-empacotados não são compatíveis com esse tipo de arquitetura.
As implantações que dependem do GoldenGate para toda a replicação não podem oferecer suporte a um RPO de perda de dados zero devido à natureza assíncrona da replicação lógica. É possível implantar bancos de dados standby locais executados no Compute Engine usando o Data Guard 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 interrupção | RPO | RTO |
|---|---|---|---|
| Não planejado | Falha recuperável de nó ou instância | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | Segundos para minutos
0 se usar o Data Guard em cada local |
0 | |
| Desastres: falhas de extensão da região | Segundos para minutos
0 se usar o Data Guard em cada local |
0 | |
| Planejado | Patches de banco de dados, atualizações de 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 |