O PolarDB for MySQL Multi-master Cluster (Limitless) Edition expande o cluster de um modelo de escritor único para múltiplos escritores. Cada nó de leitura e escrita (RW) processa gravações simultâneas nos bancos de dados e objetos de dados atribuídos a ele. Você pode reatribuir bancos de dados ou objetos entre nós em segundos para rebalancear a carga de gravação.
Conceitos principais
|
Conceito |
Descrição |
|
Nó RW |
Nó de computação de leitura e escrita. Cada banco de dados ou objeto de dados é atribuído a exatamente um nó RW para gravações. |
|
Nível de isolamento de banco de dados |
Modo padrão. Todos os objetos de um banco de dados gravam por meio de um único nó RW. |
|
Nível de isolamento de objeto de dados |
Modo opcional no qual objetos individuais do mesmo banco de dados (tabelas, visualizações, gatilhos, funções, procedimentos armazenados e eventos) podem ser atribuídos a diferentes nós RW. |
|
Endpoint |
Nó RW atribuído a um banco de dados ou objeto de dados. Alternar um endpoint transfere a atribuição de gravação para outro nó. |
Pré-requisitos
Antes de começar, verifique se você tem:
Um cluster Multi-master Cluster (Limitless) Edition. Para mais informações, consulte Compra personalizada e Comprar um cluster por assinatura
Uma conta privilegiada. Para mais informações, consulte Criar uma conta privilegiada
Uma conexão com o cluster. Para mais informações, consulte Conectar-se a um cluster de banco de dados
PolarDB for MySQL 8.0
Fluxo de trabalho típico
O fluxo de trabalho comum para um novo cluster consiste em:
Crie bancos de dados e atribua cada um a um nó RW.
(Opcional) Alterne o endpoint de um banco de dados para rebalancear a carga de gravação entre os nós.
(Opcional) Mude um banco de dados para o nível de isolamento de objeto de dados para permitir a atribuição de nós por objeto individual.
Limitações
Consultas entre nós
Cada banco de dados ou objeto de dados aceita gravações de apenas um nó. Não é possível ler ou gravar dados em um nó sem o banco de dados ou objeto correspondente atribuído. Se uma consulta envolver bancos de dados ou objetos em múltiplos nós RW, o sistema retornará um erro. Mova todos os bancos de dados ou objetos envolvidos para um único nó RW antes de executar esse tipo de consulta.
Tipos de endpoint
Somente endpoints de cluster são suportados. Endpoints primários não são compatíveis.
Objetos dependentes
Quando objetos fazem referência uns aos outros, ambos devem residir no mesmo nó RW:
Uma visualização e as tabelas referenciadas por ela precisam compartilhar o mesmo nó. Se VIEW1 depender da tabela t1, mas seus endpoints forem diferentes, o acesso a VIEW1 resultará em erro.
Funções, procedimentos armazenados e eventos falharão caso qualquer objeto referenciado esteja em um nó diferente.
Um gatilho e sua tabela associada devem estar no mesmo nó. Caso contrário, operações de Linguagem de Manipulação de Dados (DML) na tabela apresentarão falha.
Chaves estrangeiras
Se existir uma restrição de chave estrangeira entre duas tabelas, alterar o endpoint de uma delas modificará automaticamente o endpoint da outra.
Criar um banco de dados em um nó RW específico
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];Exemplo: Crie db1 no RW1.
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;Para criar db1 no RW2, substitua 1 por 2.
Se você omitir
POLARDB_WRITE_NODE
, o cluster atribuirá o banco de dados ao nó especificado pelo parâmetro
loose_innodb_mm_default_master_id
. Quando o valor do parâmetro for
0
, o cluster escolherá um nó aleatoriamente — os bancos de dados serão distribuídos pelos nós sem um posicionamento previsível. Isso funciona bem para cargas balanceadas, mas não para cenários que exigem controle preciso sobre a distribuição de dados. Para visualizar ou alterar esse parâmetro, acesse
Configuration And Management
>
Parameter Settings
no
e
visualize e modifique parâmetros de cluster ou nó
.
Excluir um banco de dados
DROP DATABASE name;Não é necessário especificar POLARDB_WRITE_NODE ao excluir um banco de dados.
Exemplo: Exclua db1.
DROP DATABASE db1;Alternar o endpoint de um banco de dados
Transfira a atribuição de gravação de um banco de dados para outro nó RW:
ALTER DATABASE name POLARDB_WRITE_NODE master_id;Exemplo: Alterne db1 para o RW2.
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;A duração da alternância depende de dois fatores: o número de tabelas no banco de dados (mais tabelas aumentam o tempo) e a pressão de DML durante o processo (maior pressão aumenta o tempo necessário).
Alternar do nível de isolamento de banco de dados para o nível de isolamento de objeto de dados
Por padrão, todos os objetos de um banco de dados compartilham o mesmo nó RW. Para atribuir objetos individuais a nós diferentes, alterne o banco de dados para o nível de isolamento de objeto de dados:
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;Exemplo: Alterne db1 para o nível de isolamento de objeto de dados e defina o endpoint inicial como RW2.
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;A duração da alternância depende de dois fatores: o número de objetos no banco de dados (mais objetos aumentam o tempo) e a pressão de DML durante o processo.
Alternar do nível de isolamento de objeto de dados para o nível de isolamento de banco de dados
Para consolidar todos os objetos de um banco de dados novamente em um único nó:
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;Exemplo: Retorne db1 ao nível de isolamento de banco de dados e defina o endpoint como RW1.
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;A duração da alternância depende de dois fatores: o número de objetos no banco de dados (mais objetos aumentam o tempo) e a pressão de DML durante o processo.
Alternar o endpoint de um objeto de dados
Após mudar para o nível de isolamento de objeto de dados, atribua objetos individuais a nós específicos. Os tipos de objeto suportados são TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE e EVENT.
ALTER obj_type name POLARDB_WRITE_NODE master_id;Exemplos:
Mova a tabela t1 em db1 para o RW3:
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;Transfira a visualização t2 no banco de dados atual para o RW2:
ALTER VIEW t2 POLARDB_WRITE_NODE 2;Atribua as funções f1 e f2 em db2 ao RW1:
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;Alternar um endpoint geralmente é uma operação demorada. O tempo de execução depende da pressão de DML sobre o objeto de dados durante a alternância. Quanto maior a pressão de DML, mais lenta será a operação.
Roteiar uma instrução SQL para um nó RW específico
Isso se aplica apenas a consultas sem dados, como consultas em information_schema ou variáveis de status. Para consultas de dados como SELECT * FROM table1, o proxy de banco de dados roteia automaticamente para o nó correto — nenhum roteamento manual é necessário.
Para fixar uma sessão a um nó RW específico:
ALTER SESSION POLARDB_WRITE_NODE master_id;Para liberar a fixação:
RESET SESSION POLARDB_WRITE_NODE;Exemplo: Consulte o valor de innodb_buffer_pool_size no RW1.
ALTER SESSION POLARDB_WRITE_NODE 1; -- Route to RW1
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; -- Query on RW1Sem a fixação de sessão, o proxy de banco de dados roteia as instruções para um nó RW selecionado aleatoriamente.
Consultar a distribuição de bancos de dados
Visualizar distribuição no console
Acesse Configuration And Management > Database Management no console do PolarDB para visualizar todos os bancos de dados e suas atribuições de nós.
Consultar distribuição em um nó específico
ALTER SESSION POLARDB_WRITE_NODE master_id;
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Exemplo: Consulte a distribuição no RW1.
ALTER SESSION POLARDB_WRITE_NODE 1;
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Saída de exemplo:
+------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+
| table_name | table_id | space_id | s_lock_count | lock_mode | object | current_lsn | hold_thread | hold_start_time | hold_total_time |
+------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+
| test3/f1 | 9149389368458135753 | 0 | 0 | SLS_X | function | 28076635 | 17 | 2024-07-10 21:35:20 | 214 |
| test3/e1 | 9149389368458332874 | 0 | 0 | SLS_X | event | 28077248 | 17 | 2024-07-10 21:35:30 | 204 |
| test3/v1 | 9149389368457234649 | 0 | 0 | SLS_X | view | 28075972 | 17 | 2024-07-10 21:35:08 | 226 |
| sbtest | 2107518311328629409 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-07 23:04:41 | 254053 |
| test | 7190879906290573778 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:20:57 | 37077 |
| test2 | 3381728963524265351 | 0 | 0 | SLS_X | db | 28034927 | 4294967295 | 2024-07-10 11:13:09 | 37545 |
+------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+
6 rows in set (0.00 sec)Cada linha representa um banco de dados ou objeto de dados. Neste exemplo, sbtest, test e test2 usam o nível de isolamento de banco de dados, enquanto test3/f1 (função), test3/e1 (evento) e test3/v1 (visualização) utilizam o nível de isolamento de objeto de dados. Uma entrada chamada mysql/global_ddl_lock com tipo de objeto Table também pode aparecer — trata-se de metadados internos e pode ser ignorada.
Consultar distribuição em todos os nós
Esta consulta exige uma conta privilegiada. Não é possível executá-la com uma conta recém-criada.
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Saída de exemplo:
+-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+
| master_id | table_name | table_id | lock_mode | object | current_lsn | hold_start_time | hold_total_time |
+-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+
| 1 | test3/v1 | 9149389368457234649 | SLS_X | view | 28075972 | 2024-07-10 21:35:08 | 754 |
| 2 | test5/t1 | 9149389447232697561 | SLS_X | table | 7256175 | 2024-07-10 21:46:36 | 66 |
| 1 | test2 | 3381728963524265351 | SLS_X | db | 28034927 | 2024-07-10 11:13:09 | 38073 |
| 2 | test4 | 3381728963524272009 | SLS_X | db | 7255352 | 2024-07-10 21:46:27 | 75 |
| 1 | test3/f1 | 9149389368458135753 | SLS_X | function | 28076635 | 2024-07-10 21:35:20 | 742 |
| 1 | test3/e1 | 9149389368458332874 | SLS_X | event | 28077248 | 2024-07-10 21:35:30 | 732 |
| 1 | test | 7190879906290573778 | SLS_X | db | 28034927 | 2024-07-10 11:20:57 | 37605 |
| 2 | test5/p1 | 9149389447233473757 | SLS_X | procedure | 7257051 | 2024-07-10 21:46:45 | 57 |
| 1 | sbtest | 2107518311328629409 | SLS_X | db | 28034927 | 2024-07-07 23:04:41 | 254581 |
+-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+
9 rows in set (0.00 sec)A coluna master_id indica a qual nó RW cada banco de dados ou objeto de dados está atribuído. Uma entrada chamada mysql/global_ddl_lock com tipo de objeto Table também pode aparecer — trata-se de metadados internos e pode ser ignorada.
Configurar logs binários
O Multi-master Cluster (Limitless) Edition é totalmente compatível com logs binários do MySQL. Ele mescla logs de operação de todos os nós RW em logs binários logicamente ordenados e globalmente unificados.
Para ativar logs binários, configure o parâmetro
loose_polar_log_bin.Para definir o período de retenção dos logs binários, configure
binlog_expire_logs_seconds.
Para obter instruções de configuração, consulte Ativar logs binários.
Um cluster Multi-master Cluster (Limitless) Edition pode atuar como source ou destino para o Data Transmission Service (DTS) em sincronizações de dados unidirecionais ou bidirecionais.