Todos os produtos
Search
Central de documentação

PolarDB:Global Database Network (GDN)

Última atualização: Aug 13, 2026

A Global Database Network (GDN) é uma rede distribuída de clusters do PolarDB que abrange várias regiões. Nessa rede, os dados são sincronizados entre todos os clusters. Cada cluster atende a solicitações de leitura, e o sistema encaminha automaticamente as solicitações de escrita ao cluster primário para processamento.

Visão geral

Basic edition

Multi-write edition

Uma Global Database Network (GDN) consiste em um cluster primário e vários clusters secundários. O cluster primário processa solicitações de escrita, enquanto os clusters secundários, distribuídos por diferentes regiões, atendem a solicitações de leitura locais. Os dados são sincronizados entre todos os clusters por meio de links de baixa latência, formando um único banco de dados lógico.

image

Na arquitetura da GDN Basic Edition, os clusters secundários encaminham solicitações de escrita ao cluster primário via roteamento entre regiões. Quando os clusters primário e secundários estão implantados em regiões diferentes e fisicamente distantes, a latência de escrita nos clusters secundários aumenta significativamente. A GDN Multi-write Edition oferece uma solução de escrita múltipla no nível de tabela. Isso permite que cada cluster realize escritas locais nas tabelas para as quais possui permissão, reduzindo efetivamente a latência de escrita entre regiões. Para mais informações, consulte GDN multi-write edition user guide.

Nota

A PolarDB GDN Multi-write Edition está atualmente em versão canary. Para usar esse recurso, pesquise o número do grupo no DingTalk e entre no grupo para fazer consultas.

Número do grupo no DingTalk: 30245017864

image

Mecanismo de sincronização de dados

A GDN utiliza replicação física assíncrona para sincronizar dados entre regiões. Com técnicas como a reaplicação paralela de logs físicos, a latência de replicação de dados entre os clusters primário e secundários geralmente fica abaixo de dois segundos. Esse processo não afeta o desempenho ou a estabilidade do cluster primário e garante a consistência eventual dos dados em escala global. Cada cluster na GDN pode processar solicitações de leitura e escrita, além de fornecer recursos de recuperação de desastres geográfica.

Divisão de leitura/escrita e roteamento de solicitações

A database proxy configuration de cada cluster determina o roteamento de solicitações de leitura e escrita para os clusters (primário e secundários) em uma GDN. Não é necessário modificar o código da sua aplicação. Basta conectar-se ao endereço do respectivo cluster, e o sistema roteará automaticamente as solicitações de leitura e escrita com base na seguinte lógica:

  • O proxy de banco de dados encaminha automaticamente ao nó primário do cluster primário as solicitações de escrita (como instruções INSERT, UPDATE e DELETE), outras sintaxes de broadcast (como instruções SET) e todas as solicitações dentro de transações.

  • Por padrão, o proxy de banco de dados roteia solicitações de leitura para os nós somente leitura do cluster secundário local. Se o session consistency estiver ativado, algumas solicitações de leitura também poderão ser roteadas para o nó primário do cluster primário para garantir a consistência dos dados.

Nota

As mesmas regras de roteamento se aplicam quando uma aplicação se conecta ao endpoint de cluster de um cluster secundário. Após um cliente estabelecer uma conexão com o proxy de banco de dados, o proxy cria e mantém conexões de backend do cluster secundário para o nó primário do cluster primário. O pré-estabelecimento dessas conexões depende da configuração do proxy de banco de dados. O link de um cluster secundário para o nó primário costuma ser uma conexão entre regiões. Para aplicações com conexões de curta duração, a criação frequente dessas conexões entre regiões pode degradar o desempenho devido a flutuações de rede. Nesse cenário, recomendamos ativar as On-demand Connections para o proxy de banco de dados do cluster secundário. Para mais informações, consulte Configure a database proxy.

Além disso, a GDN fornece um global domain name, que possibilita o acesso próximo e permanece inalterado após um failover do cluster primário.

Lógica detalhada de roteamento

Nó de destino

Solicitações encaminhadas

Encaminhadas apenas para o nó primário do cluster primário

  • Todas as operações DML, como INSERT, UPDATE, DELETE e SELECT FOR UPDATE.

  • Todas as operações DDL, como criação, exclusão ou alteração de tabelas ou bancos de dados e gerenciamento de permissões.

  • Todas as solicitações dentro de transações.

  • Funções definidas pelo usuário.

  • Procedimentos armazenados.

  • Instruções EXECUTE.

  • Multi Statements.

  • Solicitações que usam tabelas temporárias.

  • SELECT last_insert_id().

  • Todas as consultas e modificações em variáveis de usuário.

  • SHOW PROCESSLIST.

  • KILL (a instrução SQL KILL, não o comando KILL).

Encaminhadas para nós somente leitura ou para o nó primário

Nota

As solicitações são enviadas ao nó primário apenas se Primary Node Accepts Read Requests estiver definido como Yes na configuração do proxy de banco de dados.

  • Solicitações de leitura fora de transações.

  • Comandos COM_STMT_EXECUTE.

Sempre encaminhadas para todos os nós

  • Todas as modificações em variáveis de sistema.

  • Comandos USE.

  • Comandos COM_STMT_PREPARE.

  • Comandos como COM_CHANGE_USER, COM_QUIT e COM_SET_OPTION.

Nota

O nó primário de um cluster secundário destina-se apenas à replicação interna e não atende a tráfego de leitura ou escrita. Portanto, nesta tabela, o termo "nó primário" refere-se ao nó primário do cluster primário, e "nós somente leitura" refere-se aos nós somente leitura dos clusters secundários.

Casos de uso

Redundância geográfica ativa (implantação multirregião)

Implante seus serviços em várias regiões. Com recursos como sincronização entre regiões de baixa latência, divisão de leitura/escrita entre regiões e acesso local, a GDN garante que a latência de acesso ao banco de dados para aplicações em cada região seja tipicamente inferior a 2 segundos.

  • Indústrias típicas: Jogos, comércio eletrônico transfronteiriço, serviços locais (entrega de alimentos) e novo varejo (pontos de venda).

  • Arquitetura de negócios:

    • Para obter desempenho ideal, as aplicações em cada região leem e escrevem diretamente no banco de dados local. As solicitações de escrita são encaminhadas ao cluster primário para processamento.

    • Em uma GDN, cada cluster (incluindo os clusters primário e secundários) fornece um endpoint de cluster independente. Conecte-se ao endpoint de cluster mais próximo com base no local onde sua aplicação é executada.

    • As especificações dos clusters secundários em China (Beijing) e China (Shenzhen) devem ser iguais ou superiores às do cluster primário em China (Hangzhou). Recomendamos usar as mesmas especificações para obter o melhor desempenho.

image

Recuperação de desastres geográfica

Use a GDN para alcançar alta disponibilidade entre regiões e melhorar a segurança dos dados e a disponibilidade do sistema. Se o data center do cluster primário falhar, restaure o service fazendo failover manual para um cluster secundário. A GDN suporta várias arquiteturas, como duas regiões e três data centers, duas regiões e quatro data centers e três regiões e seis data centers.

  • Indústrias típicas: Bancos, valores mobiliários e seguros.

  • Arquitetura de negócios (exemplo: arquitetura de duas regiões e três data centers):

    • A região primária é China (Beijing) e usa uma implantação em zona de disponibilidade dupla, cobrindo AZ1 e AZ2.

    • A região de recuperação de desastres é China (Shanghai) e usa uma implantação em zona de disponibilidade única.

    • Por padrão, a aplicação realiza leituras e escritas locais no banco de dados na AZ1 da região China (Beijing). Se a AZ1 falhar, o sistema primeiro faz failover para a AZ2 em Beijing. Se tanto a AZ1 quanto a AZ2 falharem, o sistema faz failover para a AZ3 em Shanghai.

image
Nota

Um failover primário/secundário em uma GDN é concluído em até 10 minutos (geralmente em até 5 minutos, com base em resultados de testes). Durante o failover, podem ocorrer desconexões transitórias de até 160 segundos. Recomendamos realizar o failover fora dos horários de pico e garantir que sua aplicação possua um mecanismo de reconexão.

Benefícios

  • Implantação entre regiões: Expanda de uma implantação em região única para uma implantação multirregião sem alterar o código da sua aplicação.

  • Divisão de leitura/escrita entre regiões e acesso local: Em uma GDN, as solicitações de leitura são roteadas para o cluster secundário local, enquanto as solicitações de escrita são encaminhadas ao cluster primário.

  • Configuração flexível: Os clusters primário e secundários possuem configurações independentes, incluindo especificações de cluster, listas de permissões e valores de parâmetros.

  • Sincronização entre regiões de baixa latência: A replicação física assíncrona, baseada em redo log, e tecnologias de reaplicação paralela reduzem a latência de replicação entre regiões nos clusters primário e secundários. Isso garante que os dados permaneçam sincronizados em todos os clusters com uma latência de replicação tipicamente inferior a dois segundos, reduzindo significativamente a latência de leitura para aplicações em regiões remotas.

Requisitos e limitações

Configuração do cluster

  • Edição: Enterprise Edition, e a série deve ser Cluster Edition.

  • A versão do mecanismo de banco de dados deve ser uma das seguintes:

    • MySQL 8.0.2.

    • MySQL 8.0.1 com versão secundária do mecanismo 8.0.1.1.17 ou posterior.

    • MySQL 5.7 com versão secundária do mecanismo 5.7.1.0.21 ou posterior.

    • MySQL 5.6 com versão secundária do mecanismo 5.6.1.0.32 ou posterior.

  • Nós: O cluster deve incluir pelo menos um nó somente leitura.

Regiões suportadas

Todas as regiões na china continental, China (Hong Kong), Japan (Tokyo), South Korea (Seoul), Singapore, Malaysia (Kuala Lumpur), Indonesia (Jakarta), Philippines (Manila), Thailand (Bangkok), Germany (Frankfurt), US (Silicon Valley), US (Virginia) e UK (London).

Nota

É possível implantar clusters secundários além das fronteiras, mas é necessário enviar uma solicitação. Para mais informações, consulte Add a secondary cluster.

Limitações de recursos

  • Os clusters em uma Global Database Network (GDN) suportam o recurso In-Memory Column Index (IMCI). No entanto, é necessário ativar o parâmetro de cluster loose_polar_enable_imci_with_standby e a versão do cluster deve atender a um dos seguintes requisitos antes de adicionar um nó somente leitura orientado a colunas.

    • MySQL 8.0.1 com versão de revisão 8.0.1.1.48 ou posterior.

    • MySQL 8.0.2 com versão de revisão 8.0.2.2.27 ou posterior.

  • Os clusters em uma GDN podem ser serverless clusters ou clusters with defined specifications that have the serverless feature enabled. Contudo, se a versão do mecanismo de banco de dados do cluster primário for anterior às versões abaixo, todos os clusters na GDN devem ter pelo menos um nó somente leitura:

    • MySQL 8.0.1 com versão secundária do mecanismo anterior a 8.0.1.1.42.

    • MySQL 8.0.2 com versão secundária do mecanismo anterior a 8.0.2.2.23.

  • Os clusters em uma GDN não suportam restauração de banco de dados e tabelas.

Outras limitações

  • Uma GDN consiste em um cluster primário e até quatro clusters secundários.

    Nota

    Para adicionar mais clusters secundários, acesse o Quota Center, localize o item de cota com o ID polardb_mysql_gdn_region e clique em Apply na coluna Actions.

  • Um cluster pode pertencer a apenas uma GDN.

  • Apenas novos clusters podem ser adicionados como clusters secundários; não é possível utilizar clusters existentes.

  • Os clusters primário e secundários devem usar a mesma versão do mecanismo de banco de dados: MySQL 8.0, MySQL 5.7 ou MySQL 5.6.

  • Para clusters secundários em uma GDN que não sejam serverless clusters, cada nó de computação deve ter pelo menos 4 núcleos de CPU.

  • Por padrão, cada cluster em uma GDN contém 2 nós. É possível adicionar até 16 nós.

Preços

As cobranças de uma Global Database Network (GDN) consistem nos cluster costs e em quaisquer taxas aplicáveis de replicação de dados transfronteiriça. As regras de faturamento são as seguintes:

Importante

As taxas de transferência de dados transfronteiriça serão cobradas a partir de 00:00:00 de 1º de abril de 2026 (horário de Singapore). Antes dessa data, este service é gratuito. Para mais informações, consulte [[Notice] Announcement on network fee adjustment for Global Database Network (GDN)](t3212173.xdita#).

  • Cenários gratuitos:

    Seus clusters primário e secundários estão ambos implantados em regiões dentro da china continental, ou ambos estão implantados na região China (Hong Kong) ou em outras regiões no exterior. Exemplos:

    • Tanto o cluster primário quanto os secundários estão na china continental. Por exemplo, o cluster primário está em China (Chengdu) e os clusters secundários estão em regiões como China (Hangzhou) ou China (Shenzhen).

    • Tanto o cluster primário quanto o secundário estão na região China (Hong Kong) ou em outras regiões no exterior. Por exemplo, o cluster primário está em Singapore e o cluster secundário está em Philippines (Manila).

  • Cenários faturáveis:

    Taxas transfronteiriças se aplicam quando uma GDN atravessa a fronteira da china continental — por exemplo, se um cluster estiver na china continental e outro em China (Hong Kong) ou em uma região no exterior. Exemplos:

    • O cluster primário está na china continental e o cluster secundário está fora da china continental. Por exemplo, o cluster primário está em China (Chengdu) e o cluster secundário está em uma região como China (Hong Kong) ou Singapore.

    • O cluster primário está fora da china continental e o cluster secundário está na china continental. Por exemplo, o cluster primário está em Singapore e o cluster secundário está em uma região como China (Hangzhou) ou China (Shenzhen).

  • Regra de faturamento: USD 0,80 por GB, faturado por hora. A taxa é calculada horariamente com base no volume de dados de redo log replicados fisicamente do cluster primário para um cluster secundário transfronteiriço. Essa taxa de tráfego pode ser estimada consultando a posição física convertida a partir do número de sequência de log (LSN).

    Exemplo de faturamento

    Exemplo

    Às 09:00, você consulta a posição de escrita física do log e verifica que ela é ib_logfile1/648143676. Às 10:00, a posição é atualizada para ib_logfile3/648142342. A quantidade de dados escritos nessa hora é a diferença entre as duas posições.

    1. Quantidade escrita no arquivo inicial (ib_logfile1): Subtraia o deslocamento inicial do tamanho total do arquivo. Cada arquivo de log tem 1 GB (1.073.741.824 bytes). A quantidade escrita é 1073741824 - 648143676 = 425598148 bytes.

    2. Quantidade escrita no arquivo intermediário (ib_logfile2): Após o ib_logfile1 ficar cheio, o sistema escreve completamente o ib_logfile2. Essa quantidade é 1.073.741.824 bytes (1 GB).

    3. Quantidade escrita no arquivo final (ib_logfile3): Este é o deslocamento no final, que corresponde a 648142342 bytes.

    Portanto, a quantidade total escrita é 425598148 + 1073741824 + 648142342 = 2147482314 bytes. Isso equivale a 2147482314 / 1024 / 1024 / 1024 = 1,999998 GB (arredondado para baixo com seis casas decimais). A taxa de transferência de dados transfronteiriça para esta hora é de aproximadamente 1,999998 GB × USD 0,80/GB = USD 1,5999984.

    Consultar o progresso de escrita do log e o deslocamento do arquivo físico

    -- Query the current write progress of the log system.
    SHOW STATUS LIKE 'Innodb_log_write_lsn'; 
    +----------------------+------------+
    | Variable_name        | Value      |
    +----------------------+------------+
    | Innodb_log_write_lsn | 1721889596 |
    +----------------------+------------+
    
    -- Query the physical file offset in bytes.
    SELECT lsn_to_pos(1721889596); 
    +------------------------+
    | lsn_to_pos(1721889596) |
    +------------------------+
    | ib_logfile1/648143676  |
    +------------------------+
Nota

Se você usar o recurso de nome de domínio global, incorrerá em taxas adicionais para resolução de DNS interno e transferência de dados entre regiões. Para mais informações, consulte Global domain name pricing.

Primeiros passos

  1. Create and manage a global database network: Selecione um cluster que atenda aos requirements para servir como cluster primário da GDN.

  2. Add a secondary cluster: Acesse a página de compra do PolarDB para adicionar um cluster secundário à GDN criada.

  3. Connect to a global database network: Em uma GDN, cada cluster (primário e secundário) fornece um endpoint de cluster independente. Conecte-se ao endpoint do cluster mais próximo com base na região da sua aplicação. A GDN também fornece um global domain name. Esse recurso oferece acesso local e um endpoint estável que persiste mesmo após um failover do cluster primário.