MariaDB 12.0: funcionalidades, riscos da atualização e estratégia de alojamento

Classificar corretamente o MariaDB 12.0

A designação „MariaDB 12“ não descreve uma versão do produto uniforme e com manutenção contínua. Para informações técnicas concretas, consulte a série «Rolling» MariaDB 12.0 refere-se a isso. Dentro desta série, as versões apresentam diferentes graus de maturação: a versão 12.0.0 foi lançada a 26 de março de 2025 como pré-visualização, a versão 12.0.1 foi lançada a 5 de junho de 2025 como Release Candidate e a versão 12.0.2 a 7 de agosto de 2025 como versão estável GA.

A versão «Preview» e a «Release Candidate» destinam-se a testes e não devem ser equiparadas a uma plataforma estável. O facto de a versão 12.0.2 estar documentada como «Stable» ou «GA», por outro lado, descreve o estado de maturidade precisamente desta versão. Daí não decorre que todas as instalações devam ser atualizadas imediatamente, nem que as versões posteriores possuam automaticamente as mesmas características, pacotes ou limites operacionais.

Também as ramificações posteriores, como a 12.1, a 12.2 ou a 12.3, devem ser consideradas separadamente. As funcionalidades, as correções de erros ou os valores padrão alterados dessas séries não constituem prova de MariaDB 12.0. O mesmo se aplica aos ramos de desenvolvimento: um anúncio ou documentação nesses ramos não substitui qualquer informação relativa à versão publicada de um servidor da comunidade.

Por isso, antes de uma implementação, a plataforma necessita de uma nova verificação do estado real dos pacotes previstos. É necessário verificar, em particular, a série de servidores disponível, a compatibilidade entre os pacotes de cliente e os pacotes adicionais, o suporte da versão do sistema operativo utilizada, bem como a classificação atual da versão. O conteúdo do repositório e os pacotes de distribuição podem diferir da designação geral do produto.

Distinguir entre «Rolling Release» e LTS

No caso das plataformas de alojamento, não é apenas o número da versão que é relevante, mas sim o Modelo de lançamento. O MariaDB distingue as versões de inovação das versões LTS. As versões de inovação introduzem novas funcionalidades em intervalos curtos e, após a sua fase de lançamento geral (GA), seguem normalmente o caminho para a próxima série contínua. Por outro lado, segundo o fabricante, as versões LTS são mantidas durante três anos a partir do lançamento geral (GA).

Uma versão GA estável responde, assim, apenas à questão de saber se essa versão específica foi lançada como estável. Não responde de forma genérica por quanto tempo estarão disponíveis correções de segurança, se um distribuidor continuará a fornecer pacotes ou se uma base de clientes existente poderá permanecer na série sem necessidade de migração. Estes aspetos dependem do contrato, da distribuição e do resumo atual das versões.

Uma série de inovações pode ser adequada quando uma plataforma pretende implementar antecipadamente uma funcionalidade claramente necessária e consegue testar isoladamente as aplicações, os conectores e os processos operacionais em causa. Para tal, as equipas devem planear avançar atempadamente na trajetória de atualização prevista. Especialmente no caso de ofertas multicliente, isto aumenta o esforço necessário para aprovações, comunicação e procedimentos de contingência.

A Nível-alvo do LTS adequa-se mais a plataformas padronizadas com muitas aplicações clássicas, quando as janelas de manutenção programáveis e uma versão de software estável a longo prazo são mais importantes do que novas funcionalidades isoladas. Isto não é uma regra contra os lançamentos de inovação: o que é decisivo é se os benefícios de uma funcionalidade justificam os testes adicionais e a mudança previsível para a série seguinte.

A escolha deve, por isso, ter em conta, no mínimo, as necessidades funcionais, o estado atual dos pacotes e do suporte, a compatibilidade testada com as aplicações, a capacidade de recuperação e os custos operacionais em termos de pessoal. Para uma nova instalação, não basta considerar o „MariaDB 12“ como a versão mais recente. A plataforma opta conscientemente entre a utilização de funcionalidades a curto prazo e um estado de base de dados padronizado a longo prazo.

Avaliar novas funcionalidades tendo em conta as suas limitações

MariaDB 12.0 complementa Sugestões do otimizador para influenciar de forma mais específica os planos de execução, por exemplo, no que diz respeito à ordem das junções, à otimização de intervalos ou a determinados algoritmos de junção. As extensões dizem ainda respeito a componentes de índice ordenados por ordem decrescente no «Loose Index Scan» e no «Index Condition Pushdown». No contexto da hospedagem, trata-se sobretudo de uma ferramenta de diagnóstico para consultas individuais problemáticas, não sendo um substituto para índices adequados, condições de junção corretas e estatísticas de tabelas atualizadas.

Uma sugestão pode limitar um plano indesejado, mas pode vir a ter efeitos negativos devido ao crescimento dos dados ou a alterações nas estatísticas. Por isso, deve ser integrada numa análise reprodutível da aplicação em questão e não ser aplicada como uma regra global nos servidor de base de dados. No caso das bases de dados típicas de CMS e lojas online, a mera existência dessas sugestões não constitui, por si só, um motivo convincente para atualizar o MariaDB.

Durante a auditoria, o plugin de auditoria na versão 12.0 regista adicionalmente o anfitrião e a porta das ligações recebidas, bem como a versão TLS utilizada. No caso de acessos através de proxies, NAT ou balanceadores de carga, isto pode melhorar a identificação forense. No entanto, a vantagem só se concretiza através de uma recolha centralizada e protegida de registos e de regras de retenção definidas; os dados de registo adicionais têm de se enquadrar no planeamento de capacidade e de proteção de dados.

No que diz respeito à encriptação, com suporte a SHA-2 em file_key_management.so e ssl_passphrase Módulos disponíveis. Os ambientes de replicação passam a dispor de opções para tabelas temporárias, bem como de uma variável para o tratamento de eventos com o ID do próprio servidor. Além disso, a versão 12.0 traz, entre outras coisas, SYS_REFCURSOR, um limite de cursor por sessão e funções SIG, tais como validação, simplificação e conversão para Geohash. Estas ferramentas são úteis apenas em aplicações e topologias adequadas.

O MariaDB Server, o MaxScale e o Galera continuam a ser componentes separados: o MaxScale tem as suas próprias versões e configurações, e as alterações relacionadas com o Galera dizem respeito exclusivamente aos clusters. Da mesma forma, a compatibilidade com o MySQL não implica que os componentes sejam intercambiáveis sem verificação prévia. O MariaDB utiliza o seu próprio modelo GTID e, por exemplo, não suporta o MySQL SET PERSIST. As novas funcionalidades GIS podem ser úteis para aplicações de geodados baseadas no MySQL 8, mas, na maioria dos casos, não constituem motivo para uma atualização no que diz respeito às bases de dados web comuns.

Comparar o estado de lançamento e as funcionalidades

Para o funcionamento da plataforma, o estado específico dentro da série é determinante. O MariaDB 12.0.0 era uma pré-visualização, o 12.0.1 um candidato a lançamento e só o 12.0.2 está documentado como estável ou GA. Estes estados indicam diferentes graus de maturidade; não constituem uma indicação sobre se a série é adequada para uma determinada implementação de alojamento, um sistema operativo ou um contrato de suporte.

As novas funcionalidades são úteis sobretudo quando resolvem um problema operacional concreto. Sugestões do otimizador podem, por exemplo, limitar um plano de execução indesejado para uma única consulta complexa. Não substituem índices adequados, condições de junção corretas nem estatísticas atualizadas, e não devem ser utilizadas como regra geral para as aplicações dos clientes.

Os campos de auditoria adicionais podem registar o host, a porta e a versão TLS utilizada numa ligação recebida. A opção de chave ssl_passphrase por outro lado, as funcionalidades avançadas do SIG ou do cursor não justificam, por si só, uma atualização generalizada da versão. A sua utilidade só se faz sentir em aplicações cuja arquitetura, modelo de dados e requisitos de segurança necessitem efetivamente dessas capacidades.

Preparar de forma controlada a atualização do MariaDB

Uma atualização do MariaDB num alojamento gerido ou partilhado começa com um inventário: é necessário identificar as instâncias, bases de dados, conectores, plugins, ficheiros de configuração, percursos de replicação e aplicações afetadas. Segue-se, em seguida, um ambiente de teste que reproduz os dados de produção e a configuração apenas dentro dos parâmetros de segurança permitidos. Desta forma, é possível detetar problemas de arranque e anomalias SQL antes que vários clientes sejam afetados.

Antes de cada implementação limitada, é necessário efetuar uma cópia de segurança completa e definir um procedimento de recuperação documentado. O essencial não é apenas a existência de ficheiros de cópia de segurança: os responsáveis devem verificar se é possível restaurar a partir deles um conjunto de dados consistente e utilizável pelas aplicações. Em seguida, devem verificar os inícios de sessão, as operações de gravação, as tarefas em segundo plano e os percursos típicos dos clientes como Regressão de aplicações. O procedimento concreto depende do método de segurança utilizado e da arquitetura da plataforma.

Um plano de recuperação define quem decide quais os estados de dados que são determinantes e como as aplicações voltam ao estado consistente anterior em caso de interrupção. Trata-se de uma prática operacional de gestão, não de uma característica de uma versão específica do MariaDB. A replicação, a monitorização e o failover devem, por isso, ser testados na respetiva topologia de staging, em vez de se deduzir o seu funcionamento a partir de uma atualização bem-sucedida de uma instância única.

O MariaDB 12.0 elimina as variáveis de sistema big_tables, large_page_size e storage_engine. Por conseguinte, as entradas existentes têm de ser my.cnf e todos os fragmentos de configuração envolvidos devem ser identificados e avaliados em relação ao estado de destino. A limpeza deve ser realizada antes da atualização do pacote; no caso de large_page_size É ainda necessário distinguir entre a variável MariaDB removida e uma configuração de HugePages do sistema operativo que seja independente desta.

O planeamento dos pacotes também merece uma etapa própria: um repositório pode conter várias versões do MariaDB, e os pacotes relacionados — de servidor, cliente, partilhados e comuns — devem ter a mesma versão. A versão do sistema operativo e as fontes dos pacotes fazem parte da aprovação. No que diz respeito às dependências ao nível do anfitrião, o artigo sobre novidades relevantes para servidores de alojamento com o kernel Linux 6.x contexto adicional; no entanto, não substitui a verificação de preparação específica da base de dados.

Configurar casos especiais de forma segura

No caso de consultas de relatório instáveis, o diagnóstico deve começar por analisar os planos de execução, os índices, as condições de junção e as estatísticas das tabelas. Só quando um plano indesejado for identificado de forma reproduzível é que uma dica do otimizador pode constituir uma restrição específica. A sugestão faz parte da consulta em questão e deve ser incluída numa análise documentada, uma vez que o crescimento dos dados ou a alteração das estatísticas podem, posteriormente, alterar o seu efeito.

As consultas de leitura são adequadas para uma análise do estado atual sem riscos. Executa-as com uma conta que possua apenas os direitos de acesso necessários para o efeito; estas consultas não alteram nem os dados, nem os direitos, nem a configuração do servidor. Os resultados identificam o servidor de base de dados efetivamente ligado e ajudam a verificar as suposições contidas na documentação de implementação.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

Numa arquitetura proxy, é SET SESSION AUTHORIZATION não é uma funcionalidade de conforto, mas sim uma intervenção no modelo de segurança. A mudança de sessão requer o privilégio SET USER e não está disponível no âmbito de transações, instruções preparadas ou procedimentos armazenados.

As versões compatíveis do MaxScale podem utilizar credenciais de serviço para a ligação ao backend e, em seguida, alternar para a identidade do cliente. Para tal, é necessário um servidor backend MariaDB 12 ou mais recente e o privilégio SET USER necessária para a conta de serviço. No entanto, esta funcionalidade não decorre automaticamente de um backend MariaDB 12.0 por si só: antes da implementação, é necessário verificar a combinação específica entre o servidor MariaDB, a versão do MaxScale e a configuração.

A configuração do MaxScale use_service_credentials Determina, nas versões adequadas, se o MaxScale deve, em primeiro lugar, iniciar sessão no backend com os dados de acesso armazenados no serviço e, posteriormente, mudar para a identidade do cliente. A conta de serviço não deve receber quaisquer direitos administrativos adicionais para além dos direitos tecnicamente necessários. A auditoria e um desligamento de emergência documentado devem estar em conformidade com o modelo de ligação e de agrupamento.

As topologias de replicação e Galera requerem um percurso de teste específico para failover, reintegração e recuperação. As opções relativas a tabelas temporárias ou ao tratamento de IDs de servidor iguais não devem ser alteradas sem uma compreensão do formato do binlog, do ID do servidor e do caminho de retorno. Além disso, uma otimização do Galera não constitui uma garantia geral de desempenho para os clusters, uma vez que o perfil de carga e a latência da rede continuam a ser fatores determinantes.

Quem estiver a avaliar tabelas internas, estruturas temporárias ou motores de armazenamento no ambiente deve considerar o papel do respetivo motor separadamente da migração de versões. O artigo sobre a Motor de armazenamento MariaDB Aria no serviço de alojamento classifica essas questões de implementação. No entanto, para a decisão de atualização, o fator decisivo continua a ser se a aplicação concreta e os seus processos operacionais funcionam de forma reproduzível na versão de destino.

Garantir a transição de sessão e a auditoria

SET SESSION AUTHORIZATION é um elemento fundamental para arquiteturas de ligação concebidas de forma consciente, não sendo apenas uma facilidade para a administração. O comando permite que uma conta autorizada atue, na sessão atual, sob a identidade de outro utilizador. O pré-requisito é o privilégio SET USER. Desta forma, a responsabilidade pelo registo e pela verificação da identidade passa, em parte, das ligações individuais dos clientes para um componente controlado da plataforma.

Este padrão pode fazer sentido para um proxy, mas o MariaDB Server e o MaxScale continuam a ser produtos distintos, com sistemas de versionamento próprios. Apenas as versões do MaxScale que suportam a utilização de credenciais de serviço com subsequente mudança de identidade podem disponibilizar este processo. Um backend MariaDB 12.0 não adiciona automaticamente esta capacidade a um ramo do MaxScale mais antigo ou configurado de forma diferente.

Numa combinação suportada, o proxy inicia sessão no servidor MariaDB com a conta de serviço e, em seguida, muda para a identidade de utilizador solicitada. A configuração use_service_credentials requer, para tal, um servidor backend MariaDB 12 ou mais recente, bem como SET USER para a conta de serviço. Por isso, antes da implementação, é necessário verificar em conjunto as versões específicas do MariaDB e do MaxScale a utilizar, a configuração e o método de autenticação previsto.

A conta de serviço deve ser criada devido à possibilidade de A mudança de identidade é crítica para a segurança. O privilégio SET USER não lhe confere automaticamente quaisquer direitos administrativos globais; além disso, só lhe podem ser atribuídas as autorizações tecnicamente necessárias. Ao mudar de sessão, é possível contornar, entre outras coisas, o bloqueio da conta, a expiração da palavra-passe, a autenticação e a verificação REQUIRE-SSL da conta de destino. Além disso, a mudança não está disponível no âmbito de transações, instruções preparadas ou procedimentos armazenados.

No caso de alojamento multicliente, isto significa que as contas dos clientes permanecem logicamente separadas e que o ciclo de transição permitido é documentado e limitado. Além disso, a plataforma necessita de um mecanismo de desligamento de emergência, por exemplo, através do bloqueio da conta de serviço ou da remoção do caminho de ligação afetado, de acordo com um procedimento de incidente definido. A medida adequada deve ser ponderada tendo em conta o agrupamento de ligações, as sessões em curso e o impacto noutros clientes.

No MariaDB 12.0, o plugin de auditoria adiciona, às ligações recebidas, o host, a porta e a versão TLS utilizada. Estas informações ajudam a identificar melhor os acessos provenientes de trás de NAT, balanceadores de carga ou proxies. No entanto, não substituem uma identificação fiável caso um sistema a montante altere as informações de origem ou apenas transmita o seu próprio endereço ao servidor da base de dados.

Entra em vigor Auditoria Começando por um processo operacional: os registos devem ser recolhidos de forma centralizada, protegidos contra alterações não autorizadas e geridos de acordo com um prazo de conservação definido. Os direitos de acesso para consulta e exportação devem ser separados, tal como a responsabilidade pelo alerta e pela investigação. Sem medições, não é possível deduzir a partir da versão se dados de registo adicionais influenciam significativamente a capacidade ou o desempenho de uma plataforma específica.

Em caso de incidente de segurança, os operadores devem poder identificar qual a identidade definida pelo proxy, através de que acesso a sessão foi estabelecida e quais os dados de auditoria disponíveis a esse respeito. As verificações regulares e documentadas do desligamento e da disponibilidade dos registos são mais importantes do que um registo tão abrangente quanto possível. Em particular, um registo de auditoria não deve substituir uma política de direitos, a encriptação de transporte ou a gestão segura de segredos.

Monitorizar o funcionamento após a atualização

Após uma atualização do MariaDB, inicia-se uma fase de observação, não uma otimização automática. Em primeiro lugar, é necessário distinguir se o Arranque do servidor falha, uma aplicação deixa de conseguir estabelecer ligação ou um caminho de replicação apresenta desvios. Estas situações de erro têm causas diferentes e requerem artefactos distintos, em vez de serem resolvidas com alterações genéricas na configuração.

Os erros de inicialização são identificados com base no registo de erros do servidor e num inventário versionado dos ficheiros de configuração efetivamente carregados. No MariaDB 12.0, por exemplo, big_tables e storage_engine eliminadas. Essas entradas não podem ser mantidas inalteradas em my.cnf ou em fragmentos de configuração incorporados; a referência às variáveis documentada e a mensagem inicial indicam qual é, concretamente, a configuração afetada.

No caso dos conectores e plug-ins, devem ser registados em conjunto os pacotes instalados, as versões dos módulos carregados e a mensagem de erro da aplicação. A escolha de um repositório, por si só, não garante uma instalação compatível: no caso de uma versão específica do servidor, os pacotes do servidor, do cliente, partilhados e comuns devem ser planeados com a mesma versão. Os nomes e versões disponíveis dependem do repositório e do sistema operativo utilizados.

A melhor forma de investigar erros de aplicação é através de um caso SQL reproduzível e, se possível, o mais simples possível, juntamente com os registos correspondentes do cliente ou do conector. É possível fazer um levantamento inicial com SELECT VERSION(); começar. O resultado identifica o servidor de base de dados que responde, mas não comprova nem a compatibilidade de um ORM nem o funcionamento correto de uma configuração da aplicação.

No que diz respeito à replicação, o estado de replicação documentado, o formato do binlog, os IDs dos servidores, bem como os eventos relacionados com o failover e a reintegração, devem constar do relatório de diagnóstico. As tabelas temporárias, a topologia e as alterações nas opções de replicação devem ser verificadas separadamente. Um teste de gravação local bem-sucedido não é suficiente para comprovar a consistência e o comportamento esperado em todas as instâncias envolvidas.

Os registos do servidor e de auditoria, o inventário de configurações, as consultas de versões e os testes de consulta reproduzíveis resultam, no seu conjunto, numa cadeia de erros compreensível. Facilita também a decisão sobre se é necessário ativar um plano de recuperação. Um número de versão mais elevado não implica necessariamente um determinado impacto no desempenho nem um ajuste universal; as alterações aos parâmetros de memória, do otimizador ou de replicação requerem uma hipótese concreta e um impacto verificável.

Decidir estrategicamente o resultado final

O nível de conformidade adequado depende da função da plataforma e do modelo operacional, e não da designação genérica «MariaDB 12». Para bases de dados clássicas de CMS, lojas online e aplicações web, a segurança na atualização, a separação clara entre clientes e um processo de recuperação robusto têm, na maioria das vezes, prioridade sobre novas funcionalidades SQL específicas. Novas funcionalidades ou rotinas GIS não constituem, por si só, um motivo para a migração, se as aplicações não as utilizarem.

As aplicações complexas de relatórios podem beneficiar das sugestões do Optimizer quando uma análise identifica claramente um plano de execução indesejado. Antes disso, é necessário verificar os índices, as condições de junção, a distribuição dos dados e as estatísticas. Uma sugestão constitui uma ligação específica a uma decisão de planeamento e pode tornar-se inadequada na sequência do crescimento dos dados ou de alterações nas estatísticas; por isso, deve constar da documentação da aplicação, juntamente com a consulta, a justificação e os critérios de revogação.

Os ambientes de proxy e de cluster requerem um percurso de teste específico. No caso de um proxy, este diz respeito, em particular, ao modelo de autorizações da conta de serviço, às mudanças de sessão e à auditabilidade. No caso da replicação ou do Galera, isso inclui o failover, a reintegração, a restauração e o comportamento das tabelas temporárias. Uma atualização bem-sucedida de uma única instância não garante que estes processos funcionem corretamente em toda a topologia.

O Estratégia de lançamento é necessário avaliar separadamente as versões de inovação e as LTS. A MariaDB descreve as versões de inovação como versões contínuas (rolling releases), que, após o lançamento geral (GA), normalmente não são mantidas de forma contínua com versões de correção; o caminho previsto conduz à próxima série contínua. As versões LTS, por outro lado, são mantidas durante três anos a partir do lançamento geral (GA). Daí não decorre qualquer compromisso geral quanto ao suporte de pacotes ou contratual para um ambiente de alojamento específico.

Antes de tomar uma decisão, é, por isso, necessário avaliar em conjunto o conjunto de pacotes e o suporte da distribuição, a compatibilidade comprovada das aplicações, um processo de restauração comprovado, o modelo de segurança e os custos operacionais correntes. Apesar de partilharem muitos padrões SQL comuns, o MariaDB e o MySQL não são intercambiáveis: o MariaDB utiliza um modelo GTID próprio e, por exemplo, não suporta o MySQL SET PERSIST. Por isso, as importações provenientes de um ambiente MySQL têm de ser verificadas.

Para a série 12.0, a versão 12.0.2 está documentada como versão estável (GA), enquanto a 12.0.0 era uma pré-visualização e a 12.0.1 uma versão candidata ao lançamento. Esta classificação descreve o estado de maturidade na altura, mas não substitui uma decisão de lançamento atual. Imediatamente antes da implementação ou publicação, os operadores devem verificar novamente a versão do pacote disponibilizada, o suporte ao sistema operativo e a classificação atual da versão, comparando-as com as informações do fabricante.

O que é, portanto, decisivo é o estado da plataforma concretamente testado, com as suas dependências e regras de funcionamento. Uma implementação controlada justifica-se quando a compatibilidade, o plano de reversão e as responsabilidades estiverem comprovadamente preparados. Na ausência destes pré-requisitos, o nome «MariaDB 12» não constitui um argumento para assumir riscos no alojamento partilhado ou num ambiente de bases de dados críticas para o negócio.