GDN for Multi-write - PolarDB: Central de Documentação do Alibaba Cloud

Na edição básica de uma Global Database Network (GDN), o cluster secundário encaminha solicitações de escrita ao cluster primário. Esse processo pode causar latência significativa de escrita quando os clusters estão fisicamente distantes. O GDN para Multi-write oferece uma solução de multi-escrita no nível de tabela que permite a cada sub-cluster escrever localmente nas tabelas com permissão de escrita concedida. Esse design viabiliza o acesso baseado em proximidade tanto para leitura quanto para escrita, reduzindo efetivamente a latência de escrita entre regiões.

Nota

O PolarDB GDN para Multi-write está atualmente em visualização pública. Para usar este recurso, participe do nosso grupo no DingTalk e solicite acesso.

Número do grupo no DingTalk: 30245017864

Como funciona

O GDN para Multi-write utiliza a tecnologia de replicação física do PolarDB para fornecer capacidades de multi-escrita no nível de tabela em implantações entre regiões. Os mecanismos principais são:

Propriedade da permissão de escrita no nível de tabela: A permissão de escrita de cada tabela é atribuída estritamente a um único sub-cluster. Isso garante que apenas um sub-cluster possa escrever na tabela por vez.
Escritas locais: Cada sub-cluster pode escrever localmente nas tabelas para as quais detém permissão de escrita. Essa abordagem possibilita atualizações de dados com baixa latência e alto throughput.
Sincronização global de dados: Todas as alterações de dados são sincronizadas em tempo real com os demais sub-clusters por meio de um link de replicação física de alto desempenho, assegurando a consistência global dos dados.
Leitura completa dos dados: Todos os sub-clusters podem ler diretamente os dados mais recentes de todas as tabelas, permitindo acesso de leitura local em cenários entre regiões.

Considere um exemplo com três sub-clusters localizados na China (Hong Kong), Singapura e Alemanha (Frankfurt):

Ao criar a Tabela A no sub-cluster da China (Hong Kong), a permissão de escrita dessa tabela pertence, por padrão, ao sub-cluster da China (Hong Kong).
Ao criar a Tabela B no sub-cluster de Singapura, a permissão de escrita dessa tabela pertence ao sub-cluster de Singapura.
Ao criar a Tabela C no sub-cluster da Alemanha (Frankfurt), a permissão de escrita dessa tabela pertence ao sub-cluster da Alemanha (Frankfurt).

Todas as operações de escrita na Tabela A no sub-cluster da China (Hong Kong) são aplicadas diretamente aos dados locais. Simultaneamente, esse sub-cluster recebe alterações de dados da Tabela B e da Tabela C em tempo real, provenientes dos sub-clusters de Singapura e da Alemanha (Frankfurt), via replicação física. Dessa forma, o sub-cluster da China (Hong Kong) não apenas escreve localmente com eficiência (Tabela A), mas também lê diretamente os dados mais recentes de todas as tabelas (Tabela A, Tabela B e Tabela C). O mesmo princípio se aplica aos sub-clusters de Singapura e da Alemanha (Frankfurt).

Pré-requisitos

Seu cluster PolarDB deve estar executando a versão MySQL 8.0.2.

Crie uma GDN para Multi-write

Solicite acesso: O PolarDB GDN para Multi-write está atualmente em visualização pública. Para usar este recurso, participe do nosso grupo no DingTalk e solicite acesso. Número do grupo no DingTalk: 30245017864
Criar e gerenciar uma Global Database Network: Selecione um cluster que atenda aos pré-requisitos para ser o cluster primário da Global Database Network (GDN).

Importante
Ao criar uma GDN para Multi-write, o cluster primário reinicia uma vez.
Adicionar e gerencie um cluster secundário: Acesse a página de compra do PolarDB para adicionar clusters secundários à GDN.
Conectar-se a uma Global Database Network: Em uma GDN, cada sub-cluster (clusters primário e secundários) fornece um endpoint de cluster independente. Conecte-se ao endpoint de cluster mais próximo com base na região da sua aplicação. Além disso, a GDN fornece um nome de domínio global, que não apenas habilita o acesso baseado em proximidade, mas também permanece inalterado após um failover do cluster primário.
Com base nos requisitos do seu negócio, crie as tabelas necessárias no sub-cluster de uma região específica. Isso permite que cada sub-cluster escreva localmente nas tabelas para as quais detém permissão de escrita, viabilizando o acesso baseado em proximidade para leituras e escritas e reduzindo efetivamente a latência de escrita entre regiões.

Gerencie permissões de escrita de tabelas

Ao criar uma tabela em um sub-cluster, esse sub-cluster detém a permissão de escrita da tabela por padrão. A permissão de escrita de cada tabela é mantida por apenas um sub-cluster por vez, enquanto todos os outros sub-clusters têm acesso somente leitura a ela por padrão.

Transferir permissões de escrita

Utilize as seguintes instruções DDL para transferir dinamicamente a permissão de escrita de uma tabela entre sub-clusters:

Instrução	Descrição
ALTER TABLE <table_name> GDN_RELEASE;	Libera a permissão de escrita da tabela do sub-cluster atual. Após a execução, a tabela torna-se somente leitura no sub-cluster atual.
ALTER TABLE <table_name> GDN_FETCH;	Adquire a permissão de escrita da tabela no sub-cluster atual. Antes de executar esta instrução, libere a permissão de escrita do cluster original.

Visualize propriedade da permissão de escrita

Verifique a saída da instrução SHOW CREATE TABLE para determinar se o sub-cluster atual detém a permissão de escrita de uma tabela:

Se a saída contiver a tag /* GDN_REMOTE */, a permissão de escrita da tabela pertence a outro sub-cluster, e o sub-cluster atual possui apenas acesso somente leitura.
Caso a saída não contenha a tag /* GDN_REMOTE */, o sub-cluster atual detém a permissão de escrita da tabela.

Exemplo

O exemplo a seguir demonstra como transferir a permissão de escrita da tabela t_A, criada no sub-cluster da China (Hong Kong), para o sub-cluster de Singapura.

Crie uma tabela no sub-cluster da China (Hong Kong) e confirme a propriedade da sua permissão de escrita.

-- Create a table in the China (Hong Kong) sub-cluster.
CREATE TABLE t_A (id INT PRIMARY KEY);

-- Check the table schema. The output does not contain the GDN_REMOTE tag, which indicates that the write permission is held by the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Libere a permissão de escrita da tabela no sub-cluster da China (Hong Kong).

ALTER TABLE t_A GDN_RELEASE;

-- Check again. The output contains the GDN_REMOTE tag, which indicates that the write permission has been released.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8

Adquira a permissão de escrita da tabela no sub-cluster de Singapura.

ALTER TABLE t_A GDN_FETCH;

-- Check the table schema. The output does not contain the GDN_REMOTE tag, which indicates that the write permission has been transferred to the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

No sub-cluster da Alemanha (Frankfurt), verifique a tabela para confirmar que ela ainda é somente leitura.

-- The output contains the GDN_REMOTE tag, which indicates that the write permission is not held by the current sub-cluster.
SHOW CREATE TABLE t_A\G
Create Table: CREATE TABLE `t_A` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) /* GDN_REMOTE */ ENGINE=InnoDB DEFAULT CHARSET=utf8