Não se pode fazer load balancing de uma escrita.
Nós de base de dados idênticos parecem capacidade de escrita multiplicada. Espalhe as suas escritas por eles e o cluster fabrica deadlocks. O desenho que funciona.
Neste artigo 2 secções
- A configuração intuitiva de um cluster: nós idênticos, um load balancer, tudo em round-robin. Parece capacidade multiplicada.
- Sob carga perfeitamente normal entrega erros de deadlock a editores a meio da publicação, sem nenhum bug de locking em lado nenhum do código. Dois editores, dois nós, uma linha quente, e a verificação de conflitos do cluster devolve um deles.
- A solução contraintuitiva: todas as escritas vão para um nó eleito, e só as leituras se distribuem.
- A reviravolta que responde ao «mas distribuir não é mais rápido?»: o volume de escritas raramente é a limitação. A capacidade de leitura é o que escala, e os erros desaparecem.
Comprou um cluster de base de dados. Ninguém compra várias unidades de uma coisa para usar uma, por isso a configuração do load balancer praticamente escreve-se sozinha: round-robin de tudo por todos os nós. A crença por baixo é simples: uma única query não vai ficar mais rápida, mas muitas vão, divididas pelas máquinas. Soa obviamente correto. É também a forma mais comum que vemos de esta classe de cluster ser mal utilizada.
O bug que não está no código
Sob carga normal, os editores carregam de vez em quando em guardar e recebem de volta um erro em bruto da base de dados através do CMS: deadlock found. É intermitente e difícil de reproduzir, e por mais que se leia o código da aplicação não se encontra, porque o bug não está no código.
A carga de trabalho que se torna a arma é uma carga comum. Um CMS reescreve uma mão-cheia de linhas de configuração com nomes globais em quase todas as ações. Um plugin de SEO reconstrói o sitemap em cada gravação. Marcas temporais de login e contadores de visualizações tocam todos nas mesmas linhas quentes. O round-robin espalha essas escritas concorrentes por todos os nós. Cada nó aceita a sua própria escrita localmente, e depois o passo de certification do cluster apanha a colisão no momento do commit e devolve-a a um cliente que não fez nada de errado. Dois editores, dois nós, a mesma linha: erro 1213.
Um deadlock sob carga normal, num cluster, sem nenhum padrão de locking em lado nenhum da aplicação, é um sintoma de encaminhamento. A carga de trabalho não está errada. A topologia está.
Um único writer por segurança, distribua as leituras
Canalizar todas as escritas para um nó desperdiça os outros? Não. As leituras equilibram-se uniformemente por todo o cluster e todas as escritas vão para o único writer eleito. O instinto do round-robin está certo quanto às leituras e errado quanto às escritas; o encaminhamento com um único writer mantém a metade que está certa e apaga os erros que a outra metade gera. Se o seu primeiro instinto num cluster carregado é escalar para cima, a lição irmã é que a jogada certa é muitas vezes a oposta (dimensione para baixo, não para cima).
1213
1
“Um cluster é multi-primary-capable e single-writer-safe. São frases diferentes.”
Se opera um cluster com leituras equilibradas, vá descobrir onde as suas escritas realmente aterram. Se a resposta for «onde quer que o balancer as envie», está a uma tarde movimentada de fabricar deadlocks a partir do seu próprio sucesso. A verificação custa uma leitura de configuração. A solução é uma regra de encaminhamento, não uma reescrita.
Respostas diretas
Porque é que recebo erros de deadlock (1213) no meu cluster Galera ou PXC sob carga normal?+
Se não há nenhum bug de locking no seu código, verifique o encaminhamento das escritas. Escritas espalhadas pelos nós colidem em linhas quentes no momento da certification, e o cluster reporta a colisão como um deadlock a um cliente inocente. Encaminhe todas as escritas para um nó e toda a classe de erro desaparece.
Enviar todas as escritas para um nó não desperdiça o meu cluster?+
As escritas quase nunca são o ponto de estrangulamento; as leituras são o volume. Com encaminhamento de um único writer, as leituras continuam a equilibrar-se por todos os nós e o throughput de escrita não muda, porque na prática um nó sempre fez todo o trabalho de escrita.
Um cluster Galera consegue fazer escritas multi-master?+
É capaz de aceitar escritas em todos os nós, e é seguro quando não tem de certificar escritas concorrentes em linhas quentes vindas de vários ao mesmo tempo. Multi-primary-capable, single-writer-safe. Use a capacidade para failover, não para distribuição de carga.
Então como escalo as escritas da base de dados?+
Primeiro prove que precisa: meça o volume de escritas face à margem do único writer, que normalmente é um erro de arredondamento ao lado das leituras. O verdadeiro escalamento de escritas é território de sharding ou de redesenho da carga de trabalho, não uma definição do load balancer.
O que encaminha leituras e escritas de forma diferente?+
Uma camada de proxy que fala o protocolo da base de dados consegue separá-las: as leituras distribuem-se, as escritas fixam-se no writer eleito, e o failover reelege um writer automaticamente. Operamos este padrão em produção: ProxySQL à frente de Percona XtraDB Cluster.
Vê deadlocks que não consegue encontrar no seu código?
Envie-nos apenas o erro e a forma como o seu cluster está equilibrado. Se for a topologia, mostramos-lhe, e corrigimos no encaminhamento, não na sua aplicação.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro