Utilizar o MariaDB MaxScale como proxy de base de dados

Configurar o MaxScale como camada de proxy

MariaDB MaxScale é uma camada de proxy independente entre a aplicação e os servidores MariaDB. Para garantir um funcionamento fiável, a configuração, as funcionalidades disponíveis e as limitações conhecidas devem corresponder sempre à versão efetivamente instalada. A série MaxScale 25.10 é apresentada na documentação oficial com as suas próprias notas de lançamento.

A aplicação liga-se a um «listener» do MaxScale, em vez de se ligar diretamente a um servidor de base de dados. Um serviço agrupa a lógica de acesso, um «router» determina o backend e os filtros podem processar adicionalmente as solicitações antes do reencaminhamento. Os dados permanecem nos backends MariaDB; o MaxScale não se torna, por si só, uma base de dados.

Esta separação é particularmente útil quando não se pretende que uma aplicação saiba, por si própria, qual o servidor que desempenha atualmente cada função. Para noções básicas sobre o modelo de dados, SQL e o funcionamento da base de dados, consulte o artigo MariaDB como base de dados de código aberto um complemento adequado. O proxy complementa a arquitetura do servidor, mas não substitui nem os direitos de acesso à base de dados nem um conceito de replicação e de gestão de falhas.

Em Roteamento de ligações Ao estabelecer uma sessão, o MaxScale seleciona um destino; este backend permanece responsável pela sessão. No encaminhamento de instruções, o router pode atribuir instruções SQL individuais de forma diferente com base no seu conteúdo. A variante mais adequada depende, portanto, das transações, do estado da sessão e da capacidade da aplicação de separar de forma clara os caminhos de leitura e de escrita.

A Proxy de base de dados não constitui uma garantia geral de desempenho. Pode centralizar o encaminhamento, dissociar a alternância de funções das aplicações ou distribuir os pedidos de leitura adequados. No entanto, nós de rede adicionais, a análise SQL e a topologia concreta do backend influenciam o comportamento. A resiliência e a capacidade devem, por isso, ser verificadas com a sua própria versão, configuração e carga.

Monitorizar corretamente a topologia primária-réplica

Uma arquitetura-alvo típica é composta por um primário com capacidade de gravação e uma ou mais réplicas de leitura. O MaxScale é o único ponto de acesso à base de dados da aplicação, por exemplo, por trás de um nome DNS fixo. Consequentemente, a aplicação não se liga diretamente a hosts individuais; a seleção de um backend acessível e adequado ocorre na camada de proxy.

No caso de uma topologia primária-réplica, o monitor determina mariadbmon o estado dos back-ends e identifica as suas funções como «Primário» ou «Réplica». Os routers podem utilizar esta informação para a seleção dos destinos. Por conseguinte, o monitor tem de ser capaz de visualizar a topologia real da replicação; atribuições erradas, dados não replicados ou funções pouco claras não constituem problemas de encaminhamento, mas sim riscos operacionais.

É necessário distinguir entre a identificação de um papel e a sua alteração. Com a configuração e as autorizações adequadas, o mariadbmon pode gerir o failover, o switchover planeado e o rejoin. Uma transição é uma mudança de função preparada de forma deliberada para fins de manutenção ou operação; um failover responde a uma falha. Ambos os processos exigem uma topologia clara, monitorização, alertas e um processo documentado de gestão de incidentes ou de retorno ao normal.

Para tarefas exclusivamente de monitorização, a conta de monitorização deve seguir o princípio Menos privilégio recebem apenas os direitos necessários. A documentação atual refere-se a isto como REPLICA MONITOR. São necessários direitos adicionais, dependendo das funções ativadas, como, por exemplo, o direito FILE para verificar o espaço de armazenamento ou outros direitos específicos para análises de topologia e manipulações de clusters. Os direitos totais genéricos não constituem um substituto para estes.

Antes de proceder à automatização, a equipa deve definir quem autoriza uma mudança de função, como é verificado o estado das réplicas e como as aplicações são informadas sobre falhas. O MaxScale pode ajustar os destinos de encaminhamento com base nas funções identificadas. No entanto, a decisão sobre se uma comutação é tecnicamente admissível cabe ao conceito de alta disponibilidade, com os seus limites em termos de dados, tempo e responsabilidades.

Compreender o encaminhamento SQL e os limites de consistência

O router readwritesplit encaminha as instruções SQL de gravação para o servidor primário e distribui as consultas de leitura adequadas pelas réplicas. Desta forma, um conjunto de servidores primários e réplicas pode utilizar a sua capacidade de leitura de forma mais direcionada, sem que a aplicação tenha de atribuir cada consulta a um servidor. A informação sobre as funções do monitor constitui a base para essa seleção.

Esta divisão, na configuração padrão, não garante que uma leitura veja o novo estado imediatamente após cada gravação. causal_reads está definido por predefinição como none. Se, por exemplo, uma aplicação gravar o estado de uma encomenda e, em seguida, o ler através de uma consulta independente, uma réplica pode, por isso, ainda fornecer o estado anterior. Uma rota de leitura primária escolhida deliberadamente ou um contexto de transação comum são estratégias possíveis, mas não as únicas.

Para Leitura das gravações Com o «readwritesplit» ativado e as «Causal Reads» ativadas, é possível ter em conta as gravações anteriores, apesar do atraso nas réplicas. O modo local garante a visibilidade dessa mesma ligação. global mantém o estado do GTID guardado pelo serviço em todas as suas ligações; uma ordem global «happens-before» das leituras só é garantida se todas as transações se encontrarem dentro de um único domínio GTID. universal tem em conta o estado das transações do cluster observável no Primary. No entanto, os âmbitos de aplicação mais amplos aumentam o esforço de sincronização e, consequentemente, potencialmente a latência.

As leituras causais utilizam informações GTID e, nos modos não rápidos, aguardam a replicação. Se a sincronização demorar mais do que causal_reads_timeout – por predefinição, 10 segundos –, o readwritesplit tenta executar a consulta no servidor primário. Numa transação de só leitura, pode, em vez disso, ocorrer um tempo limite como erro, uma vez que a consulta não pode ser transferida para o servidor primário.

Os modos rápidos fast, fast_global e fast_universal não esperam por uma réplica e, se necessário, utilizam o primário; o tempo limite não se aplica nesse caso. Por isso, são especialmente adequadas para cargas de trabalho predominantemente de leitura, com poucas gravações. A partir da versão 24.02 do MaxScale, o próprio MaxScale configura o acompanhamento necessário para novas ligações ao backend; as versões anteriores requerem, para isso, last_gtid em session_track_system_variables em todos os back-ends.

No âmbito de uma transação aberta de leitura e escrita, a regra «readwritesplit» encaminha os acessos de leitura para o servidor primário. Isto evita que as instruções da mesma transação sejam executadas em back-ends com diferentes estados de replicação. Esta regra conservadora não dispensa a necessidade de definir limites de transação de forma tecnicamente correta e de tratar o atraso de replicação como um limite próprio da arquitetura.

Também no caso de procedimentos armazenados, chamadas de UDF e instruções múltiplas, a decisão é deliberadamente mais cautelosa: em casos documentados, essas consultas são encaminhadas para o Primary. A razão é que o seu efeito ou contexto não deve ser tratado como uma simples consulta de leitura. O encaminhamento SQL não é, portanto, uma mera pesquisa pela palavra SELECT, mas segue regras para o tratamento seguro das sessões e da semântica.

Um valor-limite definido com base em critérios técnicos para Réplica-Lag pode excluir réplicas de determinadas decisões de leitura, mas não substitui qualquer requisito de consistência. O atraso aceitável depende, por exemplo, de se uma entrada desatualizada no catálogo é tolerável ou se um estado de pagamento recém-confirmado tem de ser obrigatoriamente visível. Esta decisão deve ser tomada no âmbito da lógica da aplicação e do contrato de prestação de serviços, e não numa predefinição geral do proxy.

Configurar o Readwritesplit de forma segura

Uma configuração de divisão de leitura/gravação consiste em definições de objetos separadas para backends, monitor, serviço e listener. O excerto seguinte mostra a estrutura de um ficheiro, não um modelo pronto a ser utilizado em produção. Os valores entre parênteses angulares não são, expressamente, palavras-passe, mas sim referências a contas e segredos que devem ser disponibilizados através da gestão de segredos do ambiente de produção. O monitor e o serviço necessitam, cada um, dos seus próprios dados de acesso para as suas diferentes tarefas.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Os objetos de servidor referem-se apenas a backends MariaDB acessíveis; o monitor determina, com base na topologia, qual das instâncias é a Primária ou a Réplica. A conta do monitor é utilizada para consultas de estado e de funções. A conta de serviço separada serve para obter dos back-ends as informações de utilizador e de direitos necessárias para a autenticação e autorização do cliente. Ambas as contas necessitam apenas dos direitos documentados para as respetivas tarefas. Identificar papéis Carregar o código e as informações do utilizador são tarefas distintas.

Os espaços reservados no exemplo devem ser substituídos durante a implementação através de um canal de implementação protegido; não se destinam a ser valores de configuração literais. Não devem constar em ficheiros ou repositórios de acesso livre palavras-passe em texto simples, caminhos reais de certificados ou pacotes de direitos não verificados. O MaxScale gere internamente as contas de utilizador e as autorizações relevantes para as ligações de protocolo MariaDB a partir das tabelas do sistema. Se as contas ou as autorizações forem alteradas, as informações desatualizadas podem comprometer o início de sessão ou a autorização.

Por isso, antes da ativação, é necessário verificar separadamente a porta do listener, os caminhos de rede, a correspondência de utilizadores e a atribuição efetiva do router. Além disso, as intervenções automáticas do monitor não estão implicitamente incluídas nesta configuração mínima: as funções de failover, switchover ou rejoin exigem uma configuração adicional e um conceito operacional testado. Uma configuração aparentemente breve não substitui nem a gestão de segredos nem a verificação da topologia do backend.

Comparar modelos de routers por aplicação

A escolha do router depende do comportamento da aplicação, e não apenas do número de réplicas existentes. As ligações diretas simplificam a configuração, mas deixam a mudança de destino e o reconhecimento de funções a cargo da aplicação. Dois pontos finais separados com readconnroute são adequadas quando a aplicação gere deliberadamente as próprias ligações de leitura e escrita. Roteamento de extratos A utilização do `readwritesplit` faz sentido quando se pretende direcionar uma sessão, em função do SQL, para o servidor principal ou para as réplicas.

O readconnroute avalia um servidor de destino durante o estabelecimento da ligação e não analisa cada instrução SQL subsequente. Se o backend selecionado falhar, a sessão é encerrada; o router não a redireciona automaticamente para outro servidor. Isto é frequentemente compreensível no caso de ligações de leitura claramente separadas e de curta duração, mas pode ser inadequado para fluxos de trabalho de aplicações com estado.

É necessário ter especial cuidado com um serviço concebido como ponto final de leitura com router_options=slave. Esta opção dá preferência a servidores com a função de réplica; no entanto, se todas as réplicas estiverem inoperacionais e o servidor primário estiver disponível, a readconnroute pode recorrer ao servidor primário. Além disso, esta opção não cria qualquer proteção contra gravação. A aplicação deve enviar exclusivamente SQL de leitura, ou um filtro ReadOnly adicional deve impedir os acessos de gravação. O destino de encaminhamento e a preferência de função não constituem, portanto, nem um limite de autorização nem um substituto para direitos restritivos na base de dados.

Por outro lado, o readwritesplit reduz as decisões de destino no código da aplicação, mas exige uma análise precisa da semântica. As leituras adequadas podem ser distribuídas pelas réplicas, enquanto as operações de escrita são encaminhadas para o primário. Para processos com requisitos rigorosos de atualidade, continua a ser decisivo se uma consulta pode aguardar dados replicados após uma gravação ou se tem de utilizar deliberadamente o servidor primário.

Planear reuniões, inventário e transição

Uma sessão de base de dados inclui mais do que uma única consulta. SET, USE, CHANGE USER e as operações de Prepared Statement alteram o seu contexto. O readwritesplit replica os comandos de sessão relevantes para possíveis servidores de destino, para que as instruções encaminhadas posteriormente possam ser executadas com o estado de sessão adequado. Isto distingue o router do simples balanceamento de carga TCP, mas não elimina todas as limitações relacionadas com casos especiais.

No caso das instruções preparadas para tabelas temporárias, este limite é particularmente importante. Se uma instrução deste tipo for preparada no servidor primário, as réplicas não a conseguirão necessariamente executar. Por isso, a aplicação deve testar os objetos temporários, as instruções preparadas e os fluxos de transações utilizando o modelo de encaminhamento previsto. Estado da sessão não é uma condição secundária, mas determina se uma distribuição SQL é adequada do ponto de vista funcional e técnico.

No caso de uma aplicação com elevado volume de leitura, a equipa pode definir um valor-limite de atraso, estabelecido tecnicamente, como critério de exclusão para as réplicas. Apenas max_replication_lag No entanto, não garante que uma gravação anterior numa réplica já esteja visível. Para leituras subsequentes críticas, dependendo do fluxo de trabalho, podem ser consideradas uma rota primária deliberada, um contexto de gravação partilhado ou leituras causais ativadas.

No caso das leituras causais, o âmbito de aplicação deve ser escolhido de forma deliberada. local preserva a causalidade no seio de uma relação. global utiliza um valor de GTID armazenado a nível do serviço, mas só garante a ordem global «happens-before» das leituras se todas as transações se encontrarem num único domínio GTID. universal tem em conta o estado das transações do cluster observável no Primary. Os modos não rápidos sincronizam-se com os GTIDs; se uma réplica não se atualizar dentro do tempo limite configurado, a consulta é, por princípio, repetida no Primary, desde que o modo de transação o permita.

A função deve ser classificada em função da versão. A partir do MaxScale 24.02, o MaxScale adiciona last_gtid para novas ligações ao backend; nas versões anteriores era necessário session_track_system_variables devem estar configurados em conformidade nos backends do MariaDB. Os modos rápidos evitam o tempo de espera, mas, no caso de réplicas que ainda não tenham sido sincronizadas, podem redirecionar as leituras para o primário, pelo que não são adequados de forma geral para cargas com grande volume de gravações.

Uma transição planeada e uma transição automática em caso de falha também devem ser tratadas separadamente. Na transição planeada, a troca de funções é preparada de forma controlada; na transição automática em caso de falha, o sistema reage a uma situação de falha. O mariadbmon pode monitorizar funções e estados do backend e, desde que configurado de forma adequada, pode apoiar estes processos. O estado replicado dos dados, uma topologia clara, o sistema de alertas e um processo de gestão de incidentes continuam a ser requisitos essenciais.

No MaxScale 25.10, é possível discover-replicas Identificar servidores que replicam diretamente no primário atual e adicioná-los ao Monitor e ao MaxScale. Esta função não é compatível com a sincronização de configuração. Por isso, antes de a utilizar, a equipa deve definir se as alterações na topologia devem ser detetadas automaticamente ou controladas através de uma configuração sincronizada; não é permitido fazer ambas as coisas em simultâneo neste contexto.

TLS, proteger direitos e filtros

No MaxScale, o TLS deve ser configurado em duas ligações distintas: da aplicação para o listener e do proxy para os backends do MariaDB. Ambas as ligações requerem definições próprias para a encriptação e a verificação de certificados; uma ligação segura do cliente não encripta automaticamente o tráfego a jusante. A configuração deve, por isso, refletir as necessidades de proteção e a cadeia de confiança para ambas as secções.

TLS ativado ssl=true a encriptação na respetiva configuração do listener ou do servidor. Se um cliente exigir um certificado de servidor, o listener necessita do certificado e da chave privada. Uma conta com REQUIRE SSL não pode iniciar sessão através de um listener sem TLS. Os ficheiros de certificados e as chaves devem ser mantidos num ambiente operacional protegido, e não em configurações de exemplo ou de repositório que possam ser lidas livremente.

Também o Conceito de direitos No que diz respeito aos backends, o seguinte continua a ser determinante: o MaxScale mediu as ligações, mas não substitui contas de base de dados específicas. As contas de serviço recebem apenas as autorizações necessárias para o desempenho das suas funções. Para o início de sessão e a autorização, o MaxScale baseia-se nas contas de utilizador e nos direitos das tabelas de sistema do MariaDB; por conseguinte, as alterações a estas contas têm de estar disponíveis atempadamente na gestão interna de utilizadores.

O filtro do firewall pode verificar o código SQL antes do reencaminhamento, com base em regras aprendidas ou definidas. Dispõe dos modos de inatividade, aprendizagem, monitorização e imposição; no modo de imposição, os padrões de instruções não permitidos são respondidos com um erro ou a ligação é interrompida, consoante a configuração. A fase de aprendizagem deve abranger fluxos de trabalho representativos e permitidos, para que o filtro não bloqueie consultas regulares.

O filtro constitui uma camada de controlo adicional para padrões SQL esperados, não sendo uma autorização substituta. Continuam a ser necessárias autorizações restritivas de acesso à base de dados, credenciais de acesso protegidas e código de aplicação verificado, uma vez que o filtro apenas avalia as consultas que lhe chegam com base nas suas regras. As afirmações relativas a outros filtros devem ser analisadas separadamente, com base na respetiva documentação.

Verificar sistematicamente a configuração e os erros

Em caso de erros de ligação ou de encaminhamento, é mais útil seguir uma sequência de verificação fixa do que fazer alterações por intuição. Verifique primeiro o estado do monitor: todos os backends estão acessíveis e as funções de primário e réplica são reconhecidas conforme o esperado? Só então é possível avaliar de forma sensata as decisões do router. Um nó detetado incorretamente ou inacessível não é um problema exclusivamente do listener.

Em seguida, vêm o listener e o TLS: a porta, o protocolo, o certificado, a chave e os requisitos das contas utilizadas têm de corresponder. Verifique, em seguida, se a gestão de contas de utilizador reconhece as contas e os direitos atuais do backend. Especialmente após alterações nos utilizadores ou nas autorizações, dados de conta desatualizados podem impedir o início de sessão, mesmo que a conta esteja corretamente configurada no próprio MariaDB.

Em seguida, atribui o serviço, o router e os servidores previstos. No caso da divisão de leitura/gravação, é necessário ter também em conta o atraso da réplica, causal_reads e os limites de transação da aplicação à lista de verificação. Sem as «Causal Reads» ativadas, uma leitura efetuada fora do contexto de gravação necessário numa réplica pode fornecer um estado mais antigo; um limite de atraso, por si só, não garante a visibilidade de uma gravação anterior.

Além disso, coloca uma única Fonte de configuração fixa. O MaxScale pode persistir alterações em tempo de execução; ao reiniciar, a configuração persistida pode substituir os ficheiros estáticos. Se uma equipa editar parcialmente os ficheiros e, em parte, maxctrl Se for utilizada, o percurso de alteração, a revisão e o arquivo de segurança desta configuração de tempo de execução devem ser documentados de forma obrigatória.

Deves tratar as janelas de manutenção para alterações de esquema como um campo operacional específico: as dependências, o comportamento de bloqueio e a replicação devem ser verificados antecipadamente e não devem ser atribuídos ao proxy. Para o planeamento de alterações controladas em tabelas MariaDB de grande dimensão, o artigo sobre Alterações de esquema sem tempo de inatividade contexto complementar. O MaxScale pode, a partir daí, voltar a controlar as ligações e o encaminhamento com base nas funções do backend, mas não executa nenhuma estratégia DDL da base de dados.

Aviso: as alterações a funções, certificados, direitos de utilizador e encaminhamento devem ser primeiro testadas num ambiente semelhante. Para a intervenção no ambiente de produção, é necessário definir um procedimento de reversão, monitorizar os erros da aplicação e estabelecer responsabilidades claras. Desta forma, é possível distinguir se uma falha tem origem na configuração do proxy, no backend ou no comportamento do cliente.

Utilizar o MaxScale de forma adequada ou prescindir dele

No caso de um único servidor MariaDB sem requisitos de encaminhamento, comutação ou filtragem SQL, as ligações diretas são, na maioria das vezes, a forma mais simples de funcionamento. No entanto, a aplicação terá então de gerir por si própria qualquer mudança de destino posterior. O MaxScale justifica-se quando o ponto de extremidade adicional cumpre uma tarefa específica, como, por exemplo, interceptar mudanças de função, filtrar acessos ou distribuir leituras de forma controlada pelas réplicas.

Se a aplicação puder escolher deliberadamente os percursos de leitura e escrita, os pontos finais separados com readconnroute muitas vezes compreensível. Este router seleciona um backend ao estabelecer a ligação, mas não analisa todas as instruções SQL e não transfere uma sessão interrompida para outro servidor. No caso de router_options=slave Dá-se preferência às réplicas; se todas as réplicas estiverem inoperacionais e o primário ainda estiver disponível, o router pode utilizar o primário. Além disso, esta opção não torna o ponto final de leitura apenas. Para tal, são necessários um filtro «ReadOnly» adequado, direitos restritivos no backend ou SQL da aplicação rigorosamente controlado.

Para cargas de trabalho de réplica primária cujo ORM e modelo de transação sejam compatíveis, utiliza-se readwritesplit A aplicação determina a seleção do destino SQL para cada instrução. Na configuração padrão causal_reads=none No entanto, o atraso na replicação continua a ser visível. Após gravações críticas, a aplicação pode utilizar um caminho de leitura primário ou um contexto de transação partilhado adequado; em alternativa, é possível configurar leituras causais de forma específica para o âmbito de visibilidade necessário.

As «Causal Reads» distinguem entre a visibilidade no âmbito da mesma sessão, um valor GTID global gerido pelo serviço e o estado do cluster observável no servidor primário. local aplica-se à mesma ligação. No caso de global A ordem global «happens-before» das leituras só é garantida se todas as transações pertencerem a um único domínio GTID; por conseguinte, este modo não deve ser interpretado de forma generalizada como uma garantia de consistência ilimitada a nível do serviço. universal Verifica o estado observável no servidor primário antes das operações de leitura. Os modos de sincronização podem gerar tempo de espera adicional; as variantes rápidas não esperam, mas podem transferir uma carga maior para o servidor primário nas operações de escrita.

Os casos-limite devem ser submetidos a testes específicos com o driver e o modelo de dados reais antes da implementação. As tabelas temporárias e as instruções preparadas para as mesmas podem não estar disponíveis nas réplicas se a preparação for efetuada no primário. Além disso, as procedimentos armazenados, as chamadas a UDF, as instruções múltiplas e o estado da sessão influenciam se o router encaminha de forma conservadora para o primário.

O Transaction Replay não garante que as transações sejam isentas de perdas. Se uma ligação for interrompida durante COMMIT pode deixar-se em aberto se o commit já foi efetuado com sucesso. Configurações de repetição arriscadas podem executar operações de escrita duas vezes; resultados dependentes do servidor, como NOW() ou @@server_id podem, além disso, provocar desvios na soma de verificação. Por isso, avalia a sua utilização com base na necessidade de consistência, nos padrões de erros e na repetibilidade das gravações, e não com base em promessas genéricas de desempenho.