Database for nettsider – MySQL, MariaDB og driftsansvar

En database lagrer data som nettsiden må kunne finne, koble sammen og endre. I WordPress er innlegg, brukere og innstillinger typiske databasedata. I en nettbutikk gjelder det også produkter, ordre og lager. Selve applikasjonskoden og mange opplastede bilder ligger vanligvis som filer eller i objektlagring.

Ikke alle nettsider trenger en database. En statisk side kan bygges ferdig til HTML og leveres uten database i produksjon. Det gir færre bevegelige deler, men passer ikke automatisk for innlogging, ordre eller innhold som endres gjennom et administrasjonspanel.

Hva gjør en relasjonsdatabase?

MySQL og MariaDB er relasjonsdatabaser. De organiserer data i tabeller med rader og kolonner, og kobler dem gjennom nøkler.

En forenklet nettbutikk kan ha:

Applikasjonen sender SQL-spørringer for å lese eller endre data. Databasen håndterer blant annet regler, transaksjoner, indekser og samtidig tilgang. Det gjør det mulig å oppdatere flere relaterte verdier samlet, men bare når applikasjon og databaseskjema er utformet riktig.

Hva WordPress lagrer i databasen

En vanlig WordPress-installasjon lagrer blant annet:

• innlegg, sider, revisjoner og status
• brukere, roller og brukerdata
• kommentarer og modereringsstatus
• taksonomier som kategorier og stikkord
• nettsteds- og plugininnstillinger
• metadata til innhold, brukere og kommentarer
• data opprettet av plugins, for eksempel skjema eller netthandel

Bilder og andre opplastinger ligger normalt i filområdet, mens metadata om dem ligger i databasen. En databaseeksport alene er derfor ikke en komplett WordPress-kopi. Bruk WordPress-backupguiden for hele avhengighetssettet.

MySQL og MariaDB er beslektet, ikke identisk

MariaDB oppsto som en forgrening av MySQL og bruker i stor grad samme klientprotokoll og SQL-grunnlag. Mange webapplikasjoner støtter begge. Produktene har samtidig utviklet ulike funksjoner, datatyper, JSON-oppførsel, replikering og versjonsløp.

Derfor bør ikke en flytting mellom dem behandles som et navnebytte. Kontroller alltid:

• nøyaktig serverversjon og om den fortsatt vedlikeholdes
• applikasjonens dokumenterte krav
• lagringsmotorer, tegnsett og sorteringsregler
• datatyper, funksjoner, triggere og events som brukes
• drivere og tilkoblingsinnstillinger
• SQL-modus og versjonsforskjeller
• backup- og restoreverktøyenes kompatibilitet

MariaDB dokumenterer at forskjellene mellom nyere MariaDB- og MySQL-versjoner fortsetter å øke . Test applikasjon, migrering og rollback mot de konkrete versjonene dere skal bruke.

Koble applikasjonen til databasen trygt

Applikasjonen trenger vertsnavn, port, databasenavn og en egen databasebruker. Hemmeligheten bør ligge i plattformens sikre konfigurasjon, ikke i offentlig kode, supportsaker eller delte dokumenter.

Bruk disse prinsippene:

• databasen skal ikke være offentlig tilgjengelig når det ikke er nødvendig
• tillat bare kjente applikasjoner, nettverk eller identiteter
• bruk separat database og bruker for uavhengige applikasjoner og miljøer
• gi brukeren bare rettigheter applikasjonen faktisk trenger
• beskytt trafikken med TLS når den går over et nettverk som ikke er internt og kontrollert
• roter hemmeligheten ved mistanke om eksponering
• logg administrative endringer uten å logge passord eller sensitive spørringsdata ukritisk

Ikke kopier en generell liste med SQL-rettigheter. Noen applikasjoner trenger å opprette eller endre tabeller under oppgradering; andre skal aldri kunne gjøre det i normal drift. Skill gjerne migreringsrettigheter fra den vanlige kjøretidsbrukeren når plattformen støtter det.

phpMyAdmin er et verktøy, ikke et krav

phpMyAdmin gir et nettgrensesnitt for blant annet tabeller, spørringer, eksport og import. Andre plattformer bruker Adminer, kommandolinje, databaseklient eller en administrert konsoll.

Direkte redigering i produksjonsdatabasen bør være et kontrollert unntak:

1. dokumenter problemet og ønsket endring
2. sikre konsistent og gjenopprettbar kopi
3. test spørringen mot tilsvarende data
4. bruk en transaksjon når operasjonen støtter det
5. begrens utvalget eksplisitt og kontroller antall berørte rader
6. verifiser applikasjonen etterpå
7. oppbevar endringen som en sporbar migrering når den skal kunne gjentas

En manuell endring kan bryte relasjoner, serialiserte verdier, cache eller applikasjonsregler selv om SQL-spørringen fullføres.

Feilsøk ytelse før du «optimaliserer»

En stor database er ikke nødvendigvis treg, og en liten database er ikke nødvendigvis rask. Mål først:

• hvilke spørringer som bruker mest tid og ressurser
• ventetid fra applikasjon til database
• CPU, minne, disk og I/O
• låsing, samtidighet og lange transaksjoner
• treffsikkerhet for indekser og antall rader som leses
• forbindelser, køer og feil
• endringer i datamengde og trafikk

Bruk databaseverktøyets spørringsplan, for eksempel EXPLAIN, for å se hvordan en konkret spørring blir utført. Legg ikke til indekser blindt: de kan gjøre lesing raskere, men bruker plass og gjør skriving dyrere. Endre heller ikke tabeller eller slett revisjoner uten å forstå funksjon, oppbevaringskrav og rollback.

For en WordPress-side kan treghet også ligge i PHP, plugins, eksterne API-er, bilder eller nettverket. Følg arbeidsflyten for en raskere nettside før dere kjøper større database bare fordi forsiden er treg.

Databasebackup må være konsistent

En logisk dump inneholder kommandoer eller data som kan importeres på nytt. Et fysisk snapshot kopierer underliggende lagring. Replikering holder en annen instans oppdatert. Transaksjonslogger kan gi gjenoppretting til et tidspunkt. Mekanismene har ulike egenskaper, og ingen av dem er automatisk en komplett backup av nettsiden.

For en database i aktiv bruk må kopien representere en konsistent tilstand. MySQL beskriver for eksempel at mysqldump --single-transaction kan gi et konsistent øyeblikksbilde for transaksjonstabeller som InnoDB, men at enkelte schemaendringer under dumpen kan gjøre resultatet feil eller få operasjonen til å mislykkes. Se MySQLs dokumentasjon for mysqldump .

Planen må svare på:

• dekkes alle databaser, brukere, skjemaobjekter og nødvendige innstillinger?
• er filer og database fra et kompatibelt tidspunkt?
• hvor mye data kan gå tapt mellom kopier?
• beholdes flere tidspunkter, og kan en angriper slette dem?
• finnes krypteringsnøkler og tilganger ved gjenoppretting?
• er import testet mot en støttet serverversjon?
• er antall rader, relasjoner og kritiske brukerreiser kontrollert etter restore?

En phpMyAdmin-eksport kan være nyttig ved en liten database, men størrelse, tidsavbrudd, konsistens og manglende objekter må vurderes. En fil som kan lastes ned er ikke verifisert før den er importert og applikasjonen er testet. Se backup-planen for hele nettsiden for RPO, RTO og uavhengig lagring.

Flytt databasen uten å miste nye data

Planlegg migreringen som en kontrollert cutover:

1. Kartlegg kilde- og målversjon, størrelse, tegnsett, tidssone, objekter og avhengigheter.
2. Test eksport og import med realistiske data.
3. Mål hvor lang tid kopiering, validering og eventuell rollback tar.
4. Bestem om applikasjonen må ha skrivepause, eller om endringer replikeres frem til cutover.
5. Ta konsistent sluttkopi og registrer nøyaktig tidspunkt eller loggposisjon.
6. Kontroller tabeller, radantall, nøkkeldata og applikasjonsfunksjoner.
7. Bytt applikasjonen kontrollert og følg feil, køer og skrivninger.
8. Behold gammel løsning beskyttet og skrivebeskyttet til rollbackvinduet er utløpt.

DNS alene flytter ikke databasen. Nettstedet må kobles til riktig instans, og alle skrivninger i overgangsperioden må havne på et sted dere kan bevare.

Spør webhotellet om dette

Før dere velger hosting for en databasebasert nettside, be om konkrete svar:

• Hvilket produkt og hvilken versjon brukes, og hvordan oppgraderes den?
• Hvilke grenser gjelder for lagring, forbindelser, spørringstid og import?
• Får kunden egen database og databasebruker?
• Kan databasen nås sikkert for migrering og administrasjon?
• Hvilke logger og ytelsesdata er tilgjengelige?
• Hva sikkerhetskopieres, hvor ofte, hvor lenge og med hvilken konsistens?
• Kan kunden eksportere en portabel kopi uten ekstra avtale?
• Hvem utfører restore, hva koster det og hvilken tid forpliktes?
• Hvordan varsles feil, vedlikehold og versjonsutfasing?

«MySQL inkludert» sier ikke nok til å vurdere drift eller flyttbarhet.

Database i Vymos standardtilbud

Vymos standardtilbud er én enkel, ferdig publisert bedriftsnettside. Det publiserte tilbudet lover ikke MySQL, MariaDB, phpMyAdmin eller kundestyrt database, og skal derfor ikke velges som om det var et generelt WordPress-webhotell.

Har løsningen innlogging, nettbutikk, booking eller andre løpende data, må plattform, database, migrering, backup og driftsansvar spesifiseres separat. Beskriv databehovet før dere bestiller , eller velg den enkle nettsiden når virksomheten bare trenger en ryddig tilstedeværelse på nett.