Calling on the MySQL wizards

Hej rushers,
Jeg har en MySQL database leveret af en producent. Og som det er sædvane med software designet af større firmaer, så er det en idiot der har designet den bagvedliggende database (eller måske en abe, jeg ved det ikke, men det virker sandsynligt). Eller rettere, de har designet multiklient software til at connecte direkte til MySQL databasen, i stedet for at lave en reel serverdaemon der håndterer det.

Så, AL data ligger i MySQL databasen. Og den er nu på over 1.2 TB på vores SAN. Det er ikke i sig selv et problem. Problemet opstår når jeg skal tage offsite backup af lortet. Fordi data ligger i MySQL på disken, så er det én fil på 1.2 TB der ændres, hver eneste gang der indsættes et nyt entry. Dermed går vores backup system fuldstændig i baglås, fordi for alle praktiske formål er en helt ny fil hver eneste dag, som derfor smides på off-site… Not good!

Min løsning indtil videre er at lave månedlig export til .sql fil og så smide den på off-site. Det har virket. Men det er stadig absurd meget data at smide over for de få ændringer der er per måned.

Spørgsmål: Kan man sætte MySQL op til at gemme visse table data i en separat filstruktur på HDD? Altså kan jeg bryde “imagedata” table ud, så alle entries i den, kommer til at ligge som enkeltstående filer på disken, seamless?

Og inden i foreslår incremental backup / export, så har jeg prøvet det. Og det virker, men er utroligt grimt! Og det kræver dobbelt diskplads på min server, da jeg jo skal exportere fuld sql så incremental derefter. Og bare tanken om at skulle genoprette fra det rod, nej tak.

Håber der er nogle MySQL wizards der har et bud på ovenstående spørgsmål. Tak! 🙂

Emne

[ElSenatorRusher#0 Trådstarter 579 Indlæg Offline]

I fornemmer nok iøvrigt at min post er lige dele “venting” og “brug for råd”. Så hvis i er uenige og mener at direkte kobling til MySQL bare er fantastisk i et multiclient setup, så fred være med det. Jeg skulle bare af med noget galde. Jeg tror 90% af det software vi får ind, der er det fuldstændig tåbeligt designet hvad angår bagvedliggende databaser.

[sunlockRusher 52 Indlæg Offline]

Jeg er på ingen måde ekspert i MySQL, men måske kunne partitionering være noget for dig/jer? Jeg kender ikke jeres implementering af databasen o.lign., men det er da værd at overveje:
https://dev.mysql.com/doc/refman/8.0/en/partitioning.html

[FiskerRusher 480 Indlæg Offline]

Hvad jeg kan se så ligner det ikke at den har noget á la Filestream som MSSQL har, ellers er du umiddelbart ude i at lave et view? Men jeg tænker det er en dårlig løsning da din software nok er afhængig af din database er i en specifik state, fx i forbindelse med opgraderinger, og så skal du sidde og manuelt ændre databasen hver gang der kommer et konfliktende database upgrade script.

[kazconRusher 16 Indlæg Offline]

Jeg er heller ikke MySQL-ekspert, men der er noget fundamentalt galt med opsætningen af databasen, hvis den placerer alt data i én fil.

Fra https://dev.mysql.com/doc/refman/8.0/en/innodb-file-space.html:

To avoid the issues that come with storing all tables and indexes inside the system tablespace, you can enable the innodb_file_per_table configuration option (the default), which stores each newly created table in a separate tablespace file (with extension .ibd). For tables stored this way, there is less fragmentation within the disk file, and when the table is truncated, the space is returned to the operating system rather than still being reserved by InnoDB within the system tablespace. For more information, see Section 15.6.3.2, “File-Per-Table Tablespaces”.

Jeg ser ikke problemet i et multiklient, med hver deres snabel i MySQL, såfremt de har hver deres kontekst (læs: databaser) som udgangspunkt. Der er noget mystisk hvis disse klienter alle skal bruge én og samme database. Jeg kan ikke forestille mig at den database performer særlig godt.

• Dette svar blev ændret 3 år, 2 måneder siden af kazcon.
• Dette svar blev ændret 3 år, 2 måneder siden af kazcon.

[ElSenatorRusher#0 Trådstarter 579 Indlæg Offline]

Tak for jeres input, jeg læser lidt op på det. Jeg faldt selv over partionering tidligere i dag da jeg researchede. Måske det kunne være noget. Jeg har også overvejet InnoDB compression.

[DeadlightsRusher 1321 Indlæg Offline]

Så vidt jeg husker ligger MySQL data i separate filer for hver tabel (f.eks. en fil til schema og en fil til data), og hvis der ændres i data på en tabel er det kun denne ene tabels filer der ændres.

[HumanRusher 72 Indlæg Offline]

Det er ikke kønt. Mne kan du ikke dedup client side inden backup foretages?

[dinirexRusher 55 Indlæg Offline]

Kunne man evt nøjes med at lave backup af transaction loggen?

[ElSenatorRusher#0 Trådstarter 579 Indlæg Offline]

#6, Desværre ikke for den her database. Den kan sættes op til det, men i netop dette tilfælde afhjælper det ikke problemet, da der én table der er over 1 TB (image rådata).

#8, Det vil minde lidt om incremental backup, så det har jeg egentlig prøvet. Det er noget værre rod, desværre.

#7, Jeg har aldrig prøvet at sætte noget i den retning op, men det er måske værd at undersøge. Tak!

[Snowball42Rusher 307 Indlæg Offline]

#9 Det er vel det IBM Tivoli i princippet er. 1 fuld backup, og herefter kun incremental. Så de kan da fint lade sig gøre hvis du har software der kan hjælpe.

Du kan vel bare lave f.eks. ugentlig fuld backup, og herefter gøre som #8 siger med at backup af binary log på db’en.

Det vil stadig ikke være perfekt.

Har leverandøren ikke software der kan snakke direkte ind i mysql’en ?

Alternativt hvis det godt må koste penge, så har MySQL deres Enterprise Backup, den kan lave incremental backups for dig, og også lave recovery in time. Så er det vel blot en hvad koster det nuværende backup af MySQL serveren vs. hvad vil det koste hvis der kun blev sendt det nødvendige videre. Om det så kan lade sig gøre med jeres backup provider.. tjaa..

[ElSenatorRusher#0 Trådstarter 579 Indlæg Offline]

#10, Mjah, det er ikke en god løsning, som nævnt har jeg prøvet det i en periode. For en DB på 1.2 TB skal man:

1. Eksportere hele lortet til en .sql fil én gang om ugen (som dog kan komprimeres lidt). Det kræver dermed næsten dobbelt diskplads på selve serveren.
2. Eksportere incremental changes i separate filer derudover for de resterende dage. Det kræver endnu mere ekstra diskplads.
3. Alt skal smides over netværk til Tivoli. Og én gang om ugen drejer det sig om 1.2 TB, selvom kun en meget lille del af data har ændret sig. Det tager timevis og kan ofte ikke nås før produktion starter igen. Dermed har man tabt.

Så det er ikke en løsning. Derfor jeg efterspørger en måde hvor man kan smide enkelte celledata fra en table ned i enkeltfiler på disken, så det kun er de nye filer der ændres. Dermed har man vundet.

Men efter en masse research og input fra de gode folk herinde, så har jeg efterhånden konkluderet at det kan man ikke.

Så… Udvikleren er, som altid, nogle hatte der ikke tænker sig om. Det er den daglige kamp som IT-administrator, at holde styr på andres elendigt udviklede software og backends.

EDIT: Det er i øvrigt ikke det Tivoli gør. Den overfører filer der har ændret sig, og alt efter hvilke regler der er sat på serveren, så bibeholder den tidligere version x antal bagud. Det er skidesmart for små normale filer. Men ikke for filer på 1.2 TB. Den kan ikke nøjes med at overføre ændringerne, for den kender jo ikke filen på serveren. Hvis den skulle det, så skulle den overføre og sammenligne dataene, og det er jo præcist det samme som at overføre hele filen. Om den så kun gemmer ændringen på selve serveren, det er, for mig, irrelevant.

[Forfatter]

Svar