O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Replicar dados do Spanner para o Spanner Omni

Neste documento, descrevemos padrões, etapas de configuração e orientações operacionais para configurar topologias de recuperação de desastres entre o Spanner gerenciado no Google Cloud e o Spanner Omni em um ambiente externo, como a AWS ou um data center local.

Ao combinar o streaming de transações usando fluxo de alterações e conectividade de rede dedicada pelo Interconexão entre nuvens, é possível alcançar objetivos de ponto de recuperação (RPO) e objetivos de tempo de recuperação (RTO) baixos em limites de nuvem.

Informações gerais da arquitetura

Em uma topologia de recuperação de desastres entre nuvens, o Spanner no Google Cloud serve como o banco de dados principal, e o Spanner Omni serve como uma implantação em espera ou um local secundário de recuperação de desastres. É possível replicar mudanças transacionais continuamente usando fluxo de alterações.

A tabela a seguir compara os recursos, os papéis e os limites operacionais do banco de dados entre uma implantação principal do Spanner e uma implantação secundária do Spanner Omni na AWS.

Comparação entre as implantações primárias do Spanner e secundárias do Spanner Omni
Capacidade ou dimensão	Site principal: Spanner em Google Cloud	Site secundário: Spanner Omni na AWS
Modelo de implantação	Serviço totalmente gerenciado no Google Cloud.	Software autogerenciado na AWS, como o Amazon Elastic Compute Cloud (Amazon EC2) ou o Amazon Elastic Kubernetes Service (Amazon EKS).
SLA de disponibilidade	Até 99,999% para configurações multirregionais e 99,99% para configurações regionais. Para mais informações, consulte o SLA do Spanner.	Controlado pelo cliente; depende da infraestrutura e da topologia.
Modo de replicação	Replicação síncrona baseada em Paxos entre zonas e regiões.	Captura de dados alterados (CDC) assíncrona e quase em tempo real usando fluxos de alterações.
Objetivo do ponto de recuperação (RPO)	Quase zero na instância gerenciada.	De menos de um segundo a segundos entre os limites da nuvem, dependendo da capacidade de processamento do pipeline e da latência da rede.
Objetivo do tempo de recuperação (RTO)	Failover imediato e automatizado entre réplicas.	Depende do seu runbook de DNS e de alternância de tráfego.
Camada de trânsito de rede	Peering de rede de nuvem privada virtual (VPC) ou Cloud Interconnect.	Interconexão entre nuvens conectado ao AWS Direct Connect.
Destino de armazenamento de backup	Backups do Spanner gerenciados pelo Google, que só podem ser restaurados no Spanner gerenciado.	Cloud Storage ou Amazon Simple Storage Service (Amazon S3), que só podem ser restaurados para o Spanner Omni.

Antes de começar

Antes de configurar a replicação entre o Spanner e o Spanner Omni, verifique se o ambiente atende a estes requisitos:

Provisionar a capacidade de destino correspondente: dimensione a implantação de destino do Spanner Omni para corresponder à capacidade de E/S de CPU, memória e armazenamento da instância principal do Spanner. A subdimensionamento da implantação pode causar atraso na replicação e impedir que o cluster em espera processe cargas de trabalho durante um failover. Para mais informações, consulte Requisitos do sistema.
Sincronizar esquemas de banco de dados e dados de referência: crie o banco de dados e as tabelas de destino no Spanner Omni usando o mesmo dialeto SQL, GoogleSQL ou PostgreSQL, e as definições de esquema do banco de dados de origem do Spanner. Como não é possível restaurar um backup gerenciado do Spanner no Spanner Omni, exporte os dados do Spanner para arquivos Avro no Cloud Storage e importe-os para o Spanner Omni. Para mais informações, consulte Esquema e modelo de dados, Desenvolver com o Spanner Omni, Exportar bancos de dados do Spanner para o Avro e Importar e exportar dados.
Estabelecer conectividade de rede privada: configure o roteamento de rede privada entre sua rede VPC do Google Cloud e seu ambiente externo para que os workers de replicação possam se conectar ao Spanner e ao endpoint gRPC do Spanner Omni. Para mais informações, consulte Como escolher um produto de conectividade de rede e Acelerar a replicação com o Cloud Interconnect.

Replique dados continuamente usando fluxo de alterações

Para aplicativos que exigem continuidade de negócios entre nuvens, os fluxos de alterações do Spanner geram alterações de dados transacionais (operações INSERT, UPDATE e DELETE) na ordem de carimbo de data/hora de confirmação. Um pipeline de replicação contínua lê registros de alteração do Spanner no Google Cloud e os grava na implantação do Spanner Omni.

O uso de fluxo de alterações para replicação entre nuvens oferece os seguintes benefícios:

Espera ativa-passiva: mantém uma réplica ativa no Spanner Omni que está pronta para atender às cargas de trabalho quando você inicia um failover.
Replicação seletiva: é possível configurar fluxo de alterações para monitorar todo o banco de dados ou restringi-los a tabelas e colunas específicas para reduzir os custos de transferência entre nuvens.
Paridade de dialeto: como o Spanner Omni é compatível com os mesmos dialetos do GoogleSQL e do PostgreSQL e com a mesma semântica de esquema do Spanner, as consultas do aplicativo são executadas sem modificações após a transição.

Etapa 1: criar um fluxo de alterações no banco de dados de origem

Crie um fluxo de alterações no banco de dados de origem do Spanner para acompanhar as mudanças nas tabelas de destino. Por exemplo, execute esta instrução DDL no banco de dados do Spanner:

CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
  retention_period = '7d',
  value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);

Substitua:

CHANGE_STREAM_NAME: o nome do fluxo de alterações, por exemplo, CsToOmniDrStream.
TABLE_NAMES: uma lista separada por vírgulas de tabelas a serem rastreadas, por exemplo, Customers, Orders, AccountBalances ou ALL para rastrear todas as tabelas no banco de dados.

Definir retention_period como '7d' retém os registros do fluxo de alterações por até sete dias, o que ajuda a evitar a perda de dados se o pipeline de replicação passar por manutenção prolongada ou interrupções de conectividade. Para mais informações, consulte Criar e gerenciar fluxos de alterações.

Etapa 2: implantar um pipeline de captura de dados alterados

Para transmitir mudanças do Spanner para o Spanner Omni, implante um pipeline de captura de dados alterados (CDC) contínuo usando o Dataflow com o Apache Beam ou execute pods de worker personalizados no Google Kubernetes Engine (GKE) ou no Amazon EKS.

Um pipeline de replicação de produção executa estas tarefas:

Lê partições: usa a API Spanner Change Streams ou o conector SpannerIO do Apache Beam para ler registros de alterações em partições dinâmicas de fluxo de alterações. Para mais informações, consulte Partições, registros e consultas de fluxos de alterações e Processar registros de fluxos de alterações usando o Dataflow.
Armazena em buffer e ordena mutações: sequencia e agrupa transações em lote de acordo com os carimbos de data/hora de confirmação (commit_timestamp) por intervalo de chaves ou tabela para manter a consistência transacional e maximizar a capacidade de gravação.
Gravações no Spanner Omni: conecta-se por gRPC ao endpoint particular da implantação do Spanner Omni e aplica as mutações em lote. Se você usar o conector SpannerIO do Apache Beam com criptografia, use o Apache Beam 2.69.0 ou mais recente para TLS ou 2.75.0 ou mais recente para TLS mútuo (mTLS). Para mais informações, consulte Usar o Apache Beam e o SpannerIO para se conectar ao Spanner Omni e Autenticação e autorização.
Monitora o atraso de replicação: rastreia a diferença entre o horário atual e o commit_timestamp dos registros de alteração processados para que você possa receber alertas sobre atrasos de replicação.

Se você usa o Dataflow ou o Apache Beam, use o SDK do Apache Beam para Java, porque o SDK para Python não inclui um conector de fluxo de alterações. Para pods de worker personalizados, este exemplo em Python mostra como configurar um cliente do Spanner Omni usando criptografia TLS e aplicar um lote de mutações de fluxo de alterações a um banco de dados de destino. Para cargas de trabalho de alto volume, coloque em fila e em lote as mutações que não se sobrepõem na ordem de carimbo de data/hora de commit em processos de worker paralelos, em vez de fazer commit de um registro por vez:

from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType

# Configure the Spanner Omni target client
omni_client = spanner.Client(
    client_options={"api_endpoint": "ENDPOINT"},
    instance_type=InstanceType.OMNI,
    ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")


def apply_cdc_mutations_to_omni(records):
    """Applies a batch of ordered change stream records to Spanner Omni."""

    def write_batch(transaction):
        for record in records:
            table_name = record["tableName"]
            mutation_type = record["mutationType"]  # INSERT, UPDATE, DELETE
            row_data = record.get("columnValues", {})

            if mutation_type in ("INSERT", "UPDATE"):
                transaction.insert_or_update(
                    table=table_name,
                    columns=list(row_data.keys()),
                    values=[list(row_data.values())],
                )
            elif mutation_type == "DELETE":
                key_columns = record["keyValues"]
                transaction.delete(
                    table=table_name,
                    keyset=spanner.KeySet(keys=[list(key_columns.values())]),
                )

    omni_database.run_in_transaction(write_batch)

Substitua:

ENDPOINT: o endpoint gRPC privado e a porta da sua instância do Spanner Omni, por exemplo, spanner-omni.internal.example.com:15000.
PATH_TO_CA_CERT: o caminho do arquivo para o certificado da autoridade certificadora (CA) da implantação do Spanner Omni.
DATABASE_ID: o ID do banco de dados de destino do Spanner Omni.

Para mais informações sobre como configurar conexões de cliente, consulte Usar a biblioteca de cliente do Python para se conectar ao Spanner Omni.

Acelerar a replicação com o Interconexão entre nuvens

Depender da Internet pública ou de túneis de VPN IPsec entre o Google Cloud e outro provedor de nuvem pode introduzir instabilidade de rede, perda de pacotes, limites de largura de banda e atraso de replicação variável. Para cargas de trabalho de produção que exigem um RPO baixo, use o Cross-Cloud Interconnect para estabelecer uma conectividade física dedicada de alta velocidade entre o Google Cloud e seu provedor de nuvem externo.

A tabela a seguir compara as características de rede entre a Internet pública ou as conexões VPN IPsec e o Interconexão entre nuvens.

Comparação de opções de trânsito de rede para replicação entre nuvens
Métrica de rede	Internet pública ou VPN IPsec	Cross-Cloud Interconnect
Capacidade do link	De 1,25 Gbps a 3 Gbps por túnel.	Largura de banda óptica dedicada de 10 Gbps ou 100 Gbps por link.
Latência e instabilidade da rede	Caminhos de trânsito de Internet variáveis e imprevisíveis.	Roteamento privado determinista de baixa latência.
SLA de disponibilidade	Não há SLA de desempenho completo.	SLA de disponibilidade de 99,9% ou 99,99% quando configurado com conexões redundantes.
Criptografia de transferência de dados	Sobrecarga de IPsec e limites de criptografia de software.	Criptografia MACsec de taxa de linha para Cloud Interconnect (IEEE 802.1AE). Para mais informações, consulte Visão geral do MACsec para o Cloud Interconnect.
Custos de transferência de dados	Taxas padrão de saída de dados para a Internet.	Taxas reduzidas de transferência de dados do Cloud Interconnect.

Fluxo de trabalho de configuração de rede de alto nível

Para configurar Interconexão entre nuvens para seu pipeline de replicação, conclua estas etapas de alto nível:

Solicitar Interconexão entre nuvens Interconnect: solicite portas primárias e redundantes do Interconexão entre nuvens em uma instalação de colocation que se conecte ao local do seu provedor de nuvem remoto. Por exemplo, execute o comando gcloud compute interconnects create:
```
gcloud compute interconnects create CONNECTION_NAME \
  --interconnect-type=DEDICATED \
  --link-type=CAPACITY \
  --requested-link-count=LINK_COUNT \
  --location=GOOGLE_CLOUD_LOCATION \
  --remote-location=REMOTE_LOCATION \
  --noc-contact-email=CONTACT_EMAIL
```
Substitua:
- CONNECTION_NAME: o nome da sua conexão do Interconexão entre nuvens.
- CAPACITY: a capacidade do link, como LINK_TYPE_ETHERNET_10G_LR ou LINK_TYPE_ETHERNET_100G_LR.
- LINK_COUNT: o número de links a serem solicitados.
- GOOGLE_CLOUD_LOCATION: o domínio de disponibilidade de borda para o local Google Cloud , por exemplo, iad-zone1-1.
- REMOTE_LOCATION: o local remoto do provedor de nuvem, por exemplo, aws-us-east-1.
- CONTACT_EMAIL: o endereço de e-mail das operações de rede.
Para mais informações, consulte Escolher os locais e Solicitar as portas da AWS.
Configurar o Cloud Router e o peering do BGP: crie anexos da VLAN e configure sessões do protocolo de gateway de borda (BGP) entre o Cloud Router na sua rede VPC do Google Cloud e o gateway privado virtual ou o gateway de conexão direta no ambiente de nuvem remoto. Para mais informações, consulte Visão geral do Cloud Router, Configurar seus recursos do Google Cloud e Configurar seus recursos da AWS.
Validar a propagação de rotas: verifique se as tabelas de rotas em ambas as redes propagam blocos CIDR não sobrepostos para que os workers do pipeline de CDC e os nós do Spanner Omni se comuniquem exclusivamente por endereços IP privados. Para mais informações, consulte Verificar suas conexões.

Para instruções completas de configuração, consulte Conectar-se ao Amazon Web Services na documentação do Interconexão entre nuvens.

Lista de verificação de failover e runbook

Ao executar uma troca ou um failover do Spanner no Google Cloud para o Spanner Omni, siga estas etapas operacionais:

Drenar as alterações em andamento: interrompa as gravações do aplicativo no banco de dados principal do Spanner (se acessível) e verifique se o pipeline de replicação do CDC processou todos os registros do fluxo de alterações até o carimbo de data/hora de confirmação mais recente.
Redirecionar conexões de aplicativos: atualize os perfis de configuração do aplicativo, as strings de conexão ou os secrets do Kubernetes para se conectar aos endpoints do Spanner Omni em vez do Spanner noGoogle Cloud.
Atualizar o DNS e o roteamento de tráfego: mude os registros DNS ou os destinos do balanceador de carga global para rotear o tráfego do cliente para o nível do aplicativo e os balanceadores de carga que estão à frente da implantação do Spanner Omni.
Sincronizar novamente após a recuperação: depois de restaurar o ambiente principal doGoogle Cloud , inverta a direção da replicação antes de fazer o failback. Você captura as mudanças do Spanner Omni usando um fluxo de alterações e o conector do Debezium para publicar as mudanças no Apache Kafka, com um consumidor que as aplica ao Spanner. Como alternativa, é possível exportar o banco de dados do Spanner Omni para arquivos Avro no Cloud Storage e importá-los para o Spanner. Para mais informações, consulte Importar e exportar dados e Importar arquivos Avro do Spanner.

Replicar dados do Spanner para o Spanner Omni Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.