{"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":"database-replikation-hosting-master-slave-multi-master-syncio","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/datenbank-replikation-hosting-master-slave-multi-master-syncio\/","title":{"rendered":"Databasereplikation i hosting: master-slave vs. multi-master"},"content":{"rendered":"<p><strong>Replikering af databaser<\/strong> I hosting afg\u00f8r det, hvor godt applikationer forbliver tilg\u00e6ngelige, n\u00e5r belastningen \u00f8ges, og hvor hurtigt de kan skrive og l\u00e6se igen efter afbrydelser. Jeg viser tydeligt forskellen mellem master-slave og multi-master, herunder tuning, failover-strategier og passende udrulningsscenarier.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>F\u00f8lgende n\u00f8gleaspekter hj\u00e6lper mig med at v\u00e6lge den rigtige replikationsstrategi.<\/p>\n<ul>\n  <li><strong>Herre-slave<\/strong>Enkel skrivning, skalerbar l\u00e6sning, klare ansvarsomr\u00e5der.<\/li>\n  <li><strong>Multi-Master<\/strong>Distribueret skrivning, h\u00f8jere tilg\u00e6ngelighed, men konflikth\u00e5ndtering.<\/li>\n  <li><strong>GTID'er<\/strong> &amp; Failover: Hurtigere skift og renere replikeringsstier.<\/li>\n  <li><strong>V\u00e6rt for virkeligheden<\/strong>Latency, storage og netv\u00e6rk p\u00e5virker konsistensen.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> &amp; Tuning: Metrikker, opsamlingstider og binlog-indstillinger p\u00e5 et \u00f8jeblik.<\/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>Hvad replikering g\u00f8r i hosting<\/h2>\n\n<p>Jeg bruger replikering til at <strong>Tilg\u00e6ngelighed<\/strong> for at \u00f8ge l\u00e6seydelsen, fordele l\u00e6sebelastningen og muligg\u00f8re vedligeholdelsesvinduer uden fejl. Master-slave-topologier centraliserer skrivninger, mens flere replikaer betjener masser af l\u00e6sninger og dermed reducerer svartiderne. Multi-master-varianter tillader distribueret skrivning, hvilket reducerer ventetider i globale ops\u00e6tninger og g\u00f8r det lettere at h\u00e5ndtere tab af en node. For webstakke fra WordPress, shop engines eller API'er betyder det mere buffering mod trafikspidser og hurtigere genopretning efter h\u00e6ndelser. Hvis du planl\u00e6gger horisontal v\u00e6kst ud over ren replikering, kan du linke det trin for trin med <a href=\"https:\/\/webhosting.de\/da\/database-sharding-replikation-webhosting-infrastruktur-skalerbar\/\">Sharding og replikering<\/a>, at distribuere data og belastning mere bredt og <strong>Skalering<\/strong> Forudsigelig.<\/p>\n\n<h2>Master-slave: funktionalitet og styrker<\/h2>\n\n<p>I en master-slave-ops\u00e6tning skriver jeg konsekvent kun til <strong>Mester<\/strong>, mens slaverne overtager l\u00e6seadgangen og f\u00f8lger binlogs. Den klare rollefordeling undg\u00e5r skrivekonflikter og holder modellen overskuelig. Det er perfekt til mange hostingscenarier med en h\u00f8j andel af l\u00e6sninger, f.eks. produktkataloger, indholdsportaler eller rapporteringsdashboards. Jeg tilf\u00f8jer flere slaver efter behov uden at \u00e6ndre skrivestien. Jeg planl\u00e6gger buffere til replikationsforsinkelser, s\u00e5 rapporter eller cacher kan synkroniseres p\u00e5 trods af korte forsinkelser. <strong>Resultater<\/strong> levere.<\/p>\n\n<h2>MySQL Master-Slave trin for trin<\/h2>\n\n<p>Jeg starter p\u00e5 masteren med bin\u00e6r logning og en unik <strong>server-id<\/strong>, s\u00e5 slaverne kan f\u00f8lge trop: I my.cnf s\u00e6tter jeg <code>server-id=1<\/code>, <code>log_bin=mysql-bin<\/code>, valgfrit <code>binlog_do_db<\/code> til filtreret replikering. Derefter opretter jeg en dedikeret replikationsbruger og begr\u00e6nser dens rettigheder til det absolutte minimum. Til den f\u00f8rste synkronisering opretter jeg et dump med <code>--master-data<\/code>, Jeg importerer dette til slaven og gemmer logfilen og positionen. P\u00e5 slaven definerer jeg <code>server-id=2<\/code>, Aktiv\u00e9r rel\u00e6loggen og forbind den til <code>\u00c6NDRE MASTER TIL ...<\/code>efterfulgt af <code>START SLAVE<\/code>. Med <code>VIS SLAVE STATUS\\G<\/code> Jeg tror <strong>Sekunder_bag_Master<\/strong> og reagere, hvis forsinkelsen \u00f8ges.<\/p>\n\n<h2>Optimeringer til hosting-milj\u00f8er<\/h2>\n\n<p>For ren failover aktiverer jeg <strong>GTID'er<\/strong> og dermed forenkle skift uden kedelig justering af logpositionerne. Jeg router l\u00e6sninger specifikt via proxylag som ProxySQL eller applikationslogikken for at undg\u00e5 hotspots og \u00f8ge cache-hitraten. Med <code>sync_binlog=1<\/code> Jeg sikrer binlogs mod nedbrud, mens moderate v\u00e6rdier for <code>sync_relay_log<\/code> Reducer skriveoverhead uden at lade forsinkelsen tage overh\u00e5nd. Jeg er opm\u00e6rksom p\u00e5 I\/O-kapaciteten, fordi langsomme SSD'er eller delte lagerpuljer \u00f8ger eftersl\u00e6bet. Af hensyn til revision og compliance krypterer jeg replikationskanaler med <strong>TLS<\/strong> og holde n\u00f8gler adskilt fra datastien.<\/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: N\u00e5r det giver mening<\/h2>\n\n<p>Jeg bruger Multi-Master, n\u00e5r jeg har brug for at fordele skrivninger geografisk, eller n\u00e5r en enkelt <strong>Knudepunkt<\/strong> ikke l\u00e6ngere kan b\u00e6re en skrivebelastning. Alle noder accepterer \u00e6ndringer, udbreder dem gensidigt og kompenserer dermed lettere for fejl. Prisen er konflikth\u00e5ndtering: Samtidige opdateringer af den samme linje kr\u00e6ver regler, som f.eks. last-writer wins, fletninger p\u00e5 applikationssiden eller transaktionssekvenser. I latency-f\u00f8lsomme workloads, som f.eks. betalingsgateways eller globale SaaS-backends, kan ops\u00e6tningen reducere svartiderne betydeligt. Jeg vurderer p\u00e5 forh\u00e5nd, om min applikation tolererer konflikter, og om jeg har klare <strong>Strategier<\/strong> til l\u00f8sning.<\/p>\n\n<h2>MySQL Multi-Master i praksis<\/h2>\n\n<p>Jeg er afh\u00e6ngig af GTID-baseret replikering, fordi det forenkler kanaler og failover og <strong>Fejl<\/strong> g\u00f8re dem synlige hurtigere. Replikering med flere kilder giver mig mulighed for at fodre flere mastere til \u00e9n node, f.eks. til centrale analyser eller aggregering. For \u00e6gte peer-topologier definerer jeg lavkonflikt-n\u00f8glestrategier, kontrollerer auto-increment-offsets og reducerer afvigende tidsstempler. Jeg overv\u00e5ger latenstidstoppe, fordi parallelle skrivninger p\u00e5 tv\u00e6rs af regioner \u00f8ger koordineringsindsatsen og kan koste gennemstr\u00f8mning. Uden ordentlig overv\u00e5gning og klare operat\u00f8rregler ville jeg ikke bruge multi-master produktivt. <strong>Skift<\/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>Sammenligningstabel: Master-slave vs. multi-master<\/h2>\n\n<p>Den f\u00f8lgende tabel opsummerer de vigtigste forskelle og g\u00f8r det lettere for mig at <strong>Beslutning<\/strong> i hverdagens hosting.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Kriterium<\/th>\n      <th>Herre-slave<\/th>\n      <th>Multi-Master<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Skriver<\/td>\n      <td>En master behandler alle <strong>Skriveoperationer<\/strong><\/td>\n      <td>Alle noder accepterer skrivninger<\/td>\n    <\/tr>\n    <tr>\n      <td>Konsistens<\/td>\n      <td>Strenge, konflikter usandsynlige<\/td>\n      <td>Bl\u00f8dere, konflikter mulige<\/td>\n    <\/tr>\n    <tr>\n      <td>Skalering<\/td>\n      <td>L\u00e6ser meget godt og kan udvides<\/td>\n      <td>L\u00e6ser og skriver udvideligt<\/td>\n    <\/tr>\n    <tr>\n      <td>Indsats for ops\u00e6tning<\/td>\n      <td>H\u00e5ndterbar og nem at kontrollere<\/td>\n      <td>St\u00f8rre indsats og flere regler<\/td>\n    <\/tr>\n    <tr>\n      <td>Typiske brugsscenarier<\/td>\n      <td>Blogs, butikker, rapportering<\/td>\n      <td>Globale apps, latency-kritiske API'er<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>H\u00f8j tilg\u00e6ngelighed, RTO\/RPO og sikkerhed<\/h2>\n\n<p>Jeg definerer klar <strong>RTO\/RPO<\/strong>-m\u00e5l og justere replikationen med dem: Hvor lang tid kan genoprettelsen tage, hvor meget data kan jeg miste. Synkron eller semisynkron replikering kan reducere tab, men koster latency og throughput. Sikkerhedskopier erstatter ikke replikering, de supplerer den med henblik p\u00e5 point-in-time recovery og historiske statusser. Jeg tjekker j\u00e6vnligt restore-tests, for kun en testet backup t\u00e6ller i praksis. For korrekt planl\u00e6gning henvises til min guide til <a href=\"https:\/\/webhosting.de\/da\/rto-rpo-recovery-times-hosting-serverbackup\/\">RTO\/RPO i hosting<\/a>, s\u00e5 n\u00f8gletallene stemmer overens med den operationelle virkelighed og <strong>Risici<\/strong> passer.<\/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>Skaleringssti: Fra enkelt node til klynge<\/h2>\n\n<p>Jeg starter ofte med en enkelt <strong>Mester<\/strong>, Jeg tilf\u00f8jer en replika til l\u00e6sninger og sikkerhedskopier og skalerer derefter op trin for trin. N\u00e5r l\u00e6seandelen vokser, tilf\u00f8jer jeg yderligere slaver og afrunder ops\u00e6tningen med caching. Hvis skrivekapaciteten ikke l\u00e6ngere er tilstr\u00e6kkelig, planl\u00e6gger jeg multi-master-stier, kontrollerer konfliktrisici og tilf\u00f8jer idempotens til applikationen. Ved st\u00f8rre konverteringer migrerer jeg med rullende strategier, bl\u00e5\/gr\u00f8nne eller dual-write-faser og holder reserver klar til rollbacks. Til konverteringer uden nedetid bruger jeg guiden til at <a href=\"https:\/\/webhosting.de\/da\/zero-downtime-hosting-migration-vejledning\/\">Migrationer uden nedetid<\/a>, s\u00e5 brugerne ikke <strong>Afbrydelser<\/strong> f\u00f8ler.<\/p>\n\n<h2>Performance-tuning: latenstid, I\/O og caching<\/h2>\n\n<p>Jeg overv\u00e5ger latency i netv\u00e6rket, IOPS p\u00e5 storage og CPU-peaks p\u00e5 computeren. <strong>Knudepunkt<\/strong>, fordi alle tre faktorer styrer replikationsforsinkelsen. Et lokalt Redis- eller Memcached-lag tager l\u00e6sninger fra stakken og holder slaverne ubelastede. Jeg opdeler store transaktioner for at undg\u00e5 binlog-oversv\u00f8mmelser og reducere commit-jams. Til skrivetunge arbejdsbelastninger \u00f8ger jeg innodb-logbufferne moderat og regulerer flush-intervaller uden at underminere holdbarheden. Jeg holder foresp\u00f8rgselsplaner rene, fordi d\u00e5rlige indekser for\u00e5rsager dyre fejl p\u00e5 b\u00e5de mastere og slaver. <strong>Scanninger<\/strong>.<\/p>\n\n<h2>Undg\u00e5else og l\u00f8sning af konflikter i Multi-Master<\/h2>\n\n<p>Jeg undg\u00e5r konflikter ved at adskille skriveomr\u00e5der logisk, for eksempel ved at <strong>Kunde<\/strong>, region eller n\u00f8glerum. Auto-increment offsets (f.eks. 1\/2\/3 for tre noder) forhindrer kollisioner med prim\u00e6rn\u00f8gler. Hvor samtidige opdateringer er uundg\u00e5elige, dokumenterer jeg klare regler, f.eks. at den, der skriver sidst, vinder, eller at fusioner sker p\u00e5 applikationssiden. Idempotente skrivninger og deduplikerende forbrugere beskytter mod dobbeltbehandling. Jeg registrerer ogs\u00e5 revisionsoplysninger, s\u00e5 der hurtigt kan tr\u00e6ffes beslutninger i tilf\u00e6lde af en tvist. <strong>forst\u00e5<\/strong> for at v\u00e6re i stand til det.<\/p>\n\n<h2>Fejlfinding: Hvad jeg tjekker f\u00f8rst<\/h2>\n\n<p>I tilf\u00e6lde af forsinkelse tjekker jeg <strong>Sekunder_bag_Master<\/strong>, I\/O- og SQL-tr\u00e5dene samt rel\u00e6-logst\u00f8rrelser. Jeg ser p\u00e5 binlog-st\u00f8rrelser og -formater, fordi STATEMENT vs ROW kan \u00e6ndre volumen massivt. Storage-metrikker som flush-tider og k\u00f8er viser, om SSD'er er ved at n\u00e5 deres maksimum eller er ved at drosle ned. Hvis GTID'er er aktive, sammenligner jeg anvendte og manglende transaktioner pr. kanal. I en n\u00f8dsituation stopper og starter jeg replikatoren specifikt for at l\u00f8se blokeringer og f\u00f8rst derefter rette op p\u00e5 <strong>Konfiguration<\/strong>.<\/p>\n\n<h2>Konsistensmodeller og l\u00e6sning efter skrivning<\/h2>\n<p>Med asynkron replikering planl\u00e6gger jeg bevidst <strong>endelig konsistens<\/strong> p\u00e5. For brugerhandlinger med direkte feedback sikrer jeg <em>L\u00e6s-efter-skriv<\/em>, ved at binde skrivesessioner til masteren i kort tid eller dirigere l\u00e6sninger p\u00e5 en forsinkelsesbevidst m\u00e5de. Jeg bruger applikationsflag (f.eks. \u201estickiness\u201c i 2-5 sekunder) og tjekker <code>Sekunder_bag_Master<\/code>, f\u00f8r jeg tillader en replika til kritiske l\u00e6sninger. Jeg er afh\u00e6ngig af replikaer <code>read_only=ON<\/code> og <code>super_read_only=ON<\/code>, s\u00e5 ingen utilsigtede skrivninger slipper igennem. Med korrekt valgte isolationsniveauer (<code>GENTAGELIG L\u00c6SNING<\/code> vs. <code>L\u00c6S BEKR\u00c6FTET<\/code>) Jeg forhindrer lange transaktioner i at bremse Apply-tr\u00e5den.<\/p>\n\n<h2>Topologier: stjerne, kaskade og fan-out<\/h2>\n<p>Ud over den klassiske stjerne (alle slaver tr\u00e6kker direkte fra masteren) er jeg afh\u00e6ngig af <strong>Kaskade-replikation<\/strong>, hvis der er brug for mange replikaer, eller hvis WAN-linkene er begr\u00e6nsede. For at g\u00f8re dette aktiverer jeg f\u00f8lgende p\u00e5 mellemliggende noder <code>log_slave_updates=ON<\/code>, s\u00e5 de fungerer som kilde for downstream-replikater. Det aflaster belastningen p\u00e5 master-I\/O og fordeler b\u00e5ndbredden bedre. Jeg er opm\u00e6rksom p\u00e5 yderligere latensniveauer: Hver kaskade \u00f8ger potentielt forsinkelsen og kr\u00e6ver t\u00e6t overv\u00e5gning. Til globale ops\u00e6tninger kombinerer jeg regionale hubs med korte afstande og beholder mindst to replikaer pr. region til vedligeholdelse og <strong>Failover<\/strong> klar.<\/p>\n\n<h2>Planlagt og uplanlagt failover<\/h2>\n<p>Jeg dokumenterer en klar <strong>Forfremmelsesproces<\/strong>1) Stop skrivninger p\u00e5 masteren eller skift trafikflow til skrivebeskyttet, 2) V\u00e6lg kandidatreplika (laveste forsinkelse, komplette GTID'er), 3) Forfrem replika og <code>skrivebeskyttet<\/code> deaktivere, 4) justere de resterende knudepunkter. Mod <em>Split-hjerne<\/em> Jeg beskytter mig selv med klar routing (f.eks. VIP\/DNS-switching med korte TTL'er) og automatisk blokering. Orkestreringsv\u00e6rkt\u00f8jer hj\u00e6lper, men jeg praktiserer regelm\u00e6ssigt manuelle stier. Jeg har runbooks, alarmer og <strong>\u00d8velser<\/strong> klar, s\u00e5 ingen beh\u00f8ver at improvisere i en n\u00f8dsituation.<\/p>\n\n<h2>GTID'er i praksis: snublesten og helbredelse<\/h2>\n<p>For GTID'er aktiverer jeg <code>enforce_gtid_consistency=ON<\/code> og <code>gtid_mode=ON<\/code> trin for trin. Jeg bruger <em>Auto-position<\/em>, for at forenkle kilde\u00e6ndringer og undg\u00e5 replikationsfiltre p\u00e5 GTID-ruter, da de g\u00f8r fejls\u00f8gning vanskeligere. Trin <strong>fejlagtige transaktioner<\/strong> (transaktioner, der findes p\u00e5 en replika, men ikke p\u00e5 kilden), identificerer jeg dem via forskellen p\u00e5 <code>gtid_udf\u00f8rt<\/code> og kilden og rydder op p\u00e5 en kontrolleret m\u00e5de - ikke blindt med purges. Jeg planl\u00e6gger binlog-retention p\u00e5 en s\u00e5dan m\u00e5de, at rebuilds er mulige uden huller, og tjekker konsistensen af <code>gtid_purged<\/code>.<\/p>\n\n<h2>Parallelisering og gennemstr\u00f8mning p\u00e5 replikaer<\/h2>\n<p>For at reducere forsinkelsen \u00f8ger jeg <code>replika_parallelle_arbejdere<\/code> i henhold til antallet af CPU'er, og v\u00e6lg <code>replica_parallel_type=LOGICAL_CLOCK<\/code>, s\u00e5 relaterede transaktioner forbliver organiserede. Med <code>binlog_transaction_dependency_tracking=WRITESET<\/code> Jeg \u00f8ger paralleliteten, fordi uafh\u00e6ngige skrivninger kan anvendes samtidigt. Jeg overv\u00e5ger deadlock- og lock-ventetider p\u00e5 replikaer: overdreven parallelisme kan generere samtidige opdateringer. Det hj\u00e6lper desuden <strong>Gruppeforpligtelse<\/strong> p\u00e5 masteren (tilknyttede flush-forsinkelser) for at samle relaterede transaktioner mere effektivt - uden at overskride P95-latensomr\u00e5det.<\/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>Skema\u00e6ndringer uden nedetid<\/h2>\n<p>Jeg foretr\u00e6kker <strong>Online DDL<\/strong> med InnoDB (<code>ALGORITME=INDS\u00c6T\/INSTANT<\/code>, <code>LOCK=INGEN<\/code>) til at b\u00e6re tabel\u00e6ndringer gennem replikering uden at blokere foresp\u00f8rgsler. Til meget store tabeller v\u00e6lger jeg chunk-baserede metoder, opdeler indekser og holder \u00f8je med binlog-belastningen. For multi-master planl\u00e6gger jeg DDL-vinduer strengt, da samtidige skema\u00e6ndringer er sv\u00e6re at helbrede. Jeg tester DDL'er p\u00e5 en replika, m\u00e5ler deres indvirkning p\u00e5 lag og promoverer kun, n\u00e5r replikationsstien forbliver stabil.<\/p>\n\n<h2>Forsinket replikation som sikkerhedsnet<\/h2>\n<p>Mod logiske fejl (DROP\/DELETE) betragter jeg en <strong>forsinket replika<\/strong> klar, for eksempel med <code>replica_sql_delay=3600<\/code>. Det giver mig mulighed for at vende tilbage til en ren tilstand inden for en time uden straks at k\u00f8re PITR fra sikkerhedskopier. Jeg bruger aldrig denne replika til l\u00e6sninger eller failovers - det er udelukkende en sikkerhedsbuffer. Jeg automatiserer kopier fra denne node, s\u00e5 jeg hurtigt kan tr\u00e6kke en frisk, opdateret l\u00e6se-node op i en n\u00f8dsituation.<\/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>Opgraderinger, kompatibilitet og drift<\/h2>\n<p>Jeg holder kilde- og m\u00e5lversioner t\u00e6t sammen og opgraderer <strong>rullende<\/strong>F\u00f8rst replikaer, s\u00e5 masteren. Jeg ser kritisk p\u00e5 blandede milj\u00f8er med MySQL\/MariaDB, da binlog-formater og -funktioner kan afvige fra hinanden. Jeg bruger <code>binlog_row_image=MINIMAL<\/code> hvor det giver mening at reducere binlog-volumen og tjekke applikationsafh\u00e6ngigheder for triggere eller stored procedures. Jeg reducerer WAN-belastningen til protokol- og binlog-komprimering, men s\u00f8rger for ikke at overskride CPU-budgetterne.<\/p>\n\n<h2>Observerbarhed og kapacitetsplanl\u00e6gning<\/h2>\n<p>Jeg definerer SLO'er for <strong>Lag<\/strong>, opsamlingstider, fejlrater og genneml\u00f8b. Kernevariablerne omfatter anvendte transaktioner pr. sekund, fyldningsniveauer i rel\u00e6-loggen, I\/O-k\u00f8er, ventetider p\u00e5 l\u00e5se og netv\u00e6rkslatens. Jeg registrerer binlog-v\u00e6kst, planl\u00e6gger <code>binlog_expire_logs_sekunder<\/code> og tjekker, om rebuilds holder sig inden for retention-perioderne. Jeg s\u00e6tter gr\u00e6nser for replikaer som f.eks. <code>max_forbindelser<\/code> og overv\u00e5ger aflysninger, s\u00e5 l\u00e6sebelastninger ikke l\u00f8ber ud i ingenting. N\u00e5r det g\u00e6lder omkostninger og st\u00f8rrelse, beregner jeg fan-out-niveauer, lagerkrav og <strong>Spidsbelastninger<\/strong> i forhold til RPO\/RTO-m\u00e5l.<\/p>\n\n<h2>Sikkerhed og compliance i replikationsoperationer<\/h2>\n\n<p>Jeg forsegler forbindelser <strong>ende-til-ende<\/strong> og strengt adskilte operat\u00f8r-, applikations- og replikeringskonti. Regelm\u00e6ssige rettighedsrevisioner forhindrer replikationsbrugere i at beholde un\u00f8dvendige DDL\/DML-autorisationer. Jeg beskytter offsite-sikkerhedskopier med separat n\u00f8gleh\u00e5ndtering og kontrollerer adgangsstier mod lateral bev\u00e6gelse. Af hensyn til databeskyttelse overholder jeg regler for sletning og replikerer pseudonymiserede eller minimerede dataposter, hvis form\u00e5let tillader det. Jeg deler logning og metrikker i henhold til mindste privilegium, s\u00e5 telemetri ikke bruges sk\u00f8desl\u00f8st. <strong>L\u00e6kage<\/strong> produceret.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Til hosting-scenarier giver Master-Slave en p\u00e5lidelig <strong>Basis<\/strong>, fordi l\u00e6sninger let skaleres, og der sj\u00e6ldent opst\u00e5r konflikter. Hvis globale skrivninger, lav latenstid og fejltolerance er en prioritet, overvejer jeg multi-master og planl\u00e6gger regler for konfliktl\u00f8sning. Jeg kombinerer GTID'er, ren overv\u00e5gning og gennemt\u00e6nkte backups for sikkert at opn\u00e5 recovery-m\u00e5l. Ved at indstille binlog-, storage- og query-parametre reducerer jeg forsinkelser og holder throughput h\u00f8jt. Det giver mig mulighed for at v\u00e6lge den rigtige topologi, skalere p\u00e5 en kontrolleret m\u00e5de og minimere nedetid for brugerne. <strong>usynlig<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Databasereplikation i hosting: **MySQL master slave** vs. multi-master for perfekt **skalering af db**. Konfiguration, fordele og tips.<\/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\/da\/wp-json\/wp\/v2\/posts\/18104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=18104"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18104\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18097"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}