- Dette emne har 11 svar og 8 stemmer, og blev senest opdateret for 3 Är, 8 mÄneder siden af ElSenator.
-
Emne
-
ElSenator
- E-peen: 579
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! đ
ElSenator-
Svar
-
- E-peen: 579
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.
sunlock
- E-peen: 52
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.htmlFisker
- E-peen: 615
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.
kazcon
- E-peen: 16
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, 8 mÄneder siden af kazcon.
- Dette svar blev Êndret 3 Är, 8 mÄneder siden af kazcon.
- E-peen: 579
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.
Deadlights
- E-peen: 1,431
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.
Human
- E-peen: 72
Det er ikke kĂžnt. Mne kan du ikke dedup client side inden backup foretages?
dinirex
- E-peen: 55
Kunne man evt nĂžjes med at lave backup af transaction loggen?
- E-peen: 579
#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!
Snowball42
- E-peen: 399
#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..
- E-peen: 579
#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.
Fisker
Human- Du skal vĂŠre logget ind som bruger for at kunne svare...