MySQL hosting: 7 ting du skal kræve

Kort svar: De vigtigste krav til MySQL hosting er en understøttet version (MySQL 8.4 LTS eller 9.7 LTS, eller en tilsvarende understøttet MariaDB), automatiske backups med point-in-time restore, gendannelse til en ny instans, en tydelig model for høj tilgængelighed, krypterede forbindelser, overvågning og en dokumenteret opgraderingssti. Bed udbyderen vise, hvordan en gendannelse laves, og hvor lang tid den tager.

Fagligt gennemgået: 2. oktober 2026

MySQL hosting er kun godt nok, hvis det beskytter data, tåler fejl og kan opgraderes uden drama. Det vigtigste er ikke markedsføringen, men om udbyderen kan dokumentere versionssupport, gendannelse og høj tilgængelighed.

Når nogen siger “vi tilbyder MySQL”, bør dit næste spørgsmål være: “På hvilken version, med hvilke backups, og hvordan gendannes data præcist?” Det er netop her, forskellen mellem billig databaseplads og driftsegnet MySQL hosting viser sig.

Opsummering

• Det rigtige valg af MySQL hosting kræver mindst tre ting: en understøttet LTS-version som MySQL 8.4 eller 9.7, automatiske backups med point-in-time restore og en tydelig model for høj tilgængelighed eller failover.
• MySQL 8.0 nåede end of life i april 2026, så en udbyder bør kunne forklare opgraderingsstien væk fra 8.0 og oplyse præcis major- og minorversion.
• Backup er ikke det samme som høj tilgængelighed. Backup redder dig efter fejl, sletninger og korruption, mens HA beskytter mod server- eller zonefejl.
• Kræv krypterede forbindelser mellem klient og MySQL-server. HTTPS på websitet beskytter ikke automatisk trafikken til databasen.
• Kan HA, zoneredundans eller backupvalg kun aktiveres ved oprettelse, skal de afklares før bestilling. Ellers kan du stå med en dyr migrering senere.
• Kontrolspørgsmålet er enkelt: Kan udbyderen vise, hvordan en gendannelse laves, hvor lang tid den tager, og hvad der sker ved failover?

Hvorfor er versionssupport det første krav til MySQL hosting?

Det første krav er en aktivt understøttet version. Pr. oktober 2026 er de understøttede LTS-linjer MySQL 8.4 (udgivet april 2024) og MySQL 9.7 (udgivet april 2026). MySQL 8.0 mistede sin udvidede support i april 2026, så en udbyder uden klar opgraderingspolitik er et driftsmæssigt rødt flag.

Versionssupport handler ikke kun om nye funktioner. Det handler om sikkerhedsrettelser og kompatibilitet med drivere, ORM-lag, PHP-versioner og værktøjer til backup og replikering. Er databasen gammel, bliver hver ændring omkring applikationen mere følsom.

En almindelig misforståelse er, at “MySQL er MySQL”. I praksis kan forskelle mellem 8.0, 8.4 og 9.x påvirke SQL-syntaks, autentificering, standardindstillinger og performance. Derfor bør udbyderen oplyse præcis majorversion og helst også minorversion, ikke kun et generisk “vi kører MySQL”. Det samme gælder MariaDB, som mange webhoteller bruger i stedet; her skal versionen også være aktivt understøttet.

Kan din leverandør ikke forklare, hvornår de opgraderer, hvordan de varsler, og om der findes staging eller testmiljø, køber du reelt usikker drift. Det er især risikabelt for WordPress, WooCommerce og integrationsmiljøer med mange plugins eller eksterne systemer.

Skal du vælge MySQL 8.4 LTS eller 9.7 LTS?

Begge er LTS-udgivelser med fem års almindelig support og derefter udvidet support. For de fleste eksisterende produktionsmiljøer er MySQL 8.4 det sikre standardvalg, fordi den har været ude længst, og plugins og biblioteker er bredt testet mod den. MySQL 9.7 er relevant, når applikation, testproces og driftsteam er klar til den nyere linje og vil have den længste supporthorisont.

8.4 giver ro omkring change management. Det er ofte det rigtige valg, hvis du driver webshop, ERP-integration eller et CMS-miljø, hvor stabilitet vægter højere end tidlig adgang til nyt. Den er lettere at dokumentere internt og gør kompatibiliteten med plugins mere forudsigelig.

9.7 kan være det rigtige valg, hvis din softwareleverandør allerede understøtter den, eller hvis du har et modent setup med automatiserede tests og en tydelig rollback-proces. Ud over LTS-linjerne udgiver Oracle også kortlivede innovation-udgivelser, der kun understøttes indtil næste udgivelse. De passer sjældent til produktion på delt hosting.

Det forkerte valg er sjældent “for gammel” eller “for ny” isoleret set. Fejlen opstår, når versionen vælges uden sammenhæng med supportpolitik, release management og applikationens reelle afhængigheder. Ved du ikke, hvad der er certificeret i din stak, er 8.4 normalt den bedre start.

Hvad er de 7 vigtigste krav til MySQL hosting?

De syv vigtigste krav handler om dokumentation, gendannelse, høj tilgængelighed, kryptering, overvågning og en klar opgraderingssti. Mangler ét af dem, bliver MySQL hosting hurtigt dyrere i drift, end det ser ud på prissiden.

1. Dokumenteret versionssupport: kræv præcis MySQL-version, plan for end of life og opgraderingssti. Versionen bør kunne oplyses før idriftsættelse.
2. Automatiske backups med fast opbevaringstid: du skal vide, hvor ofte der tages backup, og hvor længe den gemmes.
3. Point-in-time restore: du skal kunne gendanne til et bestemt tidspunkt, ikke kun til nattens fulde backup.
4. Gendannelse til ny instans: det reducerer risikoen, fordi gendannelse oven i en eksisterende instans kan overskrive aktuelle data.
5. Høj tilgængelighed med automatisk failover – eller et bevidst fravalg: du skal vide, hvad der sker, hvis serveren går ned.
6. Krypterede forbindelser: kryptering mellem klient og server skal være et eksplicit krav, ikke en antagelse.
7. Driftsmodel og support: få svar på backupvindue, overvågning, alarmer, eskalering og hvem der faktisk hjælper ved fejl.

Listen virker enkel, men den adskiller gode driftspartnere fra udbydere, der kun sælger rå infrastruktur. Jo mere forretningskritisk databasen er, desto mindre bør du acceptere uklare svar.

Hvordan kontrollerer du versionspolitik og opgraderingssti før køb?

Den bedste metode er at spørge om tre konkrete ting: nuværende version, planlagt opgraderingsvindue og testmulighed. Bed om svarene skriftligt.

Trin 1: Bed om præcis version og supportstatus

Spørg ikke kun “understøtter I MySQL?”. Spørg i stedet: Hvilken major- og minorversion opretter I databaser på i dag, og hvornår udgår den? Standardiserer udbyderen stadig på 8.0, bør alarmklokkerne ringe.

Du kan selv tjekke versionen på din nuværende hosting. I WordPress står den under Værktøjer → Webstedets tilstand → Info → Database, og med SSH-adgang kan du spørge serveren direkte:

mysql -u brugernavn -p -e "SELECT VERSION();"

Trin 2: Få opgraderingsprocessen beskrevet

Bed om en kort beskrivelse af, hvordan opgraderinger foregår. Du skal vide, om opgraderingen sker på stedet, om der er et vedligeholdelsesvindue, om rollback er muligt, og om du bliver varslet. Er svaret uklart, bliver selve opgraderingen ofte også uklar.

Trin 3: Tjek om staging eller klon er mulig

Opgraderinger uden test er dyr risikostyring. For CMS- og webshopmiljøer bør du kunne klone applikationen og validere plugins, forespørgsler og integrationer, før produktion ændres. Mange tror, at en databaseopgradering er et rent infrastrukturskift, men det er i praksis også et applikationsskift.

Hvordan vurderer du backup, point-in-time restore og gendannelsestests?

En god backupstrategi kan beskrives konkret i tre led: hvornår der tages backup, hvor længe den gemmes, og hvordan der gendannes. En seriøs udbyder bør kunne forklare alle tre uden forbehold.

Trin 1: Få opbevaringstid og backupvindue på plads

Spørg, hvor ofte der tages backup, hvor længe den opbevares, og om der er et fast backupvindue. Læs mere om, hvordan automatisk backup på hosting fungerer.

Trin 2: Verificér point-in-time restore

Point-in-time restore betyder, at du kan genskabe databasen til et bestemt tidspunkt mellem backups. Det bygger typisk på MySQL’s binære log, som gemmer alle ændringer, så en fuld backup kan “afspilles” frem til et valgt øjeblik. Det redder dig ved brugerfejl, fejlbehæftede imports eller korruption, som opstår længe før næste fulde backup.

Trin 3: Kræv en gendannelsestest, ikke kun en backupfunktion

Gendannelse oven i en eksisterende instans kan overskrive aktuelle data. Derfor er det stærkere, hvis udbyderen kan gendanne til en ny instans eller en kopi, så du kan validere data før skiftet. Lektien er enkel: en backup er først værdifuld, når gendannelsen er afprøvet og tidsestimeret. Se test din backup.

Hvad er forskellen på backup og høj tilgængelighed i MySQL hosting?

Backup og høj tilgængelighed (HA) løser to forskellige problemer. Selv en platform med automatisk failover og zoneredundant HA erstatter ikke backup eller point-in-time restore.

Backup beskytter mod logiske fejl: tabeller slettet ved en fejl, dårlige deploys, skadelig kode eller datakorruption. Høj tilgængelighed beskytter mod infrastruktursvigt: tab af en node, hardwarefejl eller udfald i en zone. Sletter du 50.000 rækker ved en fejl, hjælper HA ikke, fordi sletningen kopieres til standby-serveren. Du har brug for point-in-time restore.

Her opstår en klassisk fejlvurdering. Mange ser en standby-node og tror, at datahistorikken dermed er dækket. Det er den ikke. HA holder tjenesten kørende. Backup gør det muligt at gå tilbage i tid.

Det samme gælder økonomien. Tåler applikationen kort nedetid, men ikke datatab, er stærke backups vigtigere end dyr HA. Tåler applikationen hverken nedetid eller datatab, skal du have begge dele.

Hvordan verificerer du HA, failover og zoneredundans i praksis?

HA er kun troværdig, når failover-modellen er dokumenteret. Hos nogle udbydere skal HA vælges ved oprettelse og kan ikke tilføjes senere uden konsekvenser.

Trin 1: Spørg om HA er standard eller tilvalg

Få svar på, om høj tilgængelighed er aktiv som standard, eller om den skal vælges ved oprettelsen. Det er en vigtig detalje, fordi nogle backup- og HA-valg binder sig til den oprindelige opsætning.

Trin 2: Bed om topologien forklaret

Du behøver ikke hele arkitekturdiagrammet. Du skal bare vide, om der findes en standby, om den står i samme zone eller i en anden, og hvad zoneredundant HA konkret betyder i deres model. Kan udbyderen ikke forklare det enkelt, er det sjældent et godt tegn.

Trin 3: Få forventet genoprettelsestid og databeskyttelse beskrevet

Spørg, hvor hurtigt en failover normalt forventes at ske (RTO), og hvor meget data du højst kan miste (RPO). Et godt svar beskriver, om designet sikrer, at bekræftede transaktioner ikke går tabt ved failover. Den type præcise driftssvar er det, du skal lede efter.

Hvorfor skal krypterede forbindelser være et eksplicit krav?

Krypterede forbindelser bør være obligatoriske i MySQL hosting. MySQL understøtter TLS-krypterede forbindelser mellem klient og server, så manglende kryptering er et valg, ikke en teknisk begrænsning.

Mange antager, at HTTPS på hjemmesiden betyder, at alt er krypteret. Det er forkert. Trafikken mellem applikation og database kan stadig være ukrypteret, især hvis der arbejdes på tværs af servere, containere, zoner eller eksterne integrationer. Ligger web og database på samme server og taler sammen via localhost eller en socket, forlader trafikken ikke maskinen, og risikoen er tilsvarende mindre.

Det rigtige spørgsmål er derfor ikke kun “understøtter I SSL?”, men også “kan I håndhæve krypterede forbindelser, validere certifikater og dokumentere, hvordan klienter kobler op?”. Håndterer databasen persondata, betalingsflow eller kundedata, er det et basalt sikkerhedskrav og ofte også et governance-krav.

Tjek connection strings og brugerrettigheder. Kan klienter stadig forbinde uden kryptering, er sikkerheden kun delvist implementeret. God MySQL hosting gør sikre standarder lette at håndhæve, fx ved at kræve kryptering for de brugere, der forbinder udefra.

Hvornår er managed MySQL bedre end webhotel eller VPS?

Managed MySQL passer til forretningskritiske workloads, et webhotel til enklere løsninger og en VPS til teams med egen driftsekspertise. Det er forskellige driftsmodeller, ikke bare forskellige prisniveauer.

Et klassisk webhotel kan være nok, når MySQL kun understøtter et mindre website med lav skriveaktivitet og få integrationer. Det er ofte den billigste start, men du får sjældent avanceret point-in-time restore, en tydelig HA-model eller finmasket performance-tuning.

En VPS giver frihed til at styre konfiguration, buffer pool, replikaer og sikkerhedspolitikker. Til gengæld overtager du ansvaret for patching, backup, overvågning og hændelseshåndtering. Ejer ingen internt databasedriften, bliver en VPS hurtigt dyrere, end den ser ud.

Managed MySQL eller en administreret applikationshost er bedst, når nedetid koster penge, og når teamet hellere vil bygge produkt end drive databaseplatform. Det gælder især WooCommerce, medlemsløsninger og indholdsplatforme med trafikspidser og mange samtidige forespørgsler.

Hvilke fejl går oftest igen, når virksomheder vælger MySQL hosting?

De mest almindelige fejl er gamle versioner, utestede gendannelser og sammenblanding af HA med backup. Databasedrift er stærkest, når kravene er konkrete og kan dokumenteres.

1. Købe efter pris og glemme livscyklus. Er MySQL-versionen tæt på end of life, køber du samtidig et fremtidigt projekt med migrering, kompatibilitetstest og mulig nedetid.
2. Acceptere ordet “backup” uden at spørge ind til detaljerne. Spørg til opbevaringstid, backupvindue og gendannelsesmetode. Kan gendannelse kun ske oven i den eksisterende instans, er risikoen større.
3. Tro, at HA løser brugerfejl. Automatisk failover hjælper ikke mod forkerte imports, dårlige deploys eller applikationer, der skriver forkerte data. Her er point-in-time restore redningen.
4. Overse kryptering mellem klient og server. Det er stadig almindeligt, at teams kontrollerer HTTPS og firewall, men glemmer krypteringen på MySQL-forbindelsen. Se også krav til sikker hosting.
5. Vælge en driftsmodel, der ikke passer til organisationen. Kan ingen vedligeholde en VPS, bør du ikke købe en VPS. Er databasen central for omsætningen, bør du heller ikke nøjes med et uigennemsigtigt standardwebhotel.

Den rigtige MySQL hosting er den model, hvor versioner, backups, gendannelse og failover kan forklares klart, testes i praksis og ejes ansvarligt.

Hvordan gendanner du én database uden at rulle hele sitet tilbage?

Kræv, at backup kan gendannes pr. database og ikke kun som ét samlet snapshot af hele hostingkontoen. Har en fejlbehæftet import eller et plugin ødelagt en tabel, skal du kunne lægge databasen tilbage uden også at rulle filer, uploads og e-mails tilbage til samme tidspunkt.

Forskellen er stor i praksis. På en WooCommerce-shop ændrer filer og database sig i forskellig rytme: produktbilleder og temafiler ligger stille i dage, mens ordrer, lagertal og kundedata skrives hele tiden. En samlet gendannelse af hele sitet betyder derfor ofte, at du mister noget, du gerne ville beholde, for at redde noget, du er nødt til at have tilbage. Se gendan fra backup uden at miste nye ordrer.

Stil derfor tre spørgsmål, før du bestiller:

• Kan hjemmesidefiler, databaser og e-mails gendannes hver for sig, eller kun samlet?
• Kan du selv starte en gendannelse fra kontrolpanelet, eller skal du åbne en supportsag og vente?
• Kan en backup hentes ned som dump, så du kan læse data ud lokalt, før du beslutter, om produktion skal rulles tilbage?

Svarene er lige vigtige, uanset om du kigger på et webhotel eller en administreret løsning. Gennemgangen af backupløsninger til webshops viser, hvorfor granularitet i gendannelsen er et gennemgående krav og ikke en luksus.

Har du selv SSH-adgang, kan du også tage et manuelt dump af én database, før du laver en risikabel ændring. Med WP-CLI er det én kommando:

wp db export backup-foer-opdatering.sql

Brug staging som forsikring, før du rører produktionsdatabasen

Backup er reaktiv. Staging er proaktiv. Kan du klone site og database til et testmiljø, kan du køre pluginopdateringer, temaskift, WooCommerce-opgraderinger og databasemigreringer igennem, før de rammer den aktive database. Mange af de fejl, der ender som gendannelsessager, startede som en opdatering, ingen nåede at teste. Kræv derfor, at staging følger med, og at staging får sin egen databasekopi i stedet for at dele tabeller med produktion.

Hvornår er databasen flaskehalsen, og hvad skal du kræve af serveren?

Langsom MySQL viser sig sjældent som en fejlmeddelelse. Den viser sig som symptomer i frontend og admin, og de peger næsten altid tilbage på kombinationen af diskhastighed, ledige serverressourcer og antallet af samtidige forespørgsler.

Symptom	Typisk årsag i databasen	Det bør du kræve
Produkt- og kategorisider bliver langsomme under trafik	Mange samtidige læseforespørgsler og en buffer pool, der er for lille	NVMe-lager og garanterede ressourcer, ikke delt kapacitet uden loft
Admin-panelet i WordPress eller WooCommerce er tungt	Store tabeller uden indeks, postmeta og ordredata, der aldrig ryddes op	Indsigt i langsomme forespørgsler og mulighed for databaseoptimering
Checkout tøver eller fejler i spidsbelastning	Låsninger ved skrivning til ordre-, lager- og sessionstabeller	Tilstrækkelige CPU-ressourcer og en klar model for opskalering
Integrationer mod ERP, PIM eller lagersystem hænger	Tunge batchjob konkurrerer med besøgende om samme database	Mulighed for at flytte til en isoleret VPS eller dedikeret server

Pointen med tabellen er, at hurtigere hosting ikke er ét greb. Disk, CPU og databasekonfiguration skal passe sammen, og du skal kunne se, hvor tiden går, før du køber mere kapacitet. Et godt sted at starte er at finde langsomme databasekald med Query Monitor.

Replikering: læs fra replikaen, tag backup på replikaen

Når én server ikke længere er nok, er MySQL-replikering det naturlige næste trin. En eller flere replikaer modtager løbende alle ændringer fra den primære server og kan bruges til to ting, som begge aflaster produktion. Læseforespørgsler fra rapporter, søgning og integrationer kan sendes til replikaen, og backup kan tages på replikaen, så dump og snapshot ikke stjæler I/O fra kunderne midt på dagen.

Replikering er ikke det samme som HA. En replika giver dig en kopi, men ikke nødvendigvis automatisk failover, og den beskytter heller ikke mod, at en fejlagtig sletning replikeres videre med det samme. Se den som et værktøj til skalering og skånsom backup, og kræv stadig point-in-time restore og en dokumenteret failover-model ved siden af.

Den slags opsætning kræver typisk en VPS eller en dedikeret server. Er du i tvivl om, hvornår springet kan betale sig, giver guiden til hvornår en dedikeret server giver mest værdi et konkret afsæt.

Hvad betyder support og placering for MySQL-drift?

Når databasen er nede, tæller supportens svartid lige så meget som serverens. Kræv, at du kan få fat i en tekniker, der kender miljøet og selv kan udføre en gendannelse, og ikke kun en førstelinje, der opretter en sag. Spørg konkret: Hvem kan starte en gendannelse klokken tre om natten, og hvor lang tid går der typisk, før den er i gang?

Placering betyder også noget for governance. Ligger database og backups i EU, og har du en databehandleraftale med udbyderen, er det lettere at dokumentere, hvor persondata behandles, og hvem der har adgang. Det er ofte et krav fra kunder og revisorer, ikke kun en teknisk præference. Se også hvor dine sikkerhedskopier ligger.

Hos Hostious er MySQL-databasen en del af WordPress hosting fra 39 kr./md. og WooCommerce hosting fra 59 kr./md. ekskl. moms. Alle planer kører på LiteSpeed og NVMe med daglig og manuel backup, selvbetjent gendannelse, gratis SSL, dansk support døgnet rundt, gratis migrering og servere i Europa. Staging følger med fra WP StartUp og Woo StartUp, og har du brug for en isoleret database på VPS eller server, tilpasses løsningen efter behov.

Læs også

• Hub: Servere, VPS og cloud – alle guides om emnet samlet ét sted
• Hvad er en MySQL-database? Dit indholds egentlige hjem
• Fejl ved oprettelse af databaseforbindelse i WordPress
• Databasetabel beskadiget: „marked as crashed“ – reparér sikkert
• VPS hosting hos Hostious – tilpasses efter behov

Ofte stillede spørgsmål om MySQL hosting

Hvilken MySQL-version bør min hosting tilbyde?

En version med aktiv support – i praksis MySQL 8.4 LTS eller 9.7 LTS (eller en tilsvarende understøttet MariaDB). Spørg også til udbyderens opgraderingspolitik: en database uden opdateringsvej bliver et sikkerhedsproblem.

Hvad er point-in-time restore, og hvorfor er det vigtigt?

Muligheden for at gendanne databasen til et præcist tidspunkt – fx lige før en fejlslået import. Uden det kan du kun gå tilbage til seneste backup og mister alt derimellem.

Hvordan tester jeg databasens ydeevne hos en udbyder?

Kør dine tungeste rigtige forespørgsler mod en testkopi – fx søgning og filtrering – og mål svartiden under samtidighed. NVMe-lager og nok RAM til InnoDB-bufferen er de to specifikationer, der oftest afgør resultatet.

Er MySQL 8.0 stadig sikker at bruge?

MySQL 8.0 mistede sin udvidede support i april 2026 og får ikke længere officielle sikkerhedsrettelser. Kører din database stadig på 8.0, bør du planlægge en opgradering til 8.4 LTS og teste den på en kopi først.