{"id":21119,"date":"2026-08-28T18:18:54","date_gmt":"2026-08-28T16:18:54","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-undo-logs-administrator-guide-technik\/"},"modified":"2026-08-28T18:18:54","modified_gmt":"2026-08-28T16:18:54","slug":"guia-do-administrador-dos-registos-de-anulacao-do-mariadb-aspectos-tecnicos","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-undo-logs-administrator-guide-technik\/","title":{"rendered":"Registos de revers\u00e3o do MariaDB: No\u00e7\u00f5es b\u00e1sicas para administradores"},"content":{"rendered":"<p><strong>MariaDB Undo<\/strong> controla a forma como o InnoDB armazena vers\u00f5es antigas das linhas, executa revers\u00f5es com seguran\u00e7a e fornece vis\u00f5es de leitura consistentes enquanto as opera\u00e7\u00f5es de grava\u00e7\u00e3o est\u00e3o a decorrer. Vou mostrar como os registos de revers\u00e3o (Undo Logs) interagem com a Lista de Hist\u00f3rico (History List) e a Purga (Purge), por que raz\u00e3o as transa\u00e7\u00f5es longas ocupam mem\u00f3ria e como controlo o crescimento do <strong>Desfazer<\/strong>- \u00e1reas que controlo.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>MVCC<\/strong> e leituras consistentes: a fun\u00e7\u00e3o \u00abUndo\u00bb guarda vers\u00f5es anteriores, sem bloquear os leitores.<\/li>\n  <li><strong>Lista de hist\u00f3rico<\/strong>: Os commits acrescentam registos ao hist\u00f3rico, enquanto o 'purge' elimina registos.<\/li>\n  <li><strong>Transa\u00e7\u00f5es longas<\/strong>: Mant\u00eam vers\u00f5es antigas, aumentam o consumo de mem\u00f3ria e as lat\u00eancias.<\/li>\n  <li><strong>Configura\u00e7\u00e3o<\/strong>: Os tablespaces \u00abUndo\u00bb, os threads \u00abPurge\u00bb e o \u00abTruncate\u00bb controlam o crescimento.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>: Verificar antecipadamente o comprimento do hist\u00f3rico, a idade das transa\u00e7\u00f5es e os tamanhos das a\u00e7\u00f5es de anula\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<h2>Como os registos de anula\u00e7\u00e3o permitem o MVCC<\/h2>\n\n<p>Come\u00e7o pelo essencial: cada altera\u00e7\u00e3o grava a vers\u00e3o anterior da linha no <strong>Desfazer<\/strong>-Log, para que um instant\u00e2neo consistente continue a ser v\u00e1lido. Os leitores acedem \u00e0 vers\u00e3o anterior adequada, enquanto os gravadores armazenam novos dados e atualizam os \u00edndices; assim, mant\u00e9m-se <strong>Paralelismo<\/strong> alto. As linhas encadeiam-se \u00e0s suas antecessoras at\u00e9 que o Purge as possa eliminar. Sem esta cadeia, faltariam revers\u00f5es e as perspetivas de leitura ficariam comprometidas. \u00c9 precisamente aqui que o Undo estabelece a ponte entre a seguran\u00e7a das transa\u00e7\u00f5es, o isolamento e os acessos de leitura fi\u00e1veis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-serverraum-admin-5847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Estrutura interna dos registos de anula\u00e7\u00e3o<\/h2>\n\n<p>No fundo, distingo principalmente dois tipos de jogadas \u00abUndo\u00bb: <em>Inserir-Desfazer<\/em> e <em>Anular atualiza\u00e7\u00e3o<\/em>. A fun\u00e7\u00e3o \u00abInsert-Undo\u00bb permite anular inser\u00e7\u00f5es que ainda n\u00e3o tenham sido confirmadas. O \u00abUpdate-Undo\u00bb mant\u00e9m vers\u00f5es mais antigas em caso de altera\u00e7\u00f5es ou marca\u00e7\u00f5es de elimina\u00e7\u00e3o, para que os instant\u00e2neos continuem a funcionar. O InnoDB marca inicialmente as linhas eliminadas apenas como removidas (marca de elimina\u00e7\u00e3o) e adia a elimina\u00e7\u00e3o efetiva at\u00e9 que nenhum instant\u00e2neo as possa ver. Esta separa\u00e7\u00e3o \u00e9 crucial: as revers\u00f5es (rollbacks) necessitam de estados anteriores precisos, enquanto os leitores consistentes t\u00eam de encontrar uma vers\u00e3o que corresponda logicamente ao seu momento de in\u00edcio. Por isso, as linhas referenciam internamente a vers\u00e3o anterior e os \u00edndices cont\u00eam informa\u00e7\u00f5es adicionais, para que a fun\u00e7\u00e3o \u00abPurge\u00bb possa, posteriormente, eliminar as entradas do \u00edndice de forma limpa.<\/p>\n\n<h2>Lista de hist\u00f3rico, limpar e mem\u00f3ria<\/h2>\n\n<p>Ap\u00f3s cada commit, as altera\u00e7\u00f5es hist\u00f3ricas s\u00e3o guardadas no ficheiro global <strong>Hist\u00f3ria<\/strong> Lista que o thread de purga elimina de forma ass\u00edncrona. Se a purga n\u00e3o conseguir acompanhar o ritmo, esta lista cresce e mant\u00e9m artificialmente ativas vers\u00f5es antigas das linhas. Isso provoca mais percursos de leitura, mais E\/S e espa\u00e7os de tabela de revers\u00e3o maiores. Nestas situa\u00e7\u00f5es, verifico sempre os n\u00edveis de isolamento e os instant\u00e2neos abertos, pois uma configura\u00e7\u00e3o desfavor\u00e1vel <a href=\"https:\/\/webhosting.de\/pt\/mysql-nivel-de-isolamento-alojamento-servidor-consistencia-transaccoes\/\">Escolha do isolamento<\/a> aumenta a vida \u00fatil das vers\u00f5es antigas. Quem tiver em conta a velocidade de purga, a extens\u00e3o do hist\u00f3rico e as transa\u00e7\u00f5es ativas consegue identificar precocemente os pontos de estrangulamento e travar a deriva de mem\u00f3ria antes que se torne cr\u00edtica.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_undo_logs_meeting_2387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mec\u00e2nica de purga e op\u00e7\u00f5es de afina\u00e7\u00e3o<\/h2>\n\n<p>O Purge est\u00e1 a funcionar <em>melhor esfor\u00e7o poss\u00edvel<\/em>: Recolhe entradas que podem ser limpas da Lista de Hist\u00f3rico, remove definitivamente as marcas de elimina\u00e7\u00e3o, atualiza os \u00edndices secund\u00e1rios e liberta as \u00e1reas de anula\u00e7\u00e3o. Em sistemas com elevada taxa de altera\u00e7\u00f5es, dimensiono a <strong>Paralelismo<\/strong> (por exemplo, atrav\u00e9s de v\u00e1rios Purge-Workers) e ajusta a estrat\u00e9gia de processamento em lotes, para que o Purge funcione de forma cont\u00ednua, mas n\u00e3o agressiva. Regras gerais:<\/p>\n<ul>\n  <li>Lotes curtos e constantes em vez de execu\u00e7\u00f5es espor\u00e1dicas em grande escala \u2013 isso uniformiza as opera\u00e7\u00f5es de E\/S e os pontos de verifica\u00e7\u00e3o.<\/li>\n  <li>N\u00e3o se deve opor a \u00abPurge\u00bb ao armazenamento ou \u00e0 limpeza de registos: ambas as abordagens t\u00eam de estar a par.<\/li>\n  <li>Resolver primeiro os \u00absnapshots\u00bb longos antes de aumentar ainda mais o tamanho dos lotes \u2013 caso contr\u00e1rio, o efeito perde-se.<\/li>\n<\/ul>\n<p>Importante: o Purge n\u00e3o substitui uma boa disciplina nas transa\u00e7\u00f5es. Mesmo com um elevado n\u00edvel de paralelismo, o Undo permanece bloqueado enquanto existirem instant\u00e2neos antigos. Por isso, acompanho em simult\u00e2neo o progresso do Purge e a idade das transa\u00e7\u00f5es e ajusto a carga de trabalho se o Purge estiver permanentemente atrasado.<\/p>\n\n<h2>Configura\u00e7\u00e3o dos espa\u00e7os de tabela de anula\u00e7\u00e3o<\/h2>\n\n<p>As informa\u00e7\u00f5es de anula\u00e7\u00e3o podem, dependendo da configura\u00e7\u00e3o, ser armazenadas no espa\u00e7o de tabelas do sistema ou em <strong>Desfazer<\/strong>-Tablespaces. Costumo isolar o Undo para controlar melhor o crescimento e as E\/S. Muitas instala\u00e7\u00f5es permitem o crescimento din\u00e2mico, por vezes incluindo a liberta\u00e7\u00e3o de espa\u00e7o atrav\u00e9s do comando \u00abTruncate\u00bb. Isto parece pr\u00e1tico, mas aumenta a necessidade de monitoriza\u00e7\u00e3o, porque os instant\u00e2neos de longa dura\u00e7\u00e3o impedem uma redu\u00e7\u00e3o r\u00e1pida. Escolho a localiza\u00e7\u00e3o, o tamanho e a paralelidade da purga de forma a que as taxas de altera\u00e7\u00e3o e os intervalos de tempo no dia-a-dia sejam devidamente geridos e <strong>Restaura\u00e7\u00e3o<\/strong> n\u00e3o sofra.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Defini\u00e7\u00e3o<\/th>\n      <th>Efeito<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_undo_directory<\/td>\n      <td>Local de armazenamento para <strong>Desfazer<\/strong>-ficheiros<\/td>\n      <td>Os suportes de dados separados isolam as opera\u00e7\u00f5es de E\/S<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_purge_threads<\/td>\n      <td>Mais <strong>Purga<\/strong>-Trabalhador da minera\u00e7\u00e3o<\/td>\n      <td>Aumentar em caso de elevada taxa de altera\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_undo_log_truncate<\/td>\n      <td>Recupera espa\u00e7o n\u00e3o utilizado<\/td>\n      <td>S\u00f3 \u00e9 eficaz se o History estiver livre<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_undo_log_size<\/td>\n      <td>Limite de crescimento<\/td>\n      <td>Disponibilidade consoante a vers\u00e3o<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Estrutura da mem\u00f3ria e aspetos do sistema de ficheiros<\/h2>\n\n<p>Prefiro colocar os espa\u00e7os de tabela de Undo separados em SSDs r\u00e1pidos, separados das E\/S de dados e de registos. Se o sistema de ficheiros suportar TRIM\/Discard, um comando \u00abTruncate\u00bb pode devolver fisicamente a mem\u00f3ria ao sistema operativo. No entanto, planeio com limites m\u00e1ximos conservadores, porque a liberta\u00e7\u00e3o de espa\u00e7o n\u00e3o \u00e9 garantida enquanto os instant\u00e2neos estiverem ligados ao Undo. A compress\u00e3o no sistema de ficheiros s\u00f3 vale a pena se houver margem de manobra da CPU e se os padr\u00f5es de grava\u00e7\u00e3o n\u00e3o causarem fragmenta\u00e7\u00e3o. Continua a ser importante monitorizar os picos de lat\u00eancia: se o \u00abUndo\u00bb crescer num disco sobrecarregado, a amplifica\u00e7\u00e3o de grava\u00e7\u00e3o e a press\u00e3o dos pontos de verifica\u00e7\u00e3o agravam-se progressivamente.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e diagn\u00f3stico<\/h2>\n\n<p>Verifico regularmente o tamanho do <strong>Desfazer<\/strong>- Espa\u00e7os de tabela, o comprimento da lista de hist\u00f3rico e a idade das transa\u00e7\u00f5es em aberto. Os comandos SHOW ENGINE InnoDB STATUS, o Performance Schema e o Information Schema fornecem sinais claros. Se as \u00e1reas de undo estiverem a crescer, enquanto a purga tem pouco efeito, come\u00e7o por encerrar as sess\u00f5es antigas. Al\u00e9m disso, analiso os bloqueios, pois os desnecess\u00e1rios <a href=\"https:\/\/webhosting.de\/pt\/bloqueio-de-linhas-na-base-de-dados-otimizacao-da-concorrencia-no-mysql-desempenho-bloqueios\/\">Bloqueios de remo<\/a> prolongam as transa\u00e7\u00f5es e os instant\u00e2neos. Quem analisa diariamente estes indicadores evita picos repentinos de E\/S e reduz os percursos no <strong>Mem\u00f3ria<\/strong>.<\/p>\n\n<h2>Consequ\u00eancias no desempenho de transa\u00e7\u00f5es demoradas<\/h2>\n\n<p>Transa\u00e7\u00f5es longas de leitura ou escrita demoram <strong>Vers\u00f5es<\/strong> permanentes, mesmo que estejam logicamente desatualizadas. Isso aumenta o volume do Undo, alarga as varreduras e intensifica a press\u00e3o sobre a cache. Reduzo esses efeitos com lotes mais curtos, o uso consistente do COMMIT e tempos limite para as sess\u00f5es. Os relat\u00f3rios que demoram horas a ser lidos funcionam melhor em janelas mais pequenas ou contra r\u00e9plicas. Quem desativa o autocommit, otimiza os planos de consulta e encerra transa\u00e7\u00f5es inativas, liberta o Purge e alivia a carga sobre a <strong>Inst\u00e2ncia<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-undo-logs-insight-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Segmentos de rollback e paralelismo<\/h2>\n\n<p>As entradas de \u00abUndo\u00bb encontram-se em <em>Segmentos de rollback<\/em>, que, por assim dizer, disponibilizam \u00abslots\u00bb para altera\u00e7\u00f5es ativas em simult\u00e2neo. Muitos \u00abwriters\u00bb simult\u00e2neos beneficiam de segmentos de rollback suficientes, uma vez que as inser\u00e7\u00f5es e atualiza\u00e7\u00f5es t\u00eam, assim, de partilhar as suas cadeias de anula\u00e7\u00e3o com menos frequ\u00eancia. Observo padr\u00f5es de espera nos recursos de rollback e aumento o seu n\u00famero sempre que a vers\u00e3o e a distribui\u00e7\u00e3o o permitirem. Os sintomas de falta de paralelismo s\u00e3o tempos de espera inesperados em fases de atualiza\u00e7\u00e3o que, de resto, seriam curtas, ou lat\u00eancias de grava\u00e7\u00e3o muito vari\u00e1veis sob carga. Um maior n\u00famero de segmentos distribui a press\u00e3o, mas n\u00e3o anula a regra b\u00e1sica: instant\u00e2neos longos superam qualquer otimiza\u00e7\u00e3o.<\/p>\n\n<h2>N\u00edveis de isolamento em pormenor<\/h2>\n\n<p>O <a href=\"https:\/\/webhosting.de\/pt\/mysql-nivel-de-isolamento-alojamento-servidor-consistencia-transaccoes\/\">N\u00edvel de isolamento<\/a> determina durante quanto tempo as vers\u00f5es de revers\u00e3o (Undo) s\u00e3o relevantes. No modo REPEATABLE READ, uma transa\u00e7\u00e3o mant\u00e9m o seu instant\u00e2neo inicial durante toda a sua dura\u00e7\u00e3o; assim, a revers\u00e3o (Undo) permanece potencialmente associada durante muito tempo. No modo READ COMMITTED, s\u00e3o criadas janelas de visualiza\u00e7\u00e3o por instru\u00e7\u00e3o; isto reduz significativamente a dura\u00e7\u00e3o das vers\u00f5es antigas em muitas cargas de trabalho. SELECT \u2026 FOR UPDATE e LOCK IN SHARE MODE aplicam bloqueios e alteram o perfil de concorr\u00eancia \u2014 \u00fateis contra \u00abLost Updates\u00bb, mas cr\u00edticos 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\u00f3rios ou as leituras de API necessitam de vis\u00f5es consistentes, mas n\u00e3o ao n\u00edvel da transa\u00e7\u00e3o, e opto pelo REPEATABLE READ quando a l\u00f3gica de neg\u00f3cio assim o exige.<\/p>\n\n<h2>Cen\u00e1rios de recupera\u00e7\u00e3o e arranque<\/h2>\n\n<p>Ao iniciar, o InnoDB utiliza o <strong>Desfazer<\/strong>-Informa\u00e7\u00f5es para reverter transa\u00e7\u00f5es incompletas de forma correta. Isto garante vis\u00f5es consistentes antes de novos clientes come\u00e7arem a trabalhar. Em casos especiais, existem modos de arranque que encurtam as verifica\u00e7\u00f5es, mas s\u00f3 os utilizo em caso de emerg\u00eancia. A acelera\u00e7\u00e3o pura, sem diagn\u00f3stico, acaba por se revelar contraproducente, porque a integridade tem prioridade. Quem mant\u00e9m o tempo de recupera\u00e7\u00e3o e os tamanhos de revers\u00e3o sob controlo toma melhores decis\u00f5es sobre janelas de manuten\u00e7\u00e3o e <strong>Risco<\/strong>.<\/p>\n\n<h2>Regras pr\u00e1ticas para a administra\u00e7\u00e3o<\/h2>\n\n<p>Procuro manter as transa\u00e7\u00f5es curtas, fa\u00e7o commits com frequ\u00eancia e evito sess\u00f5es de leitura intermin\u00e1veis, para que <strong>Purga<\/strong> tem via livre. Divido as altera\u00e7\u00f5es em massa de maior dimens\u00e3o em lotes bem dosados, para que a Lista de Hist\u00f3rico n\u00e3o aumente. Dimensiono os threads de purga de acordo com a taxa de altera\u00e7\u00e3o e adapto o layout de Undo ao hardware de mem\u00f3ria. Al\u00e9m disso, documento os processos de neg\u00f3cio que requerem instant\u00e2neos demorados e planeio deliberadamente as janelas de tempo. Desta forma, a utiliza\u00e7\u00e3o do Undo permanece previs\u00edvel e a <strong>Lat\u00eancia<\/strong> baixo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mdb_undologs_tech_office_3821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Padr\u00f5es de carga de trabalho e otimiza\u00e7\u00e3o<\/h2>\n\n<p>O com\u00e9rcio eletr\u00f3nico, os sistemas de relat\u00f3rios e os sistemas de conte\u00fados geram muitas altera\u00e7\u00f5es e exigem uma abordagem disciplinada <strong>Transac\u00e7\u00f5es<\/strong>. Defino tempos limite conservadores para os leitores, otimizo \u00edndices para atualiza\u00e7\u00f5es precisas e limito o tamanho dos lotes. Em caso de elevada carga de grava\u00e7\u00e3o, aumento a paraleliza\u00e7\u00e3o da purga e regulo a press\u00e3o dos pontos de verifica\u00e7\u00e3o. Al\u00e9m disso, verifico a taxa de grava\u00e7\u00e3o em rela\u00e7\u00e3o a <a href=\"https:\/\/webhosting.de\/pt\/registos-de-transaccoes-da-base-de-dados-processos-de-recuperacao-protecao-da-base-de-dados-segura\/\">Registos de transa\u00e7\u00f5es e recupera\u00e7\u00e3o<\/a>, para que a recupera\u00e7\u00e3o ap\u00f3s falhas continue a ser previs\u00edvel. Esta intera\u00e7\u00e3o permite planear o volume de opera\u00e7\u00f5es de anula\u00e7\u00e3o e protege a <strong>Consist\u00eancia<\/strong>.<\/p>\n\n<h2>C\u00f3pias de seguran\u00e7a e replica\u00e7\u00e3o<\/h2>\n\n<p>As c\u00f3pias de seguran\u00e7a l\u00f3gicas com instant\u00e2neos consistentes prolongam inevitavelmente a vida \u00fatil das vers\u00f5es antigas \u2013 a lista de \u00abUndo\u00bb cresce at\u00e9 que a c\u00f3pia de seguran\u00e7a esteja conclu\u00edda. Planeio essas execu\u00e7\u00f5es fora dos per\u00edodos de pico, limito o n\u00famero de escritores simult\u00e2neos e disponibilizo capacidade de purga suficiente. Os backups f\u00edsicos podem reduzir a carga de \u00abUndo\u00bb, mas n\u00e3o dispensam o cuidado necess\u00e1rio com os instant\u00e2neos. Nas r\u00e9plicas, prefiro manter os relat\u00f3rios em modo READ COMMITTED e encerro transa\u00e7\u00f5es de inatividade prolongadas, para que o SQL-Apply n\u00e3o fique para tr\u00e1s. Se uma r\u00e9plica ficar atrasada, a carga de Undo tamb\u00e9m aumenta nessa r\u00e9plica, pois a sincroniza\u00e7\u00e3o de muitas elimina\u00e7\u00f5es\/atualiza\u00e7\u00f5es produz uma onda de hist\u00f3rico que a purga tem de processar primeiro.<\/p>\n\n<h2>Runbook: Travar rapidamente o crescimento do Undo<\/h2>\n\n<ul>\n  <li>Identificar utilizadores ativos de longa dura\u00e7\u00e3o: verificar a dura\u00e7\u00e3o das transa\u00e7\u00f5es em aberto e as sess\u00f5es com conjuntos de resultados de grande dimens\u00e3o.<\/li>\n  <li>Encerrar de forma sistem\u00e1tica os processos inativos na transa\u00e7\u00e3o: verificar o autocommit e fechar os cursores esquecidos.<\/li>\n  <li>Aumentar a capacidade de purga: ativar workers adicionais e aumentar moderadamente o tamanho dos lotes.<\/li>\n  <li>Suavizar picos no Writer: limitar os tamanhos dos lotes, introduzir micro-commits.<\/li>\n  <li>Aproveitar as janelas de manuten\u00e7\u00e3o: transferir grandes ondas de elimina\u00e7\u00e3o\/atualiza\u00e7\u00e3o para intervalos program\u00e1veis.<\/li>\n  <li>Ap\u00f3s a estabiliza\u00e7\u00e3o: permitir o comando \u00abUndo-Truncate\u00bb at\u00e9 que o tamanho do sistema de ficheiros volte a corresponder \u00e0s necessidades.<\/li>\n<\/ul>\n\n<h2>Planeamento de capacidade para o Undo<\/h2>\n\n<p>Calculo o Undo de forma conservadora com base na taxa de altera\u00e7\u00e3o, no tamanho m\u00e9dio das linhas e na janela m\u00e1xima do snapshot. Uma aproxima\u00e7\u00e3o simples: eventos de altera\u00e7\u00e3o por segundo \u00d7 carga \u00fatil m\u00e9dia \u00d7 janela de visibilidade planeada em segundos. Tem de se ter em conta uma margem de seguran\u00e7a para \u00edndices e metadados. Esta f\u00f3rmula emp\u00edrica d\u00e1 uma ideia das necessidades no pior dos casos e protege contra surpresas quando se realizam relat\u00f3rios, c\u00f3pias de seguran\u00e7a ou processos de migra\u00e7\u00e3o <em>ao mesmo tempo<\/em> Incorporar instant\u00e2neos. Em sistemas em crescimento, verifico trimestralmente se as altera\u00e7\u00f5es na carga de trabalho (novas funcionalidades, mais clientes m\u00f3veis, picos mais intensos) alteram as necessidades.<\/p>\n\n<h2>Casos especiais: tabelas tempor\u00e1rias e DDL<\/h2>\n\n<p>As tabelas InnoDB tempor\u00e1rias utilizam \u00e1reas pr\u00f3prias; as altera\u00e7\u00f5es nessas tabelas t\u00eam um impacto menor no Undo normal, mas podem, ainda assim, gerar um volume elevado de E\/S em casos de ordena\u00e7\u00f5es ou jun\u00e7\u00f5es de grande dimens\u00e3o. As opera\u00e7\u00f5es DDL, como ALTER TABLE, geram frequentemente ondas de altera\u00e7\u00f5es massivas \u2013 caso seja necess\u00e1rio, divido-as em etapas incrementais e agendo-as em fases de menor atividade. Tamb\u00e9m neste caso se aplica o seguinte: transa\u00e7\u00f5es curtas e bem organizadas s\u00e3o prefer\u00edveis a atalhos arriscados. Se uma execu\u00e7\u00e3o de DDL for interrompida, o Undo ajuda a regressar a um estado consistente; para tal, por\u00e9m, \u00e9 necess\u00e1ria mem\u00f3ria e tempo suficientes, que eu prevejo antecipadamente.<\/p>\n\n<h2>Exemplo: medir os impactos<\/h2>\n\n<p>Come\u00e7o por obter um instant\u00e2neo de refer\u00eancia do tamanho da fun\u00e7\u00e3o \u00abUndo\u00bb, que <strong>Hist\u00f3ria<\/strong>- o comprimento e a dura\u00e7\u00e3o m\u00e9dia das transa\u00e7\u00f5es. Em seguida, implemento altera\u00e7\u00f5es espec\u00edficas, como aumentar o n\u00famero de threads de purga ou reduzir o tamanho dos lotes. Em seguida, comparo os indicadores at\u00e9 que o crescimento das opera\u00e7\u00f5es de anula\u00e7\u00e3o e as lat\u00eancias atinjam um equil\u00edbrio saud\u00e1vel. Se encontrar valores at\u00edpicos, analiso os planos de consulta e as listas de sess\u00f5es para identificar leitores bloqueados. Este processo c\u00edclico proporciona resultados r\u00e1pidos, sem comprometer a <strong>Disponibilidade<\/strong> p\u00f4r em risco.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_undo_logs_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Equ\u00edvocos comuns<\/h2>\n\n<p>Um commit n\u00e3o apaga as vers\u00f5es antigas de imediato; <strong>Purga<\/strong> s\u00f3 se decide mais tarde. As op\u00e7\u00f5es \u00abTruncate\u00bb n\u00e3o resolvem um problema de conce\u00e7\u00e3o fundamental quando as transa\u00e7\u00f5es duram demasiado tempo. Ficheiros \u00abUndo\u00bb de grande dimens\u00e3o n\u00e3o significam necessariamente corrup\u00e7\u00e3o; muitas vezes, basta uma \u00fanica sess\u00e3o para causar o bloqueio. Embora os leitores raramente bloqueiem os gravadores, as consultas inadequadas prolongam indiretamente os instant\u00e2neos. Quem eliminar estes erros toma melhores decis\u00f5es e reduz <strong>Tempos de inatividade<\/strong>.<\/p>\n\n<h2>Resumo para quem est\u00e1 com pressa<\/h2>\n\n<p>Manter registos de anula\u00e7\u00e3o <strong>Passado<\/strong> tang\u00edvel, para que o InnoDB reverta as transa\u00e7\u00f5es com seguran\u00e7a e os leitores vejam vistas consistentes. Controlo o crescimento otimizando as transa\u00e7\u00f5es, configurando corretamente os threads de purga e posicionando os espa\u00e7os de tabela de revers\u00e3o de forma adequada. A monitoriza\u00e7\u00e3o do comprimento do hist\u00f3rico, dos tamanhos de \u00abundo\u00bb e da idade das transa\u00e7\u00f5es revela tend\u00eancias numa fase precoce. Em caso de anomalias, verifico a carga de trabalho, os bloqueios e as sess\u00f5es, em vez de me concentrar nos sintomas. Quem mant\u00e9m esta rotina garante o desempenho, a consist\u00eancia e <strong>rein\u00edcio<\/strong> sempre sob controlo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-undo-logs-4982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Explica\u00e7\u00e3o sobre os registos de anula\u00e7\u00e3o do MariaDB: Funcionamento interno do InnoDB, revers\u00e3o, MVCC e dicas de administra\u00e7\u00e3o para melhorar o desempenho e a estabilidade.<\/p>","protected":false},"author":1,"featured_media":21112,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21119","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"159","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Undo","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21112","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21119"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21119\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21112"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}