{"id":21299,"date":"2026-09-11T15:08:03","date_gmt":"2026-09-11T13:08:03","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-binary-logs-performance-logik\/"},"modified":"2026-09-11T15:08:03","modified_gmt":"2026-09-11T13:08:03","slug":"logica-de-desempenho-dos-registos-binarios-do-mariadb","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-binary-logs-performance-logik\/","title":{"rendered":"Registos bin\u00e1rios do MariaDB: estrutura, utiliza\u00e7\u00e3o e desempenho"},"content":{"rendered":"<p><strong>Registos bin\u00e1rios do MariaDB<\/strong> registam todas as opera\u00e7\u00f5es de grava\u00e7\u00e3o e controlam a replica\u00e7\u00e3o, a recupera\u00e7\u00e3o e a auditoria em inst\u00e2ncias produtivas. Vou mostrar como a estrutura, os formatos e os novos binlogs do InnoDB interagem entre si, onde trazem vantagens e quais as configura\u00e7\u00f5es que melhoram o desempenho em cargas de trabalho reais.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Estrutura<\/strong>: ficheiros, \u00edndice, eventos; sa\u00edda em texto simples atrav\u00e9s do mariadb-binlog<\/li>\n  <li><strong>Formatos<\/strong>: Statement, Row, Mixed \u2013 escolher de acordo com a carga de trabalho<\/li>\n  <li><strong>Replica\u00e7\u00e3o<\/strong>: Ter em conta a posi\u00e7\u00e3o vs. GTID e a compatibilidade<\/li>\n  <li><strong>Desempenho<\/strong>: Group Commit, estrat\u00e9gias de flush, E\/S de armazenamento<\/li>\n  <li><strong>Administra\u00e7\u00e3o<\/strong>: Rota\u00e7\u00e3o, armazenamento, an\u00e1lise e resolu\u00e7\u00e3o de problemas<\/li>\n<\/ul>\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\/09\/mariadb-binarylogs-1293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Estrutura: ficheiros, \u00edndice e eventos<\/h2>\n\n<p>Um binlog \u00e9 composto por ficheiros binlog e por um \u00edndice que mant\u00e9m a ordem e permite uma leitura seletiva; isto <strong>Ficheiro de \u00edndice<\/strong> torna a gest\u00e3o previs\u00edvel. Cada ficheiro armazena eventos que representam DML e DDL, incluindo limites de transa\u00e7\u00f5es e metadados por evento. Recorro a esta informa\u00e7\u00e3o quando necess\u00e1rio com <strong>mariadb-binlog<\/strong> e obtenho assim texto simples, f\u00e1cil de analisar. Os pr\u00f3prios binlogs permanecem bin\u00e1rios, para que o desempenho de grava\u00e7\u00e3o e os requisitos de mem\u00f3ria se mantenham eficientes no funcionamento di\u00e1rio. Importante: verifico regularmente os tipos de eventos, pois estes revelam se o formato de registo ativo se adequa \u00e0 carga atual.<\/p>\n\n<h2>Formatos de binlog: Statement, Row, Mixed<\/h2>\n\n<p>O MariaDB suporta o registo por instru\u00e7\u00e3o, por linha e misto, e eu decido consoante o padr\u00e3o de grava\u00e7\u00e3o; isto <strong>Formato<\/strong> controla o tamanho do ficheiro, a seguran\u00e7a da replica\u00e7\u00e3o e os requisitos de rede. O modo \u00abStatement\u00bb guarda a instru\u00e7\u00e3o SQL, \u00e9 frequentemente mais compacto, mas pode causar desvios no caso de fun\u00e7\u00f5es n\u00e3o determin\u00edsticas. O modo \u00abRow\u00bb regista as linhas afetadas e mant\u00e9m as r\u00e9plicas muito pr\u00f3ximas do original, mas gera um volume maior de registos. A op\u00e7\u00e3o \u00abMixed\u00bb seleciona dinamicamente e procura o melhor equil\u00edbrio entre precis\u00e3o e volume. Para uma replica\u00e7\u00e3o consistente, em sistemas sens\u00edveis, prefiro utilizar \u00abRow\u00bb ou \u00abMixed\u00bb e, em seguida, verifico a lat\u00eancia.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Formato<\/strong><\/th>\n      <th><strong>Mem\u00f3ria<\/strong><\/th>\n      <th><strong>Exatid\u00e3o<\/strong><\/th>\n      <th><strong>Utiliza\u00e7\u00e3o t\u00edpica<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Declara\u00e7\u00e3o<\/td>\n      <td>Baixa<\/td>\n      <td>Recursos (dependendo das fun\u00e7\u00f5es\/gatilhos)<\/td>\n      <td>Muitas linhas por instru\u00e7\u00e3o, baixa carga na rede<\/td>\n    <\/tr>\n    <tr>\n      <td>Row<\/td>\n      <td>Mais alto<\/td>\n      <td>Alto (baseado em linhas, determin\u00edstico)<\/td>\n      <td>Dados sens\u00edveis, replica\u00e7\u00e3o heterog\u00e9nea<\/td>\n    <\/tr>\n    <tr>\n      <td>Misto<\/td>\n      <td>M\u00e9dio<\/td>\n      <td>Elevado (dependendo da situa\u00e7\u00e3o)<\/td>\n      <td>Cargas de trabalho mistas, comuns em muitas configura\u00e7\u00f5es<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Binlogs baseados em InnoDB a partir da vers\u00e3o 12.3<\/h2>\n\n<p>A partir da vers\u00e3o 12.3, o MariaDB pode guardar eventos do binlog em ficheiros geridos pelo InnoDB com a extens\u00e3o .ibb, o que facilita a <strong>InnoDB<\/strong> aumenta. Beneficio de uma integra\u00e7\u00e3o estreita com os redo logs e de um percurso simplificado de recupera\u00e7\u00e3o ap\u00f3s falhas. A sobrecarga do Two-Phase Commit entre o motor de armazenamento e o binlog cl\u00e1ssico diminui assim de forma significativa. Especialmente em caso de elevada carga de grava\u00e7\u00e3o, isto reduz o n\u00famero de flushes necess\u00e1rios e estabiliza os tempos de commit em situa\u00e7\u00f5es de press\u00e3o. No entanto, antes da mudan\u00e7a, verifico as ferramentas, a monitoriza\u00e7\u00e3o e os processos de c\u00f3pia de seguran\u00e7a, uma vez que o modelo operacional altera alguns procedimentos em rela\u00e7\u00e3o aos ficheiros cl\u00e1ssicos.<\/p>\n\n<h2>Replica\u00e7\u00e3o: posi\u00e7\u00e3o, GTID e consist\u00eancia<\/h2>\n\n<p>Para a replica\u00e7\u00e3o, uma r\u00e9plica l\u00ea os eventos do binlog do prim\u00e1rio e executa-os na mesma ordem, de modo a garantir a consist\u00eancia <strong>Dados<\/strong> em v\u00e1rios n\u00f3s. Normalmente, acompanho o nome do ficheiro e a posi\u00e7\u00e3o; com o GTID, o tratamento do failover e a recupera\u00e7\u00e3o ap\u00f3s falhas tornam-se mais simples. Em ambientes mistos MariaDB\/MySQL, presto aten\u00e7\u00e3o \u00e0s diferen\u00e7as nos GTIDs e na interpreta\u00e7\u00e3o de eventos. Para garantir a disponibilidade em todo o cluster, planeio as topologias de forma consciente e, para tal, recorro frequentemente a vis\u00f5es gerais concisas, como <a href=\"https:\/\/webhosting.de\/pt\/topologias-de-replicacao-de-bases-de-dados-configuracao-de-clusters-de-alojamento-escalabilidade-de-bases-de-dados\/\">Replica\u00e7\u00e3o de bases de dados<\/a>. Importante: documentar os intervalos de replica\u00e7\u00e3o e fazer c\u00f3pias de seguran\u00e7a do hist\u00f3rico do binlog, de forma a que nenhuma r\u00e9plica fique \u201esem dados\u201c e, consequentemente, tenha de ser reiniciada.<\/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\/09\/mariadb_binarylogs_meeting_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando os registos bin\u00e1rios proporcionam o maior benef\u00edcio<\/h2>\n\n<p>Utilizo os binlogs quando pretendo acompanhar altera\u00e7\u00f5es, reverter mudan\u00e7as ou transferi-las para v\u00e1rios servidores; estes <strong>Transpar\u00eancia<\/strong> Refor\u00e7a o funcionamento e a conformidade. Os cen\u00e1rios t\u00edpicos incluem alta disponibilidade com r\u00e9plicas, recupera\u00e7\u00e3o pontual ap\u00f3s erros de opera\u00e7\u00e3o e an\u00e1lises forenses. Em lojas com elevado volume de grava\u00e7\u00f5es, guardo os binlogs de forma rigorosa e planeio a sua conserva\u00e7\u00e3o de acordo com os requisitos de RPO\/RTO. Para auditorias, exporto per\u00edodos espec\u00edficos atrav\u00e9s do comando `mariadb-binlog` e verifico os eventos DDL separadamente. Quem se aprofundar nas an\u00e1lises de desempenho obt\u00e9m, a partir dos eventos, informa\u00e7\u00f5es valiosas sobre \u00abhot tables\u00bb e padr\u00f5es de bloqueio.<\/p>\n\n<h2>C\u00f3pia de seguran\u00e7a e recupera\u00e7\u00e3o pontual com binlogs<\/h2>\n\n<p>Para uma recupera\u00e7\u00e3o precisa, combino uma c\u00f3pia de seguran\u00e7a completa consistente com os binlogs subsequentes; estes <strong>Combina\u00e7\u00e3o<\/strong> garante o estado do sistema at\u00e9 pouco antes da ocorr\u00eancia. O procedimento \u00e9 claro: criar uma c\u00f3pia de seguran\u00e7a, definir o momento da falha e, em seguida, importar os binlogs at\u00e9 esse segundo. Testo regularmente o processo em inst\u00e2ncias separadas, para evitar surpresas em caso de emerg\u00eancia. Quem quiser aprofundar os seus conhecimentos sobre transa\u00e7\u00f5es e estrat\u00e9gias de recupera\u00e7\u00e3o encontrar\u00e1 informa\u00e7\u00f5es adicionais sobre <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>. Ao importar os dados, tem de ter em aten\u00e7\u00e3o o formato do ficheiro binlog e o SQL_MODE, para que as fun\u00e7\u00f5es e os triggers reajam da mesma forma.<\/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\/09\/mariadb-binary-logs-performance-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Impactos no desempenho e sobrecarga<\/h2>\n\n<p>O registo bin\u00e1rio ativo implica um trabalho adicional de grava\u00e7\u00e3o, o que tenho sempre em conta nos or\u00e7amentos de lat\u00eancia; isto <strong>Horas extraordin\u00e1rias<\/strong> varia consoante o armazenamento, o formato e o tamanho da transa\u00e7\u00e3o. O Group Commit agrupa v\u00e1rias transa\u00e7\u00f5es por flush e reduz as opera\u00e7\u00f5es de E\/S por commit. Menos opera\u00e7\u00f5es de E\/S, mas de maior dimens\u00e3o, aumentam frequentemente o d\u00e9bito, desde que a pilha de armazenamento consiga acompanhar. Preste aten\u00e7\u00e3o \u00e0s estrat\u00e9gias de sincroniza\u00e7\u00e3o, como o `sync_binlog`, e ao comportamento da cache do SO, pois configura\u00e7\u00f5es de flush demasiado agressivas causam lentid\u00e3o. Quem monitoriza a lat\u00eancia de replica\u00e7\u00e3o deve otimizar continuamente em fun\u00e7\u00e3o de <a href=\"https:\/\/webhosting.de\/pt\/mysql-atraso-na-replicacao-otimizacao-do-alojamento-atraso-no-servidor\/\">Atraso na replica\u00e7\u00e3o<\/a> e mede as altera\u00e7\u00f5es de forma direcionada.<\/p>\n\n<h2>Estrat\u00e9gias de \u00abGroup Commit\u00bb e \u00abFlush\u00bb<\/h2>\n\n<p>Configurei o Group Commit de forma a que a carga de escrita chegue em ondas e o armazenamento funcione de forma eficiente; isto <strong>Afina\u00e7\u00e3o<\/strong> tem frequentemente um impacto maior do que a otimiza\u00e7\u00e3o da CPU. Par\u00e2metros como o binlog_group_commit_sync_delay e o n\u00famero de eventos armazenados em buffer determinam o intervalo de tempo para o agrupamento. Op\u00e7\u00f5es do InnoDB, como innodb_flush_log_at_trx_commit e a escolha do sistema de ficheiros, determinam o custo de um flush. Em SSD\/NVMe com cache de write-back, posso arriscar um pouco mais de buffer; em armazenamento em rede mais lento, prefiro manter uma abordagem conservadora. Para medi\u00e7\u00f5es de controlo, altero apenas um par\u00e2metro por execu\u00e7\u00e3o de teste e mantenho os tamanhos das transa\u00e7\u00f5es constantes.<\/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\/09\/TechOfficeMariaDBNight_8491.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escolha do formato e padr\u00f5es de carga de trabalho<\/h2>\n\n<p>Escolho a op\u00e7\u00e3o \u00abStatement\u00bb quando poucas instru\u00e7\u00f5es abrangem um grande n\u00famero de linhas e se mant\u00eam determin\u00edsticas; isto <strong>Conduta<\/strong> Poupa rede e espa\u00e7o de armazenamento. No caso de triggers, UUIDs, NOW() ou RAND(), defino \u00abRow\u00bb para que as r\u00e9plicas atinjam exatamente o mesmo estado. A op\u00e7\u00e3o \u00abMixed\u00bb adapta-se bem a padr\u00f5es mistos, em que algumas instru\u00e7\u00f5es alteram muitas linhas e outras atuam apenas pontualmente. Para tarefas ETL com inser\u00e7\u00f5es em massa, o \u00abStatement\u00bb costuma ser a melhor op\u00e7\u00e3o devido aos registos de log reduzidos; em padr\u00f5es de Event Sourcing, o \u00abRow\u00bb destaca-se pelas altera\u00e7\u00f5es exatas nas linhas. Ap\u00f3s cada mudan\u00e7a, analiso o tamanho dos ficheiros, o tempo de aplica\u00e7\u00e3o nas r\u00e9plicas e eventuais atrasos.<\/p>\n\n<h2>Gerir a rota\u00e7\u00e3o e a conserva\u00e7\u00e3o dos registos<\/h2>\n\n<p>Para evitar que os registos se acumulem excessivamente, fa\u00e7o a sua rota\u00e7\u00e3o de forma ativa e defino um per\u00edodo de reten\u00e7\u00e3o; este <strong>Disciplina<\/strong> Poupa espa\u00e7o de armazenamento e mant\u00e9m as cadeias de recupera\u00e7\u00e3o completas. Com o comando FLUSH BINARY LOGS, inicio novos ficheiros, enquanto os comandos de limpeza eliminam artefactos antigos. Configura\u00e7\u00f5es baseadas no tempo, como binlog_expire_logs_seconds, facilitam a manuten\u00e7\u00e3o autom\u00e1tica. Importante: n\u00e3o elimino nada enquanto uma r\u00e9plica ainda possa precisar dos ficheiros. Em caso de congestionamentos, transfiro os binlogs para uma mem\u00f3ria mais r\u00e1pida ou separo os volumes de dados dos volumes de registo.<\/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\/09\/mariadb_logs_desk_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resolu\u00e7\u00e3o de problemas com o mariadb-binlog<\/h2>\n\n<p>Quando a replica\u00e7\u00e3o fica bloqueada, leio os eventos afetados com o `mariadb-binlog` e verifico os carimbos de data\/hora, os XIDs e os erros; estes <strong>An\u00e1lise<\/strong> muitas vezes revela a falta de direitos DDL ou fun\u00e7\u00f5es n\u00e3o determin\u00edsticas. Comparo os estados GTID ou as regras de filtragem para identificar instru\u00e7\u00f5es que est\u00e3o a bloquear o processo. No caso de chaves duplicadas, consigo perceber rapidamente se uma nova tentativa ou um filtro resolve o problema. Deteto lacunas existentes na cadeia atrav\u00e9s de saltos no \u00edndice ou de nomes de ficheiros inesperados. Em seguida, ajusto os filtros e o formato para que os problemas subsequentes nem sequer surjam.<\/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\/09\/mariadb-performance-log-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Guia pr\u00e1tico: Configura\u00e7\u00f5es por objetivo<\/h2>\n\n<p>Come\u00e7o com o registo misto e verifico se o tamanho e o tempo de replica\u00e7\u00e3o est\u00e3o adequados; isto <strong>Linha de base<\/strong> proporciona uma base de compara\u00e7\u00e3o justa. Se a lat\u00eancia aumentar durante o commit, verifico primeiro os par\u00e2metros do Group Commit e a pol\u00edtica de sincroniza\u00e7\u00e3o. Se a necessidade de mem\u00f3ria aumentar demasiado, testo as instru\u00e7\u00f5es em lotes determin\u00edsticos ou arquivo os binlogs com maior frequ\u00eancia. Em caso de elevada criticidade de falhas, analiso os binlogs baseados em InnoDB, uma vez que um menor n\u00famero de flushes mant\u00e9m o tempo de commit mais est\u00e1vel. Documento brevemente cada altera\u00e7\u00e3o, para que as medi\u00e7\u00f5es posteriores possam ser claramente atribu\u00eddas.<\/p>\n\n<h2>Seguran\u00e7a e conformidade: encripta\u00e7\u00e3o, acesso, integridade<\/h2>\n<p>Fa\u00e7o c\u00f3pias de seguran\u00e7a dos binlogs tal como fa\u00e7o com os dados de produ\u00e7\u00e3o: apenas as contas autorizadas t\u00eam direitos de leitura no sistema de ficheiros e, dependendo da vers\u00e3o, ativo a encripta\u00e7\u00e3o dos binlogs. Desta forma, os dados permanecem protegidos quando inativos, mesmo que as c\u00f3pias de seguran\u00e7a sejam guardadas em suportes externos. Al\u00e9m disso, configuro <strong>binlog_checksum<\/strong> (geralmente CRC32), para verificar a integridade durante a transfer\u00eancia. Quem trata dados pessoais deve estabelecer prazos de conserva\u00e7\u00e3o no plano de elimina\u00e7\u00e3o e verificar regularmente se a rota\u00e7\u00e3o cumpre efetivamente esses requisitos. Para efeitos de auditoria, mantenho um caminho de exporta\u00e7\u00e3o definido, no qual extraio intervalos de tempo relevantes dos binlogs e os arquivo de forma a garantir a conformidade com os requisitos de auditoria.<\/p>\n\n<h2>Replica\u00e7\u00e3o paralela e ajuste do aplicador<\/h2>\n<p>Para um processamento mais r\u00e1pido nas r\u00e9plicas, utilizo a replica\u00e7\u00e3o paralela. No MariaDB, controlo isso principalmente atrav\u00e9s de <strong>slave_parallel_threads<\/strong> e o modo <strong>slave_parallel_mode<\/strong> (conservador vs. otimista). Um maior n\u00famero de threads do Applier \u00e9 \u00fatil sobretudo em transa\u00e7\u00f5es independentes ou separadas <em>domain_id<\/em>\u2011\u00c1reas nos GTIDs. Ao faz\u00ea-lo, observo as taxas de conflito e os deadlocks: se estas aumentarem, reduzo o n\u00famero de threads ou opto por um modo mais conservador. No que diz respeito ao armazenamento, a aplica\u00e7\u00e3o paralela requer uma reserva suficiente de IOPS; caso contr\u00e1rio, o estrangulamento apenas se desloca da rede para os discos. Importante: o n\u00famero de aplicadores n\u00e3o tem qualquer efeito se o binlog contiver predominantemente transa\u00e7\u00f5es individuais de grande dimens\u00e3o, que, de qualquer forma, t\u00eam de ser processadas em s\u00e9rie.<\/p>\n\n<h2>Regras de filtragem, GTIDs e ambientes mistos<\/h2>\n<p>Com <strong>binlog_do_db<\/strong> e <strong>binlog_ignore_db<\/strong> Reduzo o volume de registos j\u00e1 no servidor prim\u00e1rio e, com filtros de replica\u00e7\u00e3o nas r\u00e9plicas, limito o \u00e2mbito de aplica\u00e7\u00e3o. No registo de instru\u00e7\u00f5es, certifico-me de que a base de dados atual est\u00e1 definida corretamente; caso contr\u00e1rio, os filtros funcionam de forma diferente do esperado. Em configura\u00e7\u00f5es GTID, documento o <em>domain_id<\/em>\u2011Utiliza\u00e7\u00e3o (espec\u00edfica do MariaDB), para que a replica\u00e7\u00e3o multi-fonte se mantenha controlada. Em ambientes mistos MariaDB\/MySQL, verifico previamente a compatibilidade de eventos e os dialetos GTID; As diferen\u00e7as n\u00e3o se limitam apenas \u00e0 sintaxe, mas tamb\u00e9m ao comportamento em pormenor (por exemplo, sem\u00e2ntica dos gatilhos, imagem de linha). Por isso, planeio as migra\u00e7\u00f5es com testes que enviam eventos reais de produ\u00e7\u00e3o atrav\u00e9s da pilha de destino.<\/p>\n\n<h2>Eventos DDL, altera\u00e7\u00f5es em linha e bloqueios<\/h2>\n<p>O DDL tamb\u00e9m grava no binlog e pode bloquear as r\u00e9plicas durante muito tempo \u2013 especialmente em caso de altera\u00e7\u00f5es de esquema em tabelas de grande dimens\u00e3o. Sempre que poss\u00edvel, utilizo atualiza\u00e7\u00f5es online com bloqueios m\u00ednimos e limito as opera\u00e7\u00f5es de risco a janelas de manuten\u00e7\u00e3o. Monitorizo os bloqueios de metadados (MDL) e verifico se os eventos DDL nas r\u00e9plicas bloqueiam outras instru\u00e7\u00f5es devido a filtros ou \u00e0 ordem de execu\u00e7\u00e3o. Antes de grandes reestrutura\u00e7\u00f5es, fa\u00e7o uma rota\u00e7\u00e3o deliberada do binlog para ter um ponto de corte claro para c\u00f3pias de seguran\u00e7a ou revers\u00f5es. Para auditorias, separo as an\u00e1lises de DDL e DML, uma vez que as altera\u00e7\u00f5es de esquema s\u00e3o frequentemente a causa de dados aparentemente \u201eem falta\u201c, que, na realidade, apenas foram migrados para novas estruturas.<\/p>\n\n<h2>Ajustar com precis\u00e3o o Row-Image, as caches e os requisitos de mem\u00f3ria<\/h2>\n<p>No modo Row, limito o volume com <strong>binlog_row_image<\/strong> (dependendo da vers\u00e3o, FULL ou MINIMAL). A vers\u00e3o MINIMAL omite as colunas inalteradas e poupa bastante espa\u00e7o, sem comprometer a replica\u00e7\u00e3o. Al\u00e9m disso, calibro <strong>binlog_cache_size<\/strong> e o tamanho m\u00e1ximo da cache, para que as transa\u00e7\u00f5es de grande dimens\u00e3o tenham de recorrer ao disco com menos frequ\u00eancia. Acompanho m\u00e9tricas como os \u00abhits\u00bb e os \u00abspills\u00bb da cache do binlog para ajustar os valores de forma realista. No caso de campos BLOB\/TEXT de grande dimens\u00e3o, planeio cuidadosamente as mem\u00f3rias-puffer e a rede e verifico se existe um caminho de instru\u00e7\u00f5es adequado para importa\u00e7\u00f5es em massa, de modo a manter o binlog num tamanho razo\u00e1vel.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o, alarmes e manuais de procedimentos<\/h2>\n<p>Para o funcionamento cont\u00ednuo, preciso de sinais claros: estou a monitorizar o valor atual <strong>Posi\u00e7\u00e3o no binlog<\/strong>, <strong>Bytes gravados<\/strong>, o n\u00famero de ficheiros abertos, o tempo restante local at\u00e9 \u00e0 <strong>Expira\u00e7\u00e3o<\/strong>\u2011limiar, bem como indicadores de replica\u00e7\u00e3o, tais como <strong>Seconds_Behind<\/strong> e c\u00f3digos de erro do Applier. Quando os backlogs nas r\u00e9plicas aumentam, verifico primeiro a rede, depois a E\/S e, por \u00faltimo, os threads do Applier. Nos runbooks, registo: como efetuar uma rota\u00e7\u00e3o corretamente, o que verificar antes de uma purga (SHOW SLAVE\/REPLICA STATUS), como reiniciar uma r\u00e9plica (c\u00f3pia de seguran\u00e7a + posi\u00e7\u00e3o inicial\/GTID) e como, em caso de emerg\u00eancia, importar os binlogs com precis\u00e3o at\u00e9 ao timestamp desejado. Estas listas de verifica\u00e7\u00e3o poupam minutos preciosos em situa\u00e7\u00f5es de stress.<\/p>\n\n<h2>Estrutura da mem\u00f3ria, sistema de ficheiros e funcionamento<\/h2>\n<p>Os binlogs competem, em termos de E\/S, com os registos de dados e os registos de redo. Por isso, separo-os num volume pr\u00f3prio, avalio o desempenho em picos de tr\u00e1fego e ativo barreiras de escrita adequadas ao sistema de ficheiros. Em NVMe, a taxa de transfer\u00eancia escala bem com janelas de Group Commit maiores; no armazenamento em rede, limito os fluxos paralelos para evitar picos de lat\u00eancia. Mantenho o tamanho do ficheiro por binlog moderado, para que a purga e as transfer\u00eancias n\u00e3o demorem demasiado tempo, e verifico regularmente a consist\u00eancia do \u00edndice. Ao aplicar patches ou atualiza\u00e7\u00f5es, fa\u00e7o a rota\u00e7\u00e3o antecipadamente, fa\u00e7o uma c\u00f3pia de seguran\u00e7a do \u00edndice e garanto que os agentes de monitoriza\u00e7\u00e3o e de c\u00f3pia de seguran\u00e7a registam corretamente o novo registo.<\/p>\n\n<h2>Compatibilidade e atualiza\u00e7\u00e3o de vers\u00e3o<\/h2>\n<p>Nem todas as vers\u00f5es utilizam exatamente o mesmo \u201evocabul\u00e1rio\u201c do Binlog. Antes das atualiza\u00e7\u00f5es, verifico se as r\u00e9plicas de gera\u00e7\u00f5es anteriores conseguem ler o conjunto de eventos ou se \u00e9 necess\u00e1rio atualizar primeiro as r\u00e9plicas e s\u00f3 depois o servidor prim\u00e1rio. Tamb\u00e9m existem diferen\u00e7as nos nomes dos par\u00e2metros: dependendo da vers\u00e3o, encontro, por exemplo, <strong>binlog_group_commit_sync_delay<\/strong> ou par\u00e2metros de espera equivalentes (<em>binlog_commit_wait_*<\/em>), bem como valores predefinidos ligeiramente diferentes para as somas de verifica\u00e7\u00e3o ou para o Row\u2011Image. Por isso, pretendo elaborar uma matriz de compatibilidade e testar o failover e o PITR com binlogs reais do ambiente de produ\u00e7\u00e3o. Ao introduzir os binlogs baseados em InnoDB, verificarei tamb\u00e9m como as ferramentas de recupera\u00e7\u00e3o e os backups lidam com este formato e terei uma op\u00e7\u00e3o de recurso dispon\u00edvel para a transi\u00e7\u00e3o.<\/p>\n\n<h2>Padr\u00f5es de erro da pr\u00e1tica e solu\u00e7\u00f5es r\u00e1pidas<\/h2>\n<p>Um obst\u00e1culo frequente s\u00e3o os filtros de replica\u00e7\u00e3o desatualizados, que, ap\u00f3s altera\u00e7\u00f5es no esquema, passam subitamente a excluir tabelas inteiras. Por isso, verifico os filtros ap\u00f3s cada lan\u00e7amento. Um segundo padr\u00e3o: atrasos na replica\u00e7\u00e3o devido a caches de binlog demasiado pequenas em transa\u00e7\u00f5es de grande dimens\u00e3o \u2013 neste caso, ajuda aumentar o tamanho das caches ou dividir a transa\u00e7\u00e3o. Em terceiro lugar: binlogs inesperadamente grandes ap\u00f3s a ativa\u00e7\u00e3o de gatilhos; no modo de linha, aumento frequentemente a efici\u00eancia com a imagem de linha MINIMAL e defino janelas de manuten\u00e7\u00e3o dedicadas para altera\u00e7\u00f5es em massa. E quando os commits variam, comparo a pol\u00edtica de sincroniza\u00e7\u00e3o (sync_binlog, innodb_flush_log_at_trx_commit) com a frequ\u00eancia real de flush em produ\u00e7\u00e3o.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Os binlogs organizam as altera\u00e7\u00f5es, permitem a replica\u00e7\u00e3o e garantem a capacidade de recupera\u00e7\u00e3o; estes <strong>Fun\u00e7\u00e3o<\/strong> torna-a na alavanca de controlo central no MariaDB. Escolho o formato de acordo com a carga de trabalho, mantenho o Group Commit sob vigil\u00e2ncia e ajusto as estrat\u00e9gias de flush com bom senso. Para a recupera\u00e7\u00e3o, combino c\u00f3pias de seguran\u00e7a completas e binlogs e mantenho a reten\u00e7\u00e3o de dados sem lacunas. Planeio a replica\u00e7\u00e3o de forma clara, monitorizo o atraso e ajusto os filtros antes que surjam situa\u00e7\u00f5es de press\u00e3o. Quem interiorizar a configura\u00e7\u00e3o, a implementa\u00e7\u00e3o e os fatores de otimiza\u00e7\u00e3o de desempenho opera o MariaDB de forma mais fi\u00e1vel e com uma vis\u00e3o mais clara dos riscos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Os registos bin\u00e1rios do MariaDB explicados: estrutura, utiliza\u00e7\u00e3o, replica\u00e7\u00e3o e desempenho resumidos de forma compreens\u00edvel.<\/p>","protected":false},"author":1,"featured_media":21292,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21299","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":"28","_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 Binary Logs","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":"21292","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21299","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=21299"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21299\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21292"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}