O recurso PolarDB for MySQL Multi-master Cluster (Limitless) atualiza um cluster da arquitetura de escrita única e múltipla leitura para uma arquitetura de múltipla escrita e múltipla leitura. Esse recurso permite gravações simultâneas de dados em diferentes bancos de dados ou objetos de dados em nós de computação distintos. Ele também oferece suporte ao agendamento dinâmico de bancos de dados e objetos de dados entre os nós, com trocas concluídas em segundos, o que melhora significativamente a capacidade geral de leitura e gravação simultânea do cluster. Os objetos de dados incluem tabelas, visualizações, gatilhos, eventos, procedimentos armazenados e funções. Este tópico descreve como usar um Multi-master Cluster (Limitless).
Pré-requisitos
Adquira um cluster Multi-master Cluster (Limitless). Para mais informações, consulte Custom Purchase e Purchase a subscription cluster.
Crie uma conta privilegiada. Para mais informações, consulte Create a privileged account.
Conecte-se ao cluster de banco de dados. Para mais informações, consulte Connect to a database cluster.
A versão 8.0 ou posterior do kernel do PolarDB for MySQL oferece suporte ao Multi-master Cluster (Limitless).
Limitações
Os dados de cada banco de dados ou objeto de dados podem ser gravados apenas por meio de um único nó primário. Nós sem um banco de dados ou objeto de dados atribuído não executam operações de leitura ou gravação. Por padrão, as operações ocorrem no nível do banco de dados. Para operar no nível do objeto de dados, use uma sintaxe específica para alternar o modo.
Não há suporte para consultas entre nós primários. Se uma consulta envolver bancos de dados ou objetos de dados residentes em diferentes nós primários, o sistema retornará um erro. Recomendamos mover os endpoints de todos os bancos de dados ou objetos de dados envolvidos para um único nó primário antes de executar a consulta.
Apenas endpoints de cluster, estão disponíveis. Não há suporte para endpoints primários.
-
A troca de endpoint está sujeita às seguintes condições:
Se utilizar o nível de isolamento de banco de dados, troque o endpoint do banco de dados.
Se utilizar o nível de isolamento de objeto de dados, troque o endpoint do objeto de dados.
-
Não há suporte para operações DDL entre nós primários. Se você executar uma instrução DDL em um banco de dados ou objeto de dados enquanto a conexão atual estiver em um nó primário que não seja o proprietário desse banco de dados ou objeto de dados, o sistema reportará o erro
Failed to get global lock for table 'xxx' on master N. Para resolver esse problema, execute as etapas a seguir:-
Execute o comando a seguir para consultar o nó primário proprietário da tabela de destino:
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';Localize o
master_idcorrespondente à tabela de destino no resultado da consulta. -
Execute o comando a seguir para alternar a sessão atual para o nó primário proprietário da tabela de destino:
ALTER SESSION POLARDB_WRITE_NODE <master_id>;Substitua
<master_id>pelo número real do nó primário obtido na etapa anterior. Após concluir a troca, execute novamente a instrução DDL.
-
Especificar um nó primário para um banco de dados
Crie um banco de dados em um nó primário específico. A sintaxe é a seguinte:
CREATE DATABASE name [POLARDB_WRITE_NODE master_id];Ao usar o nível de isolamento de banco de dados, os dados de cada banco só podem ser gravados por meio de um único nó primário.
Se você omitir
[POLARDB_WRITE_NODE master_id]na sintaxe, o sistema usará o valor do parâmetro loose_innodb_mm_default_master_id para especificar o nó primário onde o banco de dados será criado. Quando o valor do parâmetro loose_innodb_mm_default_master_id for 0, o sistema selecionará aleatoriamente um nó primário para criar o banco de dados. Para configurar esse parâmetro, acesse o console do PolarDB e acesse a página para view and modify cluster or node parameters.Para visualizar a distribuição dos bancos de dados entre os nós, consulte Query the database distribution.
Exemplo: Crie um banco de dados chamado db1 no nó primário 1.
CREATE DATABASE db1 POLARDB_WRITE_NODE 1;Para criar o banco de dados db1 no nó primário 2, altere 1 para 2 na instrução anterior.
Excluir um banco de dados
Para excluir um banco de dados criado em um nó primário específico, use a seguinte sintaxe:
DROP DATABASE name;Exemplo: Exclua o banco de dados db1 que foi criado no nó primário 1.
DROP DATABASE db1;Não é necessário especificar o nó primário ao excluir um banco de dados.
Alternar o endpoint de um banco de dados
Para transferir o endpoint do banco de dados para outro nó primário, utilize a sintaxe abaixo:
ALTER DATABASE name POLARDB_WRITE_NODE master_id;Exemplo: Transfira o endpoint do banco de dados db1 para o nó primário 2.
ALTER DATABASE db1 POLARDB_WRITE_NODE 2;A troca de endpoint pode ser uma operação demorada. O tempo de execução depende dos seguintes fatores:
Quanto mais tabelas o banco de dados contiver, mais lenta será a troca.
Quanto maior a carga de trabalho DML no banco de dados durante a troca, mais lenta será a operação.
Alternar para isolamento de objeto de dados
Por padrão, o nível de isolamento de um cluster multi-primário é o nível de banco de dados. Isso significa que todos os objetos de dados dentro do mesmo banco só podem ser acessados em um único nó primário. Caso deseje que todos os objetos de dados no mesmo banco sejam acessíveis por múltiplos nós primários, altere o nível de isolamento de banco de dados para o nível de isolamento de objeto de dados. A sintaxe é a seguinte:
ALTER DATABASE name TO TABLE_LOCK POLARDB_WRITE_NODE master_id;Nesta instrução, name especifica o nome do banco de dados e master_id define o endpoint do objeto de dados.
Exemplo: Altere o nível de isolamento do banco de dados db1 para o nível de isolamento de objeto de dados e defina seu endpoint como o nó primário 2.
ALTER DATABASE db1 TO TABLE_LOCK POLARDB_WRITE_NODE 2;A alteração do nível de isolamento pode ser uma operação demorada. O tempo de execução depende dos seguintes fatores:
Quanto mais objetos o banco de dados contiver, mais lenta será a troca.
Quanto maior a carga de trabalho DML no banco de dados durante a troca, mais lenta será a operação.
Alternar para isolamento de banco de dados
Se um banco de dados estiver configurado com o nível de isolamento de objeto de dados, você poderá revertê-lo para o nível de isolamento de banco de dados para facilitar o gerenciamento. Use a seguinte instrução:
ALTER DATABASE name TO DB_LOCK POLARDB_WRITE_NODE master_id;Nesta instrução, name especifica o nome do banco de dados e master_id define o endpoint do banco de dados.
Exemplo: Reverta o nível de isolamento do banco de dados db1 para o nível de isolamento de banco de dados e defina seu endpoint como o nó primário 1.
ALTER DATABASE db1 TO DB_LOCK POLARDB_WRITE_NODE 1;A alteração do nível de isolamento pode ser uma operação demorada. O tempo de execução depende dos seguintes fatores:
Quanto mais objetos o banco de dados contiver, mais lenta será a troca.
Quanto maior a carga de trabalho DML no banco de dados durante a troca, mais lenta será a operação.
Alternar o endpoint de um objeto de dados
Quando um cluster está no nível de isolamento de objeto de dados, um banco de dados pode conter vários tipos de objetos, incluindo tabela, visualização, gatilho, função, procedimento armazenado e evento. Para alternar o endpoint desses objetos, use a seguinte sintaxe:
ALTER obj_type name POLARDB_WRITE_NODE master_id;Nesta instrução, obj_type pode ser TABLE, VIEW, TRIGGER, FUNCTION, PROCEDURE ou EVENT. name representa o nome do objeto de dados.
Exemplo 1: Transfira o endpoint da tabela t1 no banco de dados db1 para o nó primário 3.
ALTER TABLE db1.t1 POLARDB_WRITE_NODE 3;Exemplo 2: Transfira o endpoint da visualização t2 no banco de dados atual para o nó primário 2.
ALTER VIEW t2 POLARDB_WRITE_NODE 2;Exemplo 3: Transfira o endpoint das funções f1 e f2 no banco de dados db2 para o nó primário 1.
ALTER FUNCTION db2.f1, db2.f2 POLARDB_WRITE_NODE 1;A troca de endpoint pode ser uma operação demorada. O tempo de execução depende dos seguintes fatores:
Quanto maior a carga de trabalho DML no objeto de dados durante a troca, mais lenta será a operação.
-
Objetos com dependências podem tornar-se inválidos se não estiverem localizados no mesmo nó primário.
Por exemplo, suponha que uma visualização chamada
VIEW1dependa de uma tabela chamadat1. Se o endpoint deVIEW1estiver no nó primário 1 e o endpoint det1estiver no nó primário 2, ocorrerá um erro ao consultarVIEW1no nó primário 1. Da mesma forma, chamadas a uma função, procedimento armazenado ou evento falharão se os objetos referenciados estiverem em nós primários diferentes. Um gatilho também falhará ao modificar uma tabela se seus endpoints estiverem em nós diferentes. Se existir uma restrição de chave estrangeira entre duas tabelas, como
t1et2, alterar o endpoint de uma tabela alterará automaticamente o endpoint da outra.
Especificar um nó primário para SQL
Este recurso aplica-se apenas a consultas de metadados, como consultas em information_schema ou variáveis de status. Se você precisar consultar dados, por exemplo, executando SELECT * FROM table1, não será necessário especificar um nó primário, pois o proxy de banco de dados roteia automaticamente a consulta para o nó primário correto.
Para enviar uma instrução SQL a um nó primário específico, execute a seguinte instrução SQL para bloquear a sessão nesse nó:
ALTER SESSION POLARDB_WRITE_NODE master_id;Exemplo: Consulte o valor da variável innodb_buffer_pool_size no nó primário 1.
ALTER SESSION POLARDB_WRITE_NODE 1; # Send the SQL statement to primary node 1.
SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; # Query the value of innodb_buffer_pool_size on primary node 1.Se você não especificar um nó primário ao executar uma instrução SQL, o proxy de banco de dados selecionará aleatoriamente um nó primário para executar a instrução.
Execute o comando a seguir para desbloquear a sessão do nó primário especificado:
RESET SESSION POLARDB_WRITE_NODE;Consultar a distribuição de bancos de dados
No console do PolarDB, acesse a página para visualizar a distribuição de todos os bancos de dados no cluster. A coluna MasterID exibe o número do nó RW ao qual cada banco de dados pertence (por exemplo, MasterID 1 indica que o banco de dados está no nó RW1, e MasterID 2 indica que está no nó RW2).
-
Execute os comandos a seguir para consultar a distribuição de bancos de dados em um nó primário 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 de bancos de dados no nó primário 1.
ALTER SESSION POLARDB_WRITE_NODE 1; SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';A seguinte saída é retornada:
SELECT * FROM INFORMATION_SCHEMA.INNODB_MASTER_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +------------+---------------------+----------+--------------+-----------+----------+-------------+-------------+---------------------+-----------------+ | 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)Embora a coluna seja nomeada
table_name, cada linha no resultado contém informações sobre um banco de dados ou um objeto de dados. Neste exemplo,sbtest,testetest2usam o nível de isolamento de banco de dados. Os objetostest3/f1,test3/e1etest3/v1usam o nível de isolamento de objeto de dados. O resultado também pode conter um objeto chamado mysql/global_ddl_lock com tipo de objeto tabela. Isso é para uso interno e pode ser ignorado. -
Execute o comando a seguir para consultar a distribuição de todos os bancos de dados no cluster:
NotaEsta consulta só pode ser executada usando uma conta privilegiada.
SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X';A seguinte saída é retornada:
mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_CC_GLOBAL_LOCK_INFO WHERE LOCK_MODE = 'SLS_X'; +-----------+------------+---------------------+-----------+-----------+-------------+---------------------+-----------------+ | 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)Embora a coluna seja nomeada
table_name, cada linha no resultado contém informações sobre um banco de dados ou objeto de dados e seu nó primário correspondente. O resultado também pode conter um objeto chamado mysql/global_ddl_lock com tipo de objeto tabela. Isso é para uso interno e pode ser ignorado.
Configurar o log binário
O Multi-master Cluster (Limitless) é totalmente compatível com o log binário do MySQL. Ele consolida logs de operação de todos os nós primários no cluster para gerar um log binário logicamente ordenado e globalmente unificado.
Use o parâmetro loose_polar_log_bin para ativar o recurso de log binário em um Multi-master Cluster (Limitless) e binlog_expire_logs_seconds para definir o período de retenção dos logs binários do Multi-master Cluster (Limitless). Para mais informações, consulte Enable binary logs.
O Multi-master Cluster (Limitless) pode ser usado como source e destino para o Data Transmission Service (DTS) realizar sincronização de dados unidirecional ou bidirecional.