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 executar cargas de trabalho essenciais de bancos de dados Oracle em uma Solução Bare Metal de nuvem.
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 bancos de dados Oracle precisa ser determinada com base o objetivo do tempo de recuperação (RTO) e o objetivo do ponto de recuperação de um aplicativo RPO, na sigla em inglês. 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 de planejamento de DR.
Arquiteturas rotuladas como "RPO = 0" ou "nenhuma perda de dados" exigem o que os dados sejam gravados em vários locais antes de serem considerados "comprometidos" para banco de dados. A latência torna-se um problema conforme o RPO se aproxima de zero.
A menos que isso seja devidamente contabilizado durante a fase de design, implementar um modelo arquiteturas de perda de dados podem 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 quando projetar arquiteturas de banco de dados confiáveis. No contexto deste guia, Alta disponibilidade refere-se à capacidade do sistema de 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. 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 sustentar falhas individuais e continuar em execução sem causar inatividade por o aplicativo. Os componentes de alta disponibilidade de um sistema precisam incluir, não se limitam ao seguinte:
- Alimentação redundante em servidores, redes ou hardwares de armazenamento
- Várias interfaces de rede, switches e cabos
- Malhas de armazenamento, controladores e dispositivos de disco redundantes
- Interconexões por parceiro tolerantes a falhas entre o Google Cloud e o Extensão de região da Solução Bare Metal
- Oracle RAC para evitar que falhas no servidor desativem um banco de dados
Um projeto de recuperação de desastres deve incluir processos para se recuperar de vários falhas em cascata que tornam 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 alta disponibilidade e recuperação de desastres do Oracle
Confira a seguir 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
Os Real Application Clusters (RAC) da Oracle são usados para escalonar bancos de dados horizontalmente cargas de trabalho sejam atendidas por vários servidores de banco de dados. Bancos de dados que usam RAC permitir uma configuração ativa/ativa entre servidores em uma 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 faz do RAC uma solução para alta disponibilidade mas não resolve os requisitos de recuperação de desastres.
Para saber como configurar o RAC para a Solução Bare Metal, consulte Instale o Oracle RAC em Solução Bare Metal.
Gerenciador de recuperação do Oracle
O Oracle Recovery Manager (RMAN) é a principal ferramenta de backup e recuperação de Bancos de dados Oracle devido à capacidade de ler o arquivo de dados reservado da 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á aberta. Ele também é usado para manter o catálogo de arquivos de backup disponíveis para recuperação.
Data Guard da Oracle
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 em espera configuração física ou lógica.
Os bancos de dados físicos em espera são cópias bloco-a-bloco que permitem uma cópia que o banco de dados esteja aberto para gravação, todos os outros são montados (mas não aberta) para aplicar alterações ou abrir somente leitura para auxiliar na geração de relatórios aplicativos conteinerizados.
Para aprender a 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
retroceder rapidamente um banco de dados para um ponto específico no tempo sem precisar
e realizar restaurações de bancos 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 é retornado a um momento específico
consistente com os registros da nova instância principal, sendo refeito para que
possam ser totalmente ressincronizadas.
Oracle GoldenGate
O Oracle GoldenGate é uma ferramenta de replicação lógica comumente usada para
permitir implantações ativas/ativas em vários locais ou mover dados pelo hardware
plataformas. Ao usar o GoldenGate, um processo extract no banco de dados de origem
captura as alterações nos registros de refazer on-line e as grava nas alterações no
que são transportados para o banco de dados de destino. Um processo replicat no
de destino converte transações dos arquivos tail em SQL e executa
SQL no banco de dados de destino.
Essa arquitetura torna a GoldenGate uma ferramenta poderosa para mover dados entre plataformas de banco de dados ou na transformação de 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 replicação síncrona devido ao fato de que as transações são convertidas e aplicadas como SQL no no banco de dados de destino. Embora a GoldenGate possa fornecer atraso mínimo na replicação, A GoldenGate sozinha 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 aos requisitos de RPO e RTO em caso de falhas temporárias planejadas ou não. Cada carga de trabalho do banco de dados precisa ser avaliado de acordo com os requisitos de disponibilidade e projetado um modelo de machine learning. É 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 Silver e de nível superior incluem bancos de dados em espera executados em 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 precisam ser seguidas mesmo que um banco de dados em espera seja implantado.
Modelo de cobre
O modelo do Copper fornece uma implantação mínima para fazer backup de bancos de dados para armazenamento local mídia e cópias para armazenamento que reside fora da extensão da região. Isso implantação requer uma abordagem de dois estágios, mas pode ser roteirizado para usar a SDK Google Cloud para automatizar a transmissão de backups.
Essa implantação também aumenta o RTO devido à recuperação em dois estágios, que é obrigatórios. o RMAN não consegue acessar diretamente os backups, por isso eles devem 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 do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | 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 de extensão de 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 | Patches de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade importante do banco de dados | 0 | 1 a 2 horas |
Modelo de bronze
O modelo Bronze oferece duas opções de implantação. Ambas usam Armazenamento nativo do Google Cloud para reter backups de bancos de dados.
Implantação Bronze 1: backup no Regional Storage
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. Google Cloud Filestore, que apresenta compartilhamentos de NFS para as instâncias da Solução Bare Metal.
O diagrama a seguir mostra um exemplo de implantação.
| Falha temporária | Tipo de interrupção do serviço | 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 registro de arquivamento, backup incremental ou completo | Horas, dependendo do tamanho do banco de dados e da largura de banda atribuída ao Interconexão por parceiro | |
| Desastres: falhas de extensão de região | Último registro de arquivamento, backup incremental ou completo | 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 e atualizações do SO/FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade importante 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. Backup e DR sempre abordagem de backups, que são armazenados em mídia de alto desempenho apoiada por Cloud Storage para retenção de longo prazo.
O backup e a DR 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. Os processos de montagem e migração esse recurso coloca um banco de dados on-line rapidamente enquanto copia para a produção de armazenamento de dados, reduzindo drasticamente o RTO.
O diagrama a seguir mostra um exemplo de implantação.
| Falha temporária | Tipo de interrupção do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se você estiver usando RAC |
| Desastres: corrupção | Último registro de arquivamento, backup incremental ou completo | Minutos a horas, dependendo dos requisitos de desempenho, do tamanho do banco de dados e da largura de banda atribuída ao Interconexão por parceiro | |
| Desastres: falhas de extensão de região | Último backup completo, incremental ou de registro de arquivo | Dias / semanas, dependendo do tempo necessário para ativar a extensão da região novamente ou da capacidade do cliente de mudar para outra extensão de região. | |
| Planejado | Patches de banco de dados, atualizações do SO / FW | 0 | Tempo necessário para atualizar e reiniciar a instância |
| Upgrade importante do banco de dados | 0 | 1 a 2 horas |
Silver
O modelo Silver introduz 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 e atuam 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. Prata modelo depende da replicação assíncrona. o uso da replicação síncrona garante nenhuma perda de dados, mas o tempo necessário para enviar dados entre regiões faça com que o tempo de resposta do aplicativo ultrapasse os 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 Data Guard do observador, que pode ser executado.
O modelo Silver tem a vantagem de garantir que o banco de dados esteja disponível no caso de falha regional total, mas as operações de failover e alternância afetar o desempenho do aplicativo, como a latência de rede e aumento do banco de dados. 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 desastres os planos de failover de recuperação geralmente envolvem processos manuais devido ao número que estão sendo movidos.
No modelo Silver, ainda pode haver períodos de inatividade ou de manutenção durante as atividades de aplicação de patches 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 em
us-west2 e us-east4 regiões. A replicação é configurada com o uso
Proteção de dados. 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
pelo backbone da rede do Google. Os servidores de aplicativos são configurados
mas geralmente são desligados na região de recuperação de desastres até que
é declarado.
| Falha temporária | Tipo de interrupção do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se você estiver usando RAC |
| Desastres: corrupções | < Anos 60 | De minutos a horas, dependendo do failover do aplicativo. | |
| Desastres: falhas na extensão da região | < Anos 60 | Minutos a horas, dependendo do failover do aplicativo. | |
| Planejado | Patches 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 |
| Grande upgrade do banco de dados | 0 | De 1 a 2 horas
Minutos se você usar |
Modelo 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 distante inclui um arquivo de controle de banco de dados e um conjunto de ações de refazer em espera registros executados geograficamente perto do banco de dados primário. Esta instância está configurada para receber refazer e de forma síncrona com baixa latência, permitindo que todos o registro das mudanças fora da extensão de região do banco de dados primário. O de sincronização e encaminha o refazer para o banco de dados de espera na região para aplicar de maneira 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 executar a replicação síncrona na sincronização remota as transações não são confirmadas no banco de dados primário até que alterações foram recebidas e confirmadas na instância de sincronização distante.
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 proximidade do banco de dados primário adiciona latência mínima (normalmente abaixo 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 Compute Engine
em us-west2 está executando uma instância de sincronização distante, recebendo
e refazer. A instância de sincronização distante está configurada para enviar refazer de forma assíncrona a um RAC
banco de dados em execução 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 interrupção do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se você estiver usando RAC |
| Desastres: corrupções | 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 | Patches 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 |
| Grande upgrade do banco de dados | 0 | 1 a 2 horas
Minutos se estiver usando |
Modelo Platinum
O modelo Platinum oferece duas opções de implantação. Cada opção de implantação fornece usando outra tecnologia e carregam um RTO e RPO diferentes e as características determinantes.
Implantação Platinum 1: Data Guard com failover de inicialização rápida
A implantação Platinum 1 se baseia na implantação do modelo Gold ao adicionando um segundo banco de dados em espera do Data Guard na região local que é executado em um instância do Compute Engine. Esta configuração usa replicação síncrona entre o banco de dados primário e o de espera em execução no Compute Engine, fornecendo uma garantia de zero perda de dados na região primária.
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 a função de banco de dados aplicativos que são configurados de acordo com As considerações do cliente Oracle se reconectam automaticamente ao novo banco de dados primário sem que exigem 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. Esta instância pode ser executada com um formato menor enquanto opera como um em espera e escalonado verticalmente durante eventos de failover, ou executado com capacidade total vezes. 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 no banco de dados primário, ele inicia um failover para um dos bancos de dados. O banco de dados em espera em execução no Compute Engine precisa ser configurados como destino de failover preferencial ao usar a implantação do nível Ouro.
A Oracle recomenda que o observador seja colocado em uma região separada da bancos de dados primários 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 estiver possível, o observador deve ser instalado na região primária, em execução uma zona diferente da espera do 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 próximo ao local de espera em execução na instância do Compute Engine em
us-west2região. - 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 do
Compute Engine para lidar com o tráfego do aplicativo em caso de desastre.
| Falha temporária | Tipo de interrupção do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância
Segundos se você estiver usando RAC |
| Desastres: corrupções | 0 | < Anos 60 | |
| Desastres: falhas na extensão da região | 0 | < 60s | |
| Planejado | Patches 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 |
| Grande upgrade 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 replicação. Como o GoldenGate não replica no nível do bloco. Ele permite que cada banco de dados o serviço de leitura e gravação de sessões de aplicativo de forma independente. Ele replica muda bidirecionalmente, 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 a manutenção de software adicional 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 dão 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 interrupção do serviço | RPO | RTO |
|---|---|---|---|
| Não planejada | Falha de nó ou instância recuperável | 0 | Tempo necessário para reiniciar a instância |
| Desastres: corrupções | 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 | Patches 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 |
| Grande upgrade do banco de dados | 0 | 0 |