Registos de reversão do MariaDB: Noções básicas para administradores

MariaDB Undo controla a forma como o InnoDB armazena versões antigas das linhas, executa reversões com segurança e fornece visões de leitura consistentes enquanto as operações de gravação estão a decorrer. Vou mostrar como os registos de reversão (Undo Logs) interagem com a Lista de Histórico (History List) e a Purga (Purge), por que razão as transações longas ocupam memória e como controlo o crescimento do Desfazer- áreas que controlo.

Pontos centrais

• MVCC e leituras consistentes: a função «Undo» guarda versões anteriores, sem bloquear os leitores.
• Lista de histórico: Os commits acrescentam registos ao histórico, enquanto o 'purge' elimina registos.
• Transações longas: Mantêm versões antigas, aumentam o consumo de memória e as latências.
• Configuração: Os tablespaces «Undo», os threads «Purge» e o «Truncate» controlam o crescimento.
• Monitorização: Verificar antecipadamente o comprimento do histórico, a idade das transações e os tamanhos das ações de anulação.

Como os registos de anulação permitem o MVCC

Começo pelo essencial: cada alteração grava a versão anterior da linha no Desfazer-Log, para que um instantâneo consistente continue a ser válido. Os leitores acedem à versão anterior adequada, enquanto os gravadores armazenam novos dados e atualizam os índices; assim, mantém-se Paralelismo alto. As linhas encadeiam-se às suas antecessoras até que o Purge as possa eliminar. Sem esta cadeia, faltariam reversões e as perspetivas de leitura ficariam comprometidas. É precisamente aqui que o Undo estabelece a ponte entre a segurança das transações, o isolamento e os acessos de leitura fiáveis.

Estrutura interna dos registos de anulação

No fundo, distingo principalmente dois tipos de jogadas «Undo»: Inserir-Desfazer e Anular atualização. A função «Insert-Undo» permite anular inserções que ainda não tenham sido confirmadas. O «Update-Undo» mantém versões mais antigas em caso de alterações ou marcações de eliminação, para que os instantâneos continuem a funcionar. O InnoDB marca inicialmente as linhas eliminadas apenas como removidas (marca de eliminação) e adia a eliminação efetiva até que nenhum instantâneo as possa ver. Esta separação é crucial: as reversões (rollbacks) necessitam de estados anteriores precisos, enquanto os leitores consistentes têm de encontrar uma versão que corresponda logicamente ao seu momento de início. Por isso, as linhas referenciam internamente a versão anterior e os índices contêm informações adicionais, para que a função «Purge» possa, posteriormente, eliminar as entradas do índice de forma limpa.

Lista de histórico, limpar e memória

Após cada commit, as alterações históricas são guardadas no ficheiro global História Lista que o thread de purga elimina de forma assíncrona. Se a purga não conseguir acompanhar o ritmo, esta lista cresce e mantém artificialmente ativas versões antigas das linhas. Isso provoca mais percursos de leitura, mais E/S e espaços de tabela de reversão maiores. Nestas situações, verifico sempre os níveis de isolamento e os instantâneos abertos, pois uma configuração desfavorável Escolha do isolamento aumenta a vida útil das versões antigas. Quem tiver em conta a velocidade de purga, a extensão do histórico e as transações ativas consegue identificar precocemente os pontos de estrangulamento e travar a deriva de memória antes que se torne crítica.

Mecânica de purga e opções de afinação

O Purge está a funcionar melhor esforço possível: Recolhe entradas que podem ser limpas da Lista de Histórico, remove definitivamente as marcas de eliminação, atualiza os índices secundários e liberta as áreas de anulação. Em sistemas com elevada taxa de alterações, dimensiono a Paralelismo (por exemplo, através de vários Purge-Workers) e ajusta a estratégia de processamento em lotes, para que o Purge funcione de forma contínua, mas não agressiva. Regras gerais:

• Lotes curtos e constantes em vez de execuções esporádicas em grande escala – isso uniformiza as operações de E/S e os pontos de verificação.
• Não se deve opor a «Purge» ao armazenamento ou à limpeza de registos: ambas as abordagens têm de estar a par.
• Resolver primeiro os «snapshots» longos antes de aumentar ainda mais o tamanho dos lotes – caso contrário, o efeito perde-se.

Importante: o Purge não substitui uma boa disciplina nas transações. Mesmo com um elevado nível de paralelismo, o Undo permanece bloqueado enquanto existirem instantâneos antigos. Por isso, acompanho em simultâneo o progresso do Purge e a idade das transações e ajusto a carga de trabalho se o Purge estiver permanentemente atrasado.

Configuração dos espaços de tabela de anulação

As informações de anulação podem, dependendo da configuração, ser armazenadas no espaço de tabelas do sistema ou em Desfazer-Tablespaces. Costumo isolar o Undo para controlar melhor o crescimento e as E/S. Muitas instalações permitem o crescimento dinâmico, por vezes incluindo a libertação de espaço através do comando «Truncate». Isto parece prático, mas aumenta a necessidade de monitorização, porque os instantâneos de longa duração impedem uma redução rápida. Escolho a localização, o tamanho e a paralelidade da purga de forma a que as taxas de alteração e os intervalos de tempo no dia-a-dia sejam devidamente geridos e Restauração não sofra.

Definição	Efeito	Nota
innodb_undo_directory	Local de armazenamento para Desfazer-ficheiros	Os suportes de dados separados isolam as operações de E/S
innodb_purge_threads	Mais Purga-Trabalhador da mineração	Aumentar em caso de elevada taxa de alteração
innodb_undo_log_truncate	Recupera espaço não utilizado	Só é eficaz se o History estiver livre
innodb_max_undo_log_size	Limite de crescimento	Disponibilidade consoante a versão

Estrutura da memória e aspetos do sistema de ficheiros

Prefiro colocar os espaços de tabela de Undo separados em SSDs rápidos, separados das E/S de dados e de registos. Se o sistema de ficheiros suportar TRIM/Discard, um comando «Truncate» pode devolver fisicamente a memória ao sistema operativo. No entanto, planeio com limites máximos conservadores, porque a libertação de espaço não é garantida enquanto os instantâneos estiverem ligados ao Undo. A compressão no sistema de ficheiros só vale a pena se houver margem de manobra da CPU e se os padrões de gravação não causarem fragmentação. Continua a ser importante monitorizar os picos de latência: se o «Undo» crescer num disco sobrecarregado, a amplificação de gravação e a pressão dos pontos de verificação agravam-se progressivamente.

Monitorização e diagnóstico

Verifico regularmente o tamanho do Desfazer- Espaços de tabela, o comprimento da lista de histórico e a idade das transações em aberto. Os comandos SHOW ENGINE InnoDB STATUS, o Performance Schema e o Information Schema fornecem sinais claros. Se as áreas de undo estiverem a crescer, enquanto a purga tem pouco efeito, começo por encerrar as sessões antigas. Além disso, analiso os bloqueios, pois os desnecessários Bloqueios de remo prolongam as transações e os instantâneos. Quem analisa diariamente estes indicadores evita picos repentinos de E/S e reduz os percursos no Memória.

Consequências no desempenho de transações demoradas

Transações longas de leitura ou escrita demoram Versões permanentes, mesmo que estejam logicamente desatualizadas. Isso aumenta o volume do Undo, alarga as varreduras e intensifica a pressão sobre a cache. Reduzo esses efeitos com lotes mais curtos, o uso consistente do COMMIT e tempos limite para as sessões. Os relatórios que demoram horas a ser lidos funcionam melhor em janelas mais pequenas ou contra réplicas. Quem desativa o autocommit, otimiza os planos de consulta e encerra transações inativas, liberta o Purge e alivia a carga sobre a Instância.

Segmentos de rollback e paralelismo

As entradas de «Undo» encontram-se em Segmentos de rollback, que, por assim dizer, disponibilizam «slots» para alterações ativas em simultâneo. Muitos «writers» simultâneos beneficiam de segmentos de rollback suficientes, uma vez que as inserções e atualizações têm, assim, de partilhar as suas cadeias de anulação com menos frequência. Observo padrões de espera nos recursos de rollback e aumento o seu número sempre que a versão e a distribuição o permitirem. Os sintomas de falta de paralelismo são tempos de espera inesperados em fases de atualização que, de resto, seriam curtas, ou latências de gravação muito variáveis sob carga. Um maior número de segmentos distribui a pressão, mas não anula a regra básica: instantâneos longos superam qualquer otimização.

Níveis de isolamento em pormenor

O Nível de isolamento determina durante quanto tempo as versões de reversão (Undo) são relevantes. No modo REPEATABLE READ, uma transação mantém o seu instantâneo inicial durante toda a sua duração; assim, a reversão (Undo) permanece potencialmente associada durante muito tempo. No modo READ COMMITTED, são criadas janelas de visualização por instrução; isto reduz significativamente a duração das versões antigas em muitas cargas de trabalho. SELECT … FOR UPDATE e LOCK IN SHARE MODE aplicam bloqueios e alteram o perfil de concorrência — úteis contra «Lost Updates», mas críticos para o Undo se os leitores permanecerem abertos durante demasiado tempo. Por isso, utilizo o READ COMMITTED de forma seletiva nos casos em que os relatórios ou as leituras de API necessitam de visões consistentes, mas não ao nível da transação, e opto pelo REPEATABLE READ quando a lógica de negócio assim o exige.

Cenários de recuperação e arranque

Ao iniciar, o InnoDB utiliza o Desfazer-Informações para reverter transações incompletas de forma correta. Isto garante visões consistentes antes de novos clientes começarem a trabalhar. Em casos especiais, existem modos de arranque que encurtam as verificações, mas só os utilizo em caso de emergência. A aceleração pura, sem diagnóstico, acaba por se revelar contraproducente, porque a integridade tem prioridade. Quem mantém o tempo de recuperação e os tamanhos de reversão sob controlo toma melhores decisões sobre janelas de manutenção e Risco.

Regras práticas para a administração

Procuro manter as transações curtas, faço commits com frequência e evito sessões de leitura intermináveis, para que Purga tem via livre. Divido as alterações em massa de maior dimensão em lotes bem dosados, para que a Lista de Histórico não aumente. Dimensiono os threads de purga de acordo com a taxa de alteração e adapto o layout de Undo ao hardware de memória. Além disso, documento os processos de negócio que requerem instantâneos demorados e planeio deliberadamente as janelas de tempo. Desta forma, a utilização do Undo permanece previsível e a Latência baixo.

Padrões de carga de trabalho e otimização

O comércio eletrónico, os sistemas de relatórios e os sistemas de conteúdos geram muitas alterações e exigem uma abordagem disciplinada Transacções. Defino tempos limite conservadores para os leitores, otimizo índices para atualizações precisas e limito o tamanho dos lotes. Em caso de elevada carga de gravação, aumento a paralelização da purga e regulo a pressão dos pontos de verificação. Além disso, verifico a taxa de gravação em relação a Registos de transações e recuperação, para que a recuperação após falhas continue a ser previsível. Esta interação permite planear o volume de operações de anulação e protege a Consistência.

Cópias de segurança e replicação

As cópias de segurança lógicas com instantâneos consistentes prolongam inevitavelmente a vida útil das versões antigas – a lista de «Undo» cresce até que a cópia de segurança esteja concluída. Planeio essas execuções fora dos períodos de pico, limito o número de escritores simultâneos e disponibilizo capacidade de purga suficiente. Os backups físicos podem reduzir a carga de «Undo», mas não dispensam o cuidado necessário com os instantâneos. Nas réplicas, prefiro manter os relatórios em modo READ COMMITTED e encerro transações de inatividade prolongadas, para que o SQL-Apply não fique para trás. Se uma réplica ficar atrasada, a carga de Undo também aumenta nessa réplica, pois a sincronização de muitas eliminações/atualizações produz uma onda de histórico que a purga tem de processar primeiro.

Runbook: Travar rapidamente o crescimento do Undo

• Identificar utilizadores ativos de longa duração: verificar a duração das transações em aberto e as sessões com conjuntos de resultados de grande dimensão.
• Encerrar de forma sistemática os processos inativos na transação: verificar o autocommit e fechar os cursores esquecidos.
• Aumentar a capacidade de purga: ativar workers adicionais e aumentar moderadamente o tamanho dos lotes.
• Suavizar picos no Writer: limitar os tamanhos dos lotes, introduzir micro-commits.
• Aproveitar as janelas de manutenção: transferir grandes ondas de eliminação/atualização para intervalos programáveis.
• Após a estabilização: permitir o comando «Undo-Truncate» até que o tamanho do sistema de ficheiros volte a corresponder às necessidades.

Planeamento de capacidade para o Undo

Calculo o Undo de forma conservadora com base na taxa de alteração, no tamanho médio das linhas e na janela máxima do snapshot. Uma aproximação simples: eventos de alteração por segundo × carga útil média × janela de visibilidade planeada em segundos. Tem de se ter em conta uma margem de segurança para índices e metadados. Esta fórmula empírica dá uma ideia das necessidades no pior dos casos e protege contra surpresas quando se realizam relatórios, cópias de segurança ou processos de migração ao mesmo tempo Incorporar instantâneos. Em sistemas em crescimento, verifico trimestralmente se as alterações na carga de trabalho (novas funcionalidades, mais clientes móveis, picos mais intensos) alteram as necessidades.

Casos especiais: tabelas temporárias e DDL

As tabelas InnoDB temporárias utilizam áreas próprias; as alterações nessas tabelas têm um impacto menor no Undo normal, mas podem, ainda assim, gerar um volume elevado de E/S em casos de ordenações ou junções de grande dimensão. As operações DDL, como ALTER TABLE, geram frequentemente ondas de alterações massivas – caso seja necessário, divido-as em etapas incrementais e agendo-as em fases de menor atividade. Também neste caso se aplica o seguinte: transações curtas e bem organizadas são preferíveis a atalhos arriscados. Se uma execução de DDL for interrompida, o Undo ajuda a regressar a um estado consistente; para tal, porém, é necessária memória e tempo suficientes, que eu prevejo antecipadamente.

Exemplo: medir os impactos

Começo por obter um instantâneo de referência do tamanho da função «Undo», que História- o comprimento e a duração média das transações. Em seguida, implemento alterações específicas, como aumentar o número de threads de purga ou reduzir o tamanho dos lotes. Em seguida, comparo os indicadores até que o crescimento das operações de anulação e as latências atinjam um equilíbrio saudável. Se encontrar valores atípicos, analiso os planos de consulta e as listas de sessões para identificar leitores bloqueados. Este processo cíclico proporciona resultados rápidos, sem comprometer a Disponibilidade pôr em risco.

Equívocos comuns

Um commit não apaga as versões antigas de imediato; Purga só se decide mais tarde. As opções «Truncate» não resolvem um problema de conceção fundamental quando as transações duram demasiado tempo. Ficheiros «Undo» de grande dimensão não significam necessariamente corrupção; muitas vezes, basta uma única sessão para causar o bloqueio. Embora os leitores raramente bloqueiem os gravadores, as consultas inadequadas prolongam indiretamente os instantâneos. Quem eliminar estes erros toma melhores decisões e reduz Tempos de inatividade.

Resumo para quem está com pressa

Manter registos de anulação Passado tangível, para que o InnoDB reverta as transações com segurança e os leitores vejam vistas consistentes. Controlo o crescimento otimizando as transações, configurando corretamente os threads de purga e posicionando os espaços de tabela de reversão de forma adequada. A monitorização do comprimento do histórico, dos tamanhos de «undo» e da idade das transações revela tendências numa fase precoce. Em caso de anomalias, verifico a carga de trabalho, os bloqueios e as sessões, em vez de me concentrar nos sintomas. Quem mantém esta rotina garante o desempenho, a consistência e reinício sempre sob controlo.