PolarDB suporta duas políticas de balanceamento de carga para distribuir a carga entre vários nós de leitura: Connections-based Load Balancing e Active Request-based Load Balancing.
Políticas de balanceamento de carga
Connections-based Load Balancing: esta política é ideal para cenários de alto desempenho que não exigem recursos avançados, como níveis de consistência ou divisão de transações.
Active Request-based Load Balancing: o endpoint de cluster roteia automaticamente as solicitações de leitura entre vários nós de leitura com base no número de solicitações ativas. Esta política suporta recursos avançados, como níveis de consistência, divisão de transações e persistência de conexão, além de balancear a carga com base no status em tempo real de cada nó.
PolarDB Os endpoints de cluster do PolarDB no modo Read-only suportam tanto o Connections-based Load Balancing quanto o Active Request-based Load Balancing. Os endpoints de cluster no modo Read/Write (Automatic Read/Write Splitting) suportam apenas o Active Request-based Load Balancing.
A tabela a seguir compara as duas políticas.
Nome da política | Diferenças | Semelhanças |
Connections-based Load Balancing |
| Para um endpoint de cluster no modo Read-only, o proxy não encaminha nenhuma solicitação para o nó primário, independentemente da política de balanceamento de carga utilizada. |
Active Request-based Load Balancing |
|
Nó primário aceita solicitações de leitura
Se você defina Primary Node Accepts Read Requests como No, o PolarProxy deixa de enviar solicitações de leitura regulares para o nó primário. No entanto, o PolarProxy ainda envia solicitações de leitura dentro de uma transação que exigem consistência para o nó primário a fim de atender aos requisitos de negócios. Além disso, se todos os nós de leitura falharem, o PolarProxy também envia as solicitações de leitura para o nó primário. Se o seu negócio tiver requisitos de consistência baixos, você pode defina o nível de consistência como consistência eventual para reduzir as solicitações de leitura no nó primário. Você também pode usar o recurso de divisão de transações para reduzir as solicitações de leitura enviadas ao nó primário antes do início da transação real. O PolarProxy ainda envia solicitações de broadcast, como SET ou PREPARE, para o nó primário.
Você pode configure a opção Primary Node Accepts Read Requests apenas quando o Read/Write estiver definido como Read/Write (Automatic Read/Write Splitting). Para obter informações sobre como modifique a configuração Primary Node Accepts Read Requests, consulte Configure the database proxy.
Se a sua versão do PolarProxy for 1.x.x ou 2.5.1 ou posterior, as alterações na configuração Primary Node Accepts Read Requests entram em vigor imediatamente.
Se a sua versão do PolarProxy for 2.x.x e anterior a 2.5.1, as alterações na configuração Primary Node Accepts Read Requests entram em vigor somente após você restabelecer as conexões persistentes. Para conexões de curta duração, as alterações entram em vigor imediatamente.
Divisão de transações
Ao usar um endpoint de cluster do PolarDB no modo Read/Write (Automatic Read/Write Splitting), o PolarProxy distribui solicitações de leitura e gravação para o nó primário e os nós de leitura. Para garantir a consistência transacional dentro de uma sessão, o PolarProxy envia todas as solicitações dentro da transação para o nó primário. Por exemplo, alguns drivers de cliente de banco de dados, como o JDBC, encapsulam solicitações em transações por padrão. Como resultado, o driver envia todas as solicitações da aplicação para o nó primário, o que pode sobrecarregar o nó primário enquanto os nós de leitura são subutilizados, conforme mostrado na figura a seguir:
Para resolver esse problema, o PolarDB fornece o recurso de divisão de transações no nível de isolamento Read Committed. Esse recurso direciona solicitações de leitura dentro de uma transação para os nós de leitura a fim de reduzir a carga no nó primário, garantindo ao mesmo tempo a consistência de leitura/gravação para os seus service. Isso permite descarregar a pressão de leitura do nó primário para os nós de leitura e aumentar a estabilidade do nó primário sem alterar o código ou as configurações da sua aplicação. Para obter instruções detalhadas sobre como ative a divisão de transações, consulte Configure the database proxy.
O PolarDB for MySQL fornece dois níveis de divisão de transações: Divisão de solicitações de leitura antes da primeira solicitação de gravação (padrão, o recurso original de divisão de transações) e Divisão completa de transações (divisão de solicitações de leitura antes e após a primeira solicitação de gravação).
-
Divisão de solicitações de leitura antes da primeira solicitação de gravação
O PolarProxy envia as solicitações de leitura que precedem a primeira solicitação de gravação em uma transação para os nós de leitura, o que reduz a carga no nó primário.
-
Divisão completa de transações (divisão de solicitações de leitura antes e após a primeira solicitação de gravação)
Com a divisão de solicitações de leitura antes da primeira solicitação de gravação, o PolarProxy ainda roteia as solicitações de leitura que ocorrem após uma gravação para o nó primário, o que pode resultar em uma carga desbalanceada. Para resolver totalmente os problemas de balanceamento de carga causados pelas transações, o PolarDB for MySQL introduz a divisão completa de transações. Esse recurso permite rotear todas as operações de leitura de uma transação para os nós de leitura, garantindo resultados corretos e reduzindo ainda mais a pressão sobre o nó primário.
O PolarProxy só pode rotear uma solicitação de leitura após gravação para um nó de leitura se os dados da operação de gravação anterior na transação tiverem sido sincronizados com esse nó. Se você configurou a consistência de sessão, o PolarProxy verifica primeiro se o nó de leitura da sessão atual sincronizou as gravações anteriores antes de rotear a solicitação de leitura após gravação. Em caso afirmativo, ele roteia a solicitação para o nó de leitura; caso contrário, a roteia para o nó primário. Da mesma forma, se você configurou a consistência global, o PolarProxy verifica se as transações de todas as sessões atuais foram sincronizadas com o nó de leitura. Se sim, ele a roteia para o nó de leitura; caso contrário, a roteia para o nó primário. A divisão completa de transações não suporta a consistência eventual.
Versões e limitações
Para usar o recurso de divisão completa de transações, o seu cluster PolarDB for MySQL deve atender aos seguintes requisitos:
-
Versão do mecanismo:
PolarDB for MySQL 5.6, revisão 5.6.1.0.29 ou posterior.
PolarDB for MySQL 5.7, revisão 5.7.1.0.9 ou posterior.
PolarDB for MySQL 8.0.1, revisão 8.0.1.1.18 ou posterior.
PolarDB for MySQL 8.0.2, qualquer revisão.
-
Parâmetro do mecanismo:
O parâmetro
loose_query_cache_typedeve ser definido como OFF. O PolarDB for MySQL 5.6, 5.7 e 8.0.1 usam OFF por padrão. A versão 8.0.2 usa ON por padrão. A alteração desse parâmetro exige reiniciar o cluster PolarDB.
NotaA divisão de transações é compatível apenas com sessões no nível de isolamento Read Committed e é ativada por padrão.
Devido a restrições de consistência de leitura/gravação, o PolarProxy não roteia as solicitações de leitura para um nó de leitura se o seu nível de consistência não atender aos requisitos.
Se a sua versão do PolarProxy for anterior a 2.4.14, apenas a divisão de solicitações de leitura antes da primeira solicitação de gravação tem suporte. A divisão completa de transações não tem suporte.
Se a sua versão do PolarProxy for 2.4.14 ou posterior e a divisão de transações estiver configurada para divisão completa de transações, restabeleça as conexões persistentes para que a alteração entre em vigor. Para conexões de curta duração, a alteração entra em vigor imediatamente.
-
-
Desativar divisão de transações
Quando a divisão de transações está desativada, o PolarProxy roteia todas as solicitações dentro de uma transação para o nó primário.
Balanceamento de carga baseado em peso
Por padrão, o PolarProxy do PolarDB for MySQL roteia solicitações para o nó com o menor número de solicitações ativas (concorrentes). Essa política geralmente equilibra o tráfego entre os nós de back-end com base em sua carga. Ela também apresenta um bom desempenho quando os nós de back-end possuem especificações diferentes. No entanto, as cargas de trabalho de produção e os requisitos de distribuição de tráfego variam.
Para atender melhor a essas necessidades, o PolarDB for MySQL introduz o balanceamento de carga baseado em peso. É possível configure pesos diferentes para cada nó. Durante o processo de roteamento, o sistema usa tanto o peso quanto o número de solicitações simultâneas como critérios para ajustar dinamicamente a decisão final de roteamento. Atualmente, você pode configure os pesos nos dois níveis a seguir:
-
Dimensão global
Essa configuração se aplica a todos os endpoints.
-
Dimensão do endpoint
O peso na dimensão do endpoint aplica-se apenas ao balanceamento de carga desse endpoint e substitui a configuração global. Por exemplo, se você primeiro configure um peso na dimensão global e depois configure um peso separado para um endpoint específico, o balanceamento de carga para esse endpoint baseia-se na configuração no nível do endpoint.
Notes
Este recurso requer o PolarProxy 2.8.3 ou posterior.
Como a política de roteamento considera tanto a carga atual do nó quanto o peso definido pelo usuário, a proporção geral de tráfego pode desviar-se ligeiramente da proporção configurada. Com o tempo, ela converge gradualmente para a proporção configurada.
Clusters serverless não suportam a configuração de peso na dimensão do endpoint.
Como funciona
Durante o processo de roteamento de solicitações, o sistema calcula o peso final de cada nó dinamicamente com base no peso configurado e no número atual de solicitações simultâneas no nó. A fórmula simplificada é a seguinte:
Peso dinâmico = Peso configurado / Número de solicitações simultâneas
Quanto maior o peso dinâmico, maior a prioridade do nó. A política de balanceamento de carga por peso dinâmico oferece um método de roteamento flexível. Na prática, o tráfego muda gradualmente de acordo com os pesos configurados, o que pode levar mais tempo do que uma abordagem simples de round-robin ponderado.
Procedimento
Inicialmente, cada nó de back-end tem o mesmo peso padrão de 1.
O intervalo configurável para pesos é de 0 a 100.
Ao defina um peso como 0, o PolarProxy não roteia solicitações para esse nó em circunstâncias normais. O sistema seleciona o nó apenas se todos os outros nós estiverem indisponíveis.
Se um cluster tiver apenas um nó de leitura de armazenamento de colunas, o sistema ignora seu peso. Se um cluster tiver vários nós de leitura de armazenamento de colunas, o sistema balanceia as solicitações de armazenamento de colunas com base nos pesos desses nós.
configure pesos na dimensão global
Faça login no console do PolarDB.
No canto superior esquerdo, selecione a região onde o cluster está implantado.
Encontre o cluster de destino e clique em seu ID.
Na página Basic Information, na seção Standard Enterprise Edition ou Dedicated Enterprise Edition, clique em Database Proxy Settings.
-
Na caixa de diálogo Database Proxy Settings, defina um peso para cada nó com base nos requisitos do seu negócio.
A caixa de diálogo exibe a Role de cada nó (nó primário ou nó de leitura) e uma caixa de entrada Weight. Uma mensagem na parte superior indica que o sistema ajusta as decisões de roteamento dinamicamente com base nos pesos e nas solicitações simultâneas. Após terminar de defina os pesos, clique em OK.
Após configure os pesos, clique em OK.
configure pesos na dimensão do endpoint
Faça login no console do PolarDB.
No canto superior esquerdo, selecione a região onde o cluster está implantado.
Encontre o cluster de destino e clique em seu ID.
Na página Basic Information, na seção Standard Enterprise Edition ou Dedicated Enterprise Edition, clique em Configure no canto superior direito do endpoint de cluster ou endpoint personalizado.
-
Na página Modify Endpoint Settings, na área de nós de service, ative Configure Node Weight e defina um peso para cada nó.
Mova o nó de destino, como um nó de leitura de armazenamento de colunas, da lista Available Nodes para a lista Selected Nodes. Em seguida, defina um peso para o nó selecionado, como
1, e clique em OK. Após defina os pesos, clique em OK.
Dados de teste
A seguir, confira os dados reais de teste após a configuração dos pesos dos nós.
A proporção de peso dos três nós usados no teste é de 1:2:3 (o nó primário tem peso 1). Os resultados do teste de estresse atendem às expectativas (usando o conjunto de testes oltp_read_only do Sysbench).
Os dois nós internos, pi-bp1d1mtcobuzv** e pcbp14vvpolardbma23957, não participam do roteamento, portanto, ignore suas métricas.
Conexões sob demanda
Contexto
Para endpoints que usam Active Request-based Load Balancing, o PolarProxy cria conexões completas por padrão. Depois que o cliente estabelece uma sessão por meio do PolarProxy, o proxy estabelece uma sessão (conexão) com todos os nós de banco de dados dentro desse endpoint, criando uma relação de conexão 1:N. O PolarProxy roteia as solicitações de leitura normais nesta sessão para vários nós de banco de dados com base em sua carga ativa atual, enquanto roteia as solicitações de broadcast (como instruções SET) para todos os nós de banco de dados. Quando há muitos nós de banco de dados, a eficiência geral é significativamente reduzida devido à sobrecarga de estabelecimento de conexão e broadcast.
Como funciona
Com as conexões sob demanda, o PolarProxy estabelece conexões com os bancos de dados de back-end apenas conforme a necessidade. Ele minimiza o número de conexões de back-end enquanto atende aos requisitos de consistência e carga de leitura/gravação. Isso reduz a sobrecarga do banco de dados causada pelas conexões de proxy e pela execução de broadcast. Na maioria dos casos, uma sessão estabelece conexões com no máximo um nó primário e um nó de leitura (assumindo consistência eventual). Isso pode melhorar significativamente o desempenho para conexões de curta duração ou cargas de trabalho com muitas instruções de broadcast.
Conforme mostrado na figura acima, suponha que um cluster PolarDB tenha um nó primário (RW) e três nós de leitura (RO). Se a consistência não for um fator, a eficiência de roteamento de solicitações e leitura de dados nos três cenários é a seguinte:
-
Conexões completas
Uma única sessão de usuário através do PolarProxy estabelece conexões com todos os quatro nós de banco de dados, e o proxy roteia as instruções de broadcast para todos os quatro nós.
-
Conexões sob demanda, sessão somente leitura
Uma única sessão de usuário através do PolarProxy estabelece uma conexão com apenas um nó RO. O proxy roteia as solicitações de leitura (incluindo broadcasts) apenas para este único nó RO, melhorando significativamente a eficiência de leitura de dados.
-
Conexões sob demanda, sessão de leitura/gravação
Uma única sessão de usuário através do PolarProxy estabelece conexões com apenas um nó RO e um nó RW. O proxy roteia as solicitações de broadcast apenas para esses dois nós de banco de dados, também melhorando significativamente a eficiência de leitura de dados.
Casos de uso
Clusters com um grande número de nós RO.
Conexões de curta duração.
Cenários com muitas instruções de broadcast (por exemplo, em cenários de conexão de curta duração em PHP, a primeira instrução de uma sessão costuma ser semelhante a
set names utf8mb4).Cargas de trabalho com muitas consultas que usam instruções PREPARE curtas.
Limitações
Requer o PolarProxy 2.8.34 ou posterior. Para obter instruções sobre como verificar a versão do PolarProxy do seu cluster, consulte Check the version number.
Ao usar
SHOW PROCESSLISTSpara visualize o número de conexões de banco de dados, o comando pode não exibir o número total de conexões com todos os bancos de dados.Ao usar o comando KILL para encerrar uma conexão específica, o comando pode não encerrar a conexão especificada em todos os bancos de dados.
Teste de desempenho
Ambiente de teste
Nós de banco de dados: um nó de leitura/gravação (RW), sete nós de leitura (RO)
SQL usado para teste:
SET NAMES utf8mb4,SELECT 1Ferramenta de teste: Sysbench, com o mesmo número de conexões simultâneas para cada teste
Cenários de teste: o teste cobriu três cenários: sem pool de conexões, com pool de conexões no nível de sessão e com pool de conexões no nível de transação. Cada teste foi dividido em duas partes: a primeira metade sem as conexões sob demanda ativadas e a segunda metade com as conexões sob demanda ativadas.
Resultados do teste
-
Resultados do teste de desempenho para o cenário sem pool de conexões:
-
A figura abaixo mostra o consumo de CPU dos nós de banco de dados. Após ative as conexões sob demanda, o consumo de CPU do banco de dados diminuiu em mais de 60%:
-
O gráfico a seguir ilustra a mudança no número total de conexões com os nós de banco de dados. Após ative as conexões sob demanda, o número total de conexões diminuiu em mais de 80%:
-
A imagem abaixo apresenta a variação no QPS geral. Após ative as conexões sob demanda, o QPS geral aumentou em 35%:
-
-
Resultados do teste de desempenho para o cenário com pool de conexões no nível de sessão:
-
A figura abaixo mostra o consumo de CPU dos nós de banco de dados. Após ative as conexões sob demanda, o consumo de CPU do banco de dados diminuiu entre 50% e 60%:
-
O próximo gráfico exibe a alteração no número total de conexões com os nós de banco de dados. Após ative as conexões sob demanda, o número total de conexões diminuiu em 60%:
-
A imagem abaixo detalha a variação no QPS geral. Após ative as conexões sob demanda, o QPS aumentou em 30%:
-
-
Resultados do teste de desempenho para o cenário com pool de conexões no nível de transação:
-
A figura abaixo mostra o consumo de CPU dos nós de banco de dados. Após ative as conexões sob demanda, o consumo de CPU do banco de dados diminuiu em 60%:
-
O gráfico a seguir ilustra a mudança no número total de conexões com os nós de banco de dados. Após ative as conexões sob demanda, o número total de conexões diminuiu em 50%:
-
A imagem abaixo apresenta a variação no QPS geral. Após ative as conexões sob demanda, o QPS aumentou em 260%:
-