PolarDB:Load balancing

Políticas de balanceamento de carga

• Connections-based Load Balancing: Recomendada 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: Roteia solicitações de leitura automaticamente entre vários nós somente leitura em um endpoint de cluster, 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 equilibrar a carga conforme o status em tempo real de cada nó.

A tabela a seguir compara as duas políticas.

Nó primário aceita solicitações de leitura

Se você defina Primary Node Accepts Read Requests como No, o PolarProxy deixará de enviar solicitações regulares de leitura para o nó primário. No entanto, solicitações de leitura dentro de uma transação que exigem consistência ainda serão enviadas ao nó primário para atender aos requisitos de negócios. Além disso, se todos os nós somente leitura falharem, as solicitações de leitura também serão direcionadas ao nó primário. Caso seus negócios tenham baixos requisitos de consistência, defina o nível de consistência como consistência eventual para reduzir as solicitações de leitura no nó primário. Também é possível utilizar o recurso de divisão de transações para diminuir as solicitações de leitura enviadas ao nó primário antes do início efetivo da transação. Solicitações de broadcast, como SET ou PREPARE, continuam sendo enviadas ao nó primário.

Divisão de transações

Ao utilizar um endpoint de cluster do PolarDB no modo Read/Write (Automatic Read/Write Splitting), o PolarProxy distribui as solicitações de leitura e escrita entre o nó primário e os nós somente leitura. Para garantir a consistência transacional dentro de uma sessão, o PolarProxy envia todas as solicitações em transação para o nó primário. Por exemplo, alguns drivers de cliente de banco de dados, como JDBC, encapsulam solicitações em transações por padrão. Consequentemente, todas as solicitações da aplicação são enviadas ao nó primário, o que pode resultar em alta carga nesse nó enquanto os nós somente leitura permanecem subutilizados, conforme ilustrado na figura a seguir:

Para resolver essa questão, o PolarDB fornece o recurso de divisão de transações no nível de isolamento Read Committed. Esse recurso envia solicitações de leitura dentro de uma transação para os nós somente leitura, reduzindo a carga no nó primário e mantendo a consistência de leitura/escrita para seus serviços. É possível transferir a pressão de leitura do nó primário para os nós somente leitura e melhorar 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 Configurar o PolarProxy.

O PolarDB for MySQL oferece dois níveis de divisão de transações: Read request splitting before first write request (padrão, o recurso original de divisão de transações) e Full transaction splitting (read request splitting before and after first write request).

• Read request splitting before first write request

  O PolarProxy envia as solicitações de leitura que antecedem a primeira solicitação de escrita em uma transação para os nós somente leitura, o que reduz a carga no nó primário.

• Full transaction splitting (read request splitting before and after first write request)

  Com a divisão de solicitações de leitura antes da primeira escrita, as leituras que ocorrem após uma escrita ainda são roteadas para o nó primário, podendo causar desequilíbrio de carga. Para solucionar completamente os problemas de balanceamento causados por transações, o PolarDB for MySQL introduziu a divisão completa de transações. Este recurso permite rotear todas as operações de leitura dentro de uma transação para nós somente leitura, garantindo resultados corretos e aliviando ainda mais a pressão sobre o nó primário.

  Uma solicitação de leitura após escrita só pode ser roteada para um nó somente leitura se os dados da operação de escrita anterior na transação já tiverem sido sincronizados com esse nó. Se você configure a consistência de sessão, o PolarProxy verifica primeiro se o nó somente leitura da sessão atual sincronizou as escritas anteriores antes de rotear a solicitação de leitura após escrita. Em caso afirmativo, a solicitação vai para o nó somente leitura; caso contrário, é enviada ao nó primário. Da mesma forma, se a consistência global estiver configurada, o PolarProxy verifica se as transações de todas as sessões atuais foram sincronizadas com o nó somente leitura. Se sim, a solicitação é roteada para lá; senão, segue para o nó primário. A divisão completa de transações não suporta consistência eventual.

  Versões e limitações

  Para utilizar o recurso de divisão completa de transações, 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_type deve estar 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 a reinicialização do cluster PolarDB.

  Nota

  • A divisão de transações é suportada apenas para sessões no nível de isolamento Read Committed e está ativada por padrão.

  • Devido às restrições de consistência de leitura/escrita, as solicitações de leitura não são roteadas para um nó somente leitura se o nível de consistência dele não atender aos requisitos.

  • Se a versão do seu PolarProxy for anterior à 2.4.14, apenas a divisão de solicitações de leitura antes da primeira escrita é suportada. Não há suporte para divisão completa de transações.

  • Caso sua versão do PolarProxy seja 2.4.14 ou posterior e a divisão de transações esteja configurada como divisão completa, será necessário restabelecer as conexões persistentes para que a alteração tenha efeito. Para conexões de curta duração, a mudança entra em vigor imediatamente.

• Desativar a divisão de transações

  Quando a divisão de transações está desativada, todas as solicitações dentro de uma transação são roteadas 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 backend com base na carga de cada um. Ela também apresenta bom desempenho quando os nós de backend 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 introduziu o balanceamento de carga baseado em peso. É possível configure pesos diferentes para cada nó. Durante o processo de roteamento, tanto o peso quanto o número de solicitações simultâneas são usados como critérios para ajustar dinamicamente a decisão final de roteamento. Atualmente, os pesos podem ser configurados nos dois níveis a seguir:

• Dimensão global

  Esta configuração aplica-se a todos os endpoints.

• Dimensão do endpoint

  O peso na dimensão do endpoint aplica-se apenas ao balanceamento de carga desse endpoint específico e substitui a configuração global. Por exemplo, se você configure primeiro um peso na dimensão global e depois defina um peso separado para um endpoint específico, o balanceamento de carga para esse endpoint seguirá a configuração de nível de endpoint.

Conexões sob demanda