{"id":18104,"date":"2026-03-05T11:50:25","date_gmt":"2026-03-05T10:50:25","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-replikation-hosting-master-slave-multi-master-syncio\/"},"modified":"2026-03-05T11:50:25","modified_gmt":"2026-03-05T10:50:25","slug":"replicacao-de-bases-de-dados-alojamento-mestre-escravo-multi-mestre-syncio","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/datenbank-replikation-hosting-master-slave-multi-master-syncio\/","title":{"rendered":"Replica\u00e7\u00e3o de bases de dados em alojamento: master-slave vs. multi-master"},"content":{"rendered":"<p><strong>Replica\u00e7\u00e3o da base de dados<\/strong> No alojamento, determina a forma como as aplica\u00e7\u00f5es permanecem dispon\u00edveis quando a carga aumenta e a rapidez com que podem escrever e ler novamente ap\u00f3s interrup\u00e7\u00f5es. Mostro claramente a diferen\u00e7a entre master-slave e multi-master, incluindo afina\u00e7\u00e3o, estrat\u00e9gias de failover e cen\u00e1rios de implementa\u00e7\u00e3o adequados.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Os seguintes aspectos fundamentais ajudam-me a escolher a estrat\u00e9gia de replica\u00e7\u00e3o correta.<\/p>\n<ul>\n  <li><strong>Mestre-Escravo<\/strong>Escritas simples, leituras escal\u00e1veis, responsabilidades claras.<\/li>\n  <li><strong>Multi-Mestre<\/strong>Escritas distribu\u00eddas, maior disponibilidade, mas gest\u00e3o de conflitos.<\/li>\n  <li><strong>GTIDs<\/strong> &amp; Failover: Trocas mais r\u00e1pidas e caminhos de replica\u00e7\u00e3o mais limpos.<\/li>\n  <li><strong>Realidade do alojamento<\/strong>A lat\u00eancia, o armazenamento e a rede influenciam a consist\u00eancia.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> &amp; Tuning: M\u00e9tricas, tempos de recupera\u00e7\u00e3o e defini\u00e7\u00f5es de binlog num relance.<\/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\/03\/server-replication-setup-4921.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que a replica\u00e7\u00e3o faz no alojamento<\/h2>\n\n<p>Utilizo a replica\u00e7\u00e3o para <strong>Disponibilidade<\/strong> para aumentar o desempenho de leitura, distribuir cargas de leitura e permitir janelas de manuten\u00e7\u00e3o sem falhas. As topologias mestre-escravo tratam as escritas de forma centralizada, enquanto as r\u00e9plicas m\u00faltiplas servem massas de leituras, reduzindo assim os tempos de resposta. As variantes multi-mestre permitem grava\u00e7\u00f5es distribu\u00eddas, o que reduz as lat\u00eancias em configura\u00e7\u00f5es globais e facilita a gest\u00e3o da perda de um n\u00f3. Para pilhas Web do WordPress, motores de loja ou APIs, isto significa mais armazenamento em buffer contra picos de tr\u00e1fego e recupera\u00e7\u00e3o mais r\u00e1pida ap\u00f3s incidentes. Se estiver a planear um crescimento horizontal para al\u00e9m da replica\u00e7\u00e3o pura, ligue-o passo a passo com <a href=\"https:\/\/webhosting.de\/pt\/banco-de-dados-fragmentacao-replicacao-hospedagem-web-infraestrutura-escalavel\/\">Sharding e replica\u00e7\u00e3o<\/a>, para distribuir os dados e a carga mais amplamente e <strong>Escalonamento<\/strong> para que seja poss\u00edvel planear.<\/p>\n\n<h2>Master-slave: funcionalidade e pontos fortes<\/h2>\n\n<p>Numa configura\u00e7\u00e3o mestre-escravo, escrevo consistentemente apenas para o <strong>Mestre<\/strong>, enquanto os escravos assumem o acesso de leitura e seguem os binlogs. A atribui\u00e7\u00e3o clara de fun\u00e7\u00f5es evita conflitos de escrita e mant\u00e9m o modelo claro. Isto \u00e9 perfeito para muitos cen\u00e1rios de alojamento com uma elevada propor\u00e7\u00e3o de leituras, tais como cat\u00e1logos de produtos, portais de conte\u00fados ou pain\u00e9is de relat\u00f3rios. Adiciono mais escravos conforme necess\u00e1rio, sem alterar o caminho de escrita. Planeio buffers para atrasos de replica\u00e7\u00e3o para que os relat\u00f3rios ou caches possam ser sincronizados apesar de pequenos atrasos. <strong>Resultados<\/strong> entregar.<\/p>\n\n<h2>MySQL Master-Slave passo a passo<\/h2>\n\n<p>Come\u00e7o no master com registo bin\u00e1rio e um \u00fanico <strong>ID do servidor<\/strong>, para que os escravos possam seguir o exemplo: No my.cnf eu defini <code>server-id=1<\/code>, <code>log_bin=mysql-bin<\/code>, opcional <code>binlog_do_db<\/code> para a replica\u00e7\u00e3o filtrada. Em seguida, crio um utilizador de replica\u00e7\u00e3o dedicado e limito os seus direitos ao m\u00ednimo necess\u00e1rio. Para a sincroniza\u00e7\u00e3o inicial, crio uma descarga com <code>-- dados-mestre<\/code>, Importo isto para o escravo e memorizo o ficheiro de registo e a posi\u00e7\u00e3o. No slave, defino <code>server-id=2<\/code>, ativar os registos do rel\u00e9 e lig\u00e1-lo a <code>ALTERAR MESTRE PARA ...<\/code>seguido de <code>INICIAR ESCRAVO<\/code>. Com <code>SHOW SLAVE STATUS\\G<\/code> Penso que <strong>Segundos Atr\u00e1s do Mestre<\/strong> e reagir se o atraso aumentar.<\/p>\n\n<h2>Optimiza\u00e7\u00f5es para ambientes de alojamento<\/h2>\n\n<p>Para uma ativa\u00e7\u00e3o p\u00f3s-falha limpa, ativo <strong>GTIDs<\/strong> e, assim, simplificar a comuta\u00e7\u00e3o sem o tedioso reajustamento das posi\u00e7\u00f5es de registo. Encaminho as leituras especificamente atrav\u00e9s de camadas proxy, como o ProxySQL ou a l\u00f3gica da aplica\u00e7\u00e3o, a fim de evitar pontos de acesso e aumentar a taxa de acerto da cache. Com <code>sync_binlog=1<\/code> I protege os binlogs contra falhas, enquanto valores moderados para <code>registo de sincroniza\u00e7\u00e3o<\/code> Reduzir a sobrecarga de escrita sem deixar que o atraso fique fora de controlo. Presto aten\u00e7\u00e3o \u00e0s capacidades de E\/S, porque os SSDs lentos ou os conjuntos de armazenamento partilhado aumentam o atraso. Para auditorias e conformidade, encripto os canais de replica\u00e7\u00e3o com <strong>TLS<\/strong> e manter as chaves separadas do caminho dos dados.<\/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\/03\/db_replikation_meeting_8394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-Master: Quando faz sentido<\/h2>\n\n<p>Utilizo o Multi-Master quando preciso de distribuir as grava\u00e7\u00f5es geograficamente ou quando um \u00fanico <strong>N\u00f3<\/strong> j\u00e1 n\u00e3o pode suportar uma carga de escrita. Todos os n\u00f3s aceitam as altera\u00e7\u00f5es, propagam-nas reciprocamente e, assim, compensam mais facilmente as falhas. O pre\u00e7o \u00e9 a gest\u00e3o de conflitos: as actualiza\u00e7\u00f5es simult\u00e2neas da mesma linha requerem regras, como a vit\u00f3ria do \u00faltimo escritor, fus\u00f5es do lado da aplica\u00e7\u00e3o ou sequ\u00eancias transaccionais. Em cargas de trabalho sens\u00edveis \u00e0 lat\u00eancia, como gateways de pagamento ou backends SaaS globais, a configura\u00e7\u00e3o pode reduzir significativamente os tempos de resposta. Eu avalio antecipadamente se a minha aplica\u00e7\u00e3o tolera conflitos e se tenho uma clara <strong>Estrat\u00e9gias<\/strong> para resolu\u00e7\u00e3o.<\/p>\n\n<h2>MySQL Multi-Master na pr\u00e1tica<\/h2>\n\n<p>Confio na replica\u00e7\u00e3o baseada em GTID porque simplifica os canais e a transfer\u00eancia em caso de falha e <strong>Erro<\/strong> torn\u00e1-los vis\u00edveis mais rapidamente. A replica\u00e7\u00e3o multi-fonte permite-me alimentar v\u00e1rios mestres num n\u00f3, por exemplo, para an\u00e1lises centrais ou agrega\u00e7\u00e3o. Para topologias de pares reais, defino estrat\u00e9gias de chave de baixo conflito, verifico os desvios de auto-incremento e reduzo os carimbos de data\/hora \u00e0 deriva. Monitorizo os picos de lat\u00eancia, uma vez que as escritas paralelas entre regi\u00f5es aumentam o esfor\u00e7o de coordena\u00e7\u00e3o e podem custar o rendimento. Sem uma monitoriza\u00e7\u00e3o adequada e regras de operador claras, n\u00e3o utilizaria o multi-master de forma produtiva. <strong>Interruptor<\/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\/03\/database-replication-contrast-6743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tabela de compara\u00e7\u00e3o: Mestre-escravo vs. multi-mestre<\/h2>\n\n<p>O quadro seguinte resume as diferen\u00e7as mais importantes e facilita-me a tarefa de <strong>Decis\u00e3o<\/strong> no alojamento quotidiano.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Crit\u00e9rio<\/th>\n      <th>Mestre-Escravo<\/th>\n      <th>Multi-Mestre<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Escreve<\/td>\n      <td>Um mestre processa todos os <strong>Opera\u00e7\u00f5es de escrita<\/strong><\/td>\n      <td>Todos os n\u00f3s aceitam escritas<\/td>\n    <\/tr>\n    <tr>\n      <td>Consist\u00eancia<\/td>\n      <td>Rigoroso, conflitos improv\u00e1veis<\/td>\n      <td>Mais suave, conflitos poss\u00edveis<\/td>\n    <\/tr>\n    <tr>\n      <td>Escalonamento<\/td>\n      <td>L\u00ea muito bem e \u00e9 expans\u00edvel<\/td>\n      <td>L\u00ea e escreve ficheiros expans\u00edveis<\/td>\n    <\/tr>\n    <tr>\n      <td>Esfor\u00e7o de instala\u00e7\u00e3o<\/td>\n      <td>Manej\u00e1vel e f\u00e1cil de controlar<\/td>\n      <td>Mais esfor\u00e7o e mais regras<\/td>\n    <\/tr>\n    <tr>\n      <td>Casos de utiliza\u00e7\u00e3o t\u00edpicos<\/td>\n      <td>Blogues, lojas, relat\u00f3rios<\/td>\n      <td>Aplica\u00e7\u00f5es globais, APIs cr\u00edticas em termos de lat\u00eancia<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Alta disponibilidade, RTO\/RPO e seguran\u00e7a<\/h2>\n\n<p>Eu defino claro <strong>RTO\/RPO<\/strong>-alvos e alinhar a replica\u00e7\u00e3o com eles: Quanto tempo pode demorar a recupera\u00e7\u00e3o, quantos dados posso perder. A replica\u00e7\u00e3o s\u00edncrona ou semi-s\u00edncrona pode reduzir as perdas, mas custa lat\u00eancia e d\u00e9bito. As c\u00f3pias de seguran\u00e7a n\u00e3o substituem a replica\u00e7\u00e3o, mas complementam-na para a recupera\u00e7\u00e3o pontual e os estados hist\u00f3ricos. Verifico regularmente os testes de restauro, porque s\u00f3 uma c\u00f3pia de seguran\u00e7a testada conta na pr\u00e1tica. Para um planeamento adequado, consulte o meu guia para <a href=\"https:\/\/webhosting.de\/pt\/rto-rpo-recovery-times-hosting-serverbackup\/\">RTO\/RPO no alojamento<\/a>, de modo a que os \u00edndices correspondam \u00e0 realidade operacional e a <strong>Riscos<\/strong> apto.<\/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\/03\/datenbank_replikation_4123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Caminho de escalonamento: de um \u00fanico n\u00f3 a um cluster<\/h2>\n\n<p>Muitas vezes come\u00e7o com um \u00fanico <strong>Mestre<\/strong>, Adiciono uma r\u00e9plica para leituras e backups e depois aumento a escala passo a passo. \u00c0 medida que a quota de leitura aumenta, adiciono escravos adicionais e completo a configura\u00e7\u00e3o com caching. Se a capacidade de escrita j\u00e1 n\u00e3o for suficiente, planeio caminhos para v\u00e1rios mestres, verifico os riscos de conflito e adiciono idempot\u00eancia \u00e0 aplica\u00e7\u00e3o. Para convers\u00f5es maiores, migro com estrat\u00e9gias cont\u00ednuas, fases de escrita azul\/verde ou dupla e mantenho reservas prontas para revers\u00f5es. Para convers\u00f5es sem tempo de inatividade, utilizo o guia para <a href=\"https:\/\/webhosting.de\/pt\/migracao-de-alojamento-sem-tempo-de-inatividade-instrucoes\/\">Migra\u00e7\u00f5es sem tempo de inatividade<\/a>, para que os utilizadores n\u00e3o <strong>Interrup\u00e7\u00f5es<\/strong> sentir.<\/p>\n\n<h2>Afina\u00e7\u00e3o do desempenho: lat\u00eancia, E\/S e armazenamento em cache<\/h2>\n\n<p>Monitorizo a lat\u00eancia na rede, o IOPS no armazenamento e os picos de CPU no <strong>N\u00f3<\/strong>, porque todos os tr\u00eas factores controlam o atraso da replica\u00e7\u00e3o. Uma camada local de Redis ou Memcached faz leituras da pilha e mant\u00e9m os slaves descarregados. Eu divido grandes transa\u00e7\u00f5es para evitar inunda\u00e7\u00f5es de binlogs e reduzir congestionamentos de commit. Para cargas de trabalho de escrita pesada, eu aumento moderadamente os buffers de log innodb e regulo os intervalos de descarga sem prejudicar a durabilidade. Eu mantenho os planos de consulta limpos, porque \u00edndices ruins causam erros caros tanto nos mestres quanto nos escravos. <strong>Digitaliza\u00e7\u00f5es<\/strong>.<\/p>\n\n<h2>Preven\u00e7\u00e3o e resolu\u00e7\u00e3o de conflitos em Multi-Master<\/h2>\n\n<p>Evito conflitos separando logicamente as \u00e1reas de escrita, por exemplo <strong>Cliente<\/strong>, regi\u00e3o ou espa\u00e7o-chave. Os offsets de auto-incremento (por exemplo, 1\/2\/3 para tr\u00eas n\u00f3s) evitam colis\u00f5es com chaves prim\u00e1rias. Quando as actualiza\u00e7\u00f5es simult\u00e2neas s\u00e3o inevit\u00e1veis, documentei regras claras, por exemplo, o \u00faltimo a escrever ganha ou as fus\u00f5es do lado da aplica\u00e7\u00e3o. As escritas idempotentes e a desduplica\u00e7\u00e3o de consumidores protegem contra o processamento duplicado. Tamb\u00e9m registo informa\u00e7\u00f5es de auditoria para que as decis\u00f5es possam ser tomadas rapidamente em caso de lit\u00edgio. <strong>compreender<\/strong> ser capaz de o fazer.<\/p>\n\n<h2>Resolu\u00e7\u00e3o de problemas: O que devo verificar primeiro<\/h2>\n\n<p>Em caso de atraso, verifico <strong>Segundos Atr\u00e1s do Mestre<\/strong>, os threads de E\/S e SQL, bem como os tamanhos dos registos de retransmiss\u00e3o. Eu olho para os tamanhos e formatos dos binlogs porque STATEMENT vs. ROW pode alterar enormemente o volume. As m\u00e9tricas de armazenamento, como tempos de descarga e filas de espera, mostram se os SSDs est\u00e3o a atingir o m\u00e1ximo ou a estrangular-se. Se os GTIDs estiverem activos, comparo as transac\u00e7\u00f5es aplicadas e em falta por canal. Em caso de emerg\u00eancia, paro e inicio o replicador especificamente para resolver bloqueios e s\u00f3 depois corrijo o <strong>Configura\u00e7\u00e3o<\/strong>.<\/p>\n\n<h2>Modelos de consist\u00eancia e leitura ap\u00f3s escrita<\/h2>\n<p>Com a replica\u00e7\u00e3o ass\u00edncrona, planeio conscientemente <strong>consist\u00eancia final<\/strong> sobre. Para as ac\u00e7\u00f5es dos utilizadores com feedback direto, asseguro <em>Leitura ap\u00f3s escrita<\/em>, ligando as sess\u00f5es de escrita ao master durante um curto per\u00edodo de tempo ou encaminhando as leituras de uma forma consciente do atraso. Utilizo sinalizadores de aplica\u00e7\u00e3o (por exemplo, \u201estickiness\u201c durante 2-5 segundos) e verifico <code>Segundos Atr\u00e1s do Mestre<\/code>, antes de autorizar uma r\u00e9plica para leituras cr\u00edticas. Eu confio nas r\u00e9plicas <code>read_only=ON<\/code> e <code>super_read_only=ON<\/code>, para que nenhuma escrita acidental passe. Com n\u00edveis de isolamento corretamente selecionados (<code>REPEATABLE READ<\/code> vs. <code>READ COMMITTED<\/code>) Evito que as transac\u00e7\u00f5es longas tornem a thread Apply mais lenta.<\/p>\n\n<h2>Topologias: estrela, cascata e fan-out<\/h2>\n<p>Para al\u00e9m da estrela cl\u00e1ssica (todos os escravos puxam diretamente do mestre), eu utilizo <strong>Replica\u00e7\u00e3o em cascata<\/strong>, se forem necess\u00e1rias muitas r\u00e9plicas ou se as liga\u00e7\u00f5es WAN forem limitadas. Para tal, activei o seguinte nos n\u00f3s interm\u00e9dios <code>log_slave_updates=ON<\/code>, para que sirvam de fonte para as r\u00e9plicas a jusante. Isto alivia a carga na E\/S principal e distribui melhor a largura de banda. Presto aten\u00e7\u00e3o aos n\u00edveis de lat\u00eancia adicionais: Cada cascata aumenta potencialmente o atraso e requer uma monitoriza\u00e7\u00e3o atenta. Para configura\u00e7\u00f5es globais, combino hubs regionais com dist\u00e2ncias curtas e mantenho pelo menos duas r\u00e9plicas por regi\u00e3o para manuten\u00e7\u00e3o e <strong>Transfer\u00eancia em caso de falha<\/strong> pronto.<\/p>\n\n<h2>Failover planeado e n\u00e3o planeado<\/h2>\n<p>Eu documentei uma clara <strong>Processo de promo\u00e7\u00e3o<\/strong>1) Parar as escritas no mestre ou mudar o fluxo de tr\u00e1fego para apenas leitura, 2) Selecionar a r\u00e9plica candidata (menor atraso, GTIDs completos), 3) Promover a r\u00e9plica e <code>s\u00f3 de leitura<\/code> desativar, 4) realinhar os restantes n\u00f3s. Contra <em>C\u00e9rebro dividido<\/em> Protejo-me com um encaminhamento claro (por exemplo, comuta\u00e7\u00e3o VIP\/DNS com TTLs curtos) e bloqueio autom\u00e1tico. As ferramentas de orquestra\u00e7\u00e3o ajudam, mas pratico regularmente caminhos manuais. Mantenho livros de execu\u00e7\u00e3o, alarmes e <strong>Brocas<\/strong> para que ningu\u00e9m tenha de improvisar numa emerg\u00eancia.<\/p>\n\n<h2>Os GTID na pr\u00e1tica: obst\u00e1culos e solu\u00e7\u00f5es<\/h2>\n<p>Para GTIDs, ativo <code>enforce_gtid_consistency=ON<\/code> e <code>gtid_mode=ON<\/code> passo a passo. Eu uso <em>posi\u00e7\u00e3o autom\u00e1tica<\/em>, para simplificar as altera\u00e7\u00f5es de origem e evitar filtros de replica\u00e7\u00e3o nas rotas GTID, uma vez que tornam a depura\u00e7\u00e3o mais dif\u00edcil. Etapa <strong>transac\u00e7\u00f5es erradas<\/strong> (transac\u00e7\u00f5es que existem numa r\u00e9plica mas n\u00e3o na fonte), identifico-as atrav\u00e9s da diferen\u00e7a de <code>gtid_executed<\/code> e a fonte e limpo de forma controlada - n\u00e3o cegamente com purgas. Planeio a reten\u00e7\u00e3o do binlog de forma a que as reconstru\u00e7\u00f5es sejam poss\u00edveis sem lacunas e verifico a consist\u00eancia do <code>gtid_purged<\/code>.<\/p>\n\n<h2>Paraleliza\u00e7\u00e3o e taxa de transfer\u00eancia em r\u00e9plicas<\/h2>\n<p>Para reduzir o desfasamento da aplica\u00e7\u00e3o, aumento <code>r\u00e9plica_paralela_trabalhadores<\/code> de acordo com o n\u00famero de CPUs e selecionar <code>replica_parallel_type=LOGICAL_CLOCK<\/code>, para que as transac\u00e7\u00f5es relacionadas permane\u00e7am organizadas. Com <code>binlog_transaction_dependency_tracking=WRITESET<\/code> Aumento o paralelismo porque as escritas independentes podem ser aplicadas simultaneamente. Monitorizo os tempos de espera de bloqueios e bloqueios nas r\u00e9plicas: o paralelismo excessivo pode gerar actualiza\u00e7\u00f5es simult\u00e2neas. Al\u00e9m disso, ajuda <strong>Grupo Compromisso<\/strong> no mestre (atrasos de descarga associados) para agrupar as transac\u00e7\u00f5es relacionadas de forma mais eficiente - sem exceder o intervalo de lat\u00eancia P95.<\/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\/03\/datenbank_replication_hosting_5893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Altera\u00e7\u00f5es de esquema sem tempo de inatividade<\/h2>\n<p>Prefiro <strong>DDL online<\/strong> com InnoDB (<code>ALGORITMO=INPLACE\/INSTANT\u00c2NEO<\/code>, <code>LOCK=NENHUM<\/code>) para efetuar altera\u00e7\u00f5es na tabela atrav\u00e9s da replica\u00e7\u00e3o sem bloquear as consultas. Para tabelas muito grandes, escolho m\u00e9todos baseados em peda\u00e7os, \u00edndices divididos e mantenho-me atento \u00e0 carga do binlog. No caso de v\u00e1rios mestres, programo rigorosamente as janelas DDL, uma vez que as altera\u00e7\u00f5es simult\u00e2neas do esquema s\u00e3o dif\u00edceis de curar. Testo as DDL numa r\u00e9plica, me\u00e7o o seu impacto no atraso e s\u00f3 as promovo quando o caminho de replica\u00e7\u00e3o permanece est\u00e1vel.<\/p>\n\n<h2>A reprodu\u00e7\u00e3o diferida como rede de seguran\u00e7a<\/h2>\n<p>Contra erros l\u00f3gicos (DROP\/DELETE), considero uma <strong>r\u00e9plica diferida<\/strong> pronto, por exemplo, com <code>replica_sql_delay=3600<\/code>. Isto permite-me regressar a um estado limpo no espa\u00e7o de uma hora sem executar imediatamente o PITR a partir das c\u00f3pias de seguran\u00e7a. Eu nunca uso essa r\u00e9plica para leituras ou failovers - ela \u00e9 puramente um buffer de seguran\u00e7a. Automatizo as c\u00f3pias a partir deste n\u00f3 para poder obter rapidamente um n\u00f3 de leitura novo e atualizado em caso de emerg\u00eancia.<\/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\/03\/serverraum-replikation-8614.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Actualiza\u00e7\u00f5es, compatibilidade e funcionamento<\/h2>\n<p>Mantenho as vers\u00f5es de origem e de destino pr\u00f3ximas umas das outras e actualizo <strong>rolante<\/strong>primeiro as r\u00e9plicas, depois o master. Tenho uma vis\u00e3o cr\u00edtica dos ambientes mistos com MySQL\/MariaDB, uma vez que os formatos e funcionalidades do binlog podem divergir. Eu uso <code>binlog_row_image=MINIMAL<\/code> onde faz sentido reduzir o volume de binlogs e verificar as depend\u00eancias de aplicativos para gatilhos ou procedimentos armazenados. Reduzo a carga da WAN para compress\u00e3o de protocolos e binlogs, mas tomo cuidado para n\u00e3o gastar demais o or\u00e7amento da CPU.<\/p>\n\n<h2>Observabilidade e planeamento da capacidade<\/h2>\n<p>Eu defino SLOs para <strong>Desfasamento<\/strong>, tempos de recupera\u00e7\u00e3o, taxas de erro e rendimento. As principais vari\u00e1veis incluem transac\u00e7\u00f5es aplicadas por segundo, n\u00edveis de preenchimento de registos de rel\u00e9s, filas de E\/S, tempos de espera de bloqueios e lat\u00eancia da rede. Registo o crescimento do binlog, planeio <code>binlog_expire_logs_seconds<\/code> e verificar se as reconstru\u00e7\u00f5es permanecem dentro dos per\u00edodos de reten\u00e7\u00e3o. Defino limites para as r\u00e9plicas, tais como <code>max_conex\u00f5es<\/code> e monitorizo os cancelamentos para que os carregamentos de leitura n\u00e3o se transformem em nada. Relativamente aos custos e ao tamanho, calculo os n\u00edveis de fan-out, os requisitos de armazenamento e <strong>Cargas de pico<\/strong> em rela\u00e7\u00e3o aos objectivos RPO\/RTO.<\/p>\n\n<h2>Seguran\u00e7a e conformidade nas opera\u00e7\u00f5es de replica\u00e7\u00e3o<\/h2>\n\n<p>Liga\u00e7\u00f5es de veda\u00e7\u00e3o I <strong>de ponta a ponta<\/strong> e contas de operador, de aplica\u00e7\u00e3o e de replica\u00e7\u00e3o estritamente separadas. As auditorias regulares de direitos impedem que os utilizadores de replica\u00e7\u00e3o mantenham autoriza\u00e7\u00f5es DDL\/DML desnecess\u00e1rias. Protejo as c\u00f3pias de seguran\u00e7a externas com uma gest\u00e3o de chaves separada e verifico os caminhos de acesso contra movimentos laterais. Para prote\u00e7\u00e3o dos dados, cumpro as regras de elimina\u00e7\u00e3o e replico registos de dados pseudonimizados ou minimizados, se a finalidade o permitir. Partilho o registo e as m\u00e9tricas de acordo com o privil\u00e9gio m\u00ednimo, para que a telemetria n\u00e3o seja utilizada de forma descuidada. <strong>Fuga<\/strong> produzido.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Para cen\u00e1rios de alojamento, o Master-Slave fornece um <strong>Base<\/strong>, porque as leituras escalam facilmente e raramente ocorrem conflitos. Se as grava\u00e7\u00f5es globais, a baixa lat\u00eancia e a toler\u00e2ncia a falhas forem uma prioridade, considero a possibilidade de ter v\u00e1rios mestres e planeio regras para a resolu\u00e7\u00e3o de conflitos. Combino GTIDs, monitoriza\u00e7\u00e3o limpa e backups sofisticados para atingir com seguran\u00e7a os objectivos de recupera\u00e7\u00e3o. Ao ajustar o binlog, o armazenamento e os par\u00e2metros de consulta, reduzo o atraso e mantenho o rendimento elevado. Isto permite-me escolher a topologia certa, escalar de forma controlada e minimizar o tempo de inatividade para os utilizadores. <strong>invis\u00edvel<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Replica\u00e7\u00e3o de bases de dados em alojamento: **MySQL master slave** vs. multi-master para um **escalonamento perfeito da base de dados**. Configura\u00e7\u00e3o, vantagens e dicas.<\/p>","protected":false},"author":1,"featured_media":18097,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-18104","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":"836","_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":"Datenbank Replikation","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":"18097","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18104","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=18104"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18104\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18097"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}