[MySQL] Back-up van 32GB+ MyIsam database

Pagina: 1
Acties:

  • BastiaanN
  • Registratie: September 2003
  • Niet online
Ik beheer nu al enige tijd een website die zich in het, door tweakers omgeschreven "grijze gebied" bevind. Ik ga verder niet in op het hoe of wat :) De gegevens van deze website blijven maximaal 140 dagen in de database staan en worden daarna verwijderd, elk uur komen er in deze database +/- 10.000 rijen bij en gaan er ook weer ongeveer 10.000 uit.

Ik probeer al enige tijd een goede back-up oplossing te vinden voor de database van deze website welke inmiddels al op 32,4GB zit. Door de hoeveelheid data wat er per uur in en uit gaat is een incrementele back-up bijna ondoenbaar.

De back-up gaat om het totaal plaatje, het is niet zo heel erg als we bijvoorbeeld 2 dagen aan data kwijtraken maar we willen niet dat we bijvoorbeeld de complete database kwijtraken door een harddisk crash.

Het probleem is dus dat,
  1. Een hardcopy bijna niet te doen is omdat de inhoud van de database met grote mate wijzigt.
  2. mysqldump bijna 2 dagen nodig heeft om een back-up te maken.
  3. Er bij replicatie alle wijzigingen 1-op-1 worden doorgevoerd naar een andere MySQL database.
  4. Door de hoeveelheid data is een incrementele back-up ook bijna niet te doen is
Ik heb wél de beschikking over 2 servers welke beide op een andere, fysieke locatie staan. (Groningen en Amsterdam)

Ten slotte nog even de specs van de server:

- Supermicro PDSMi+ Server Moederbord
- 2x Western Digital 160GB, SATA II, 8MB, 7200rpm
- Intel Pentium E2160, 1.8Ghz Dual Core, FSB800, 1MB, 32/64 bit, 65W
- 4096MB DDR-2 Geheugen

Wie o wie heeft de gouden tip voor mij? :)

Edit; Wellicht handig om te vermelden dat het gaat om MySQL versie 5.0.51a-community op een Centos 5 os.

Strava | :-( + ┌(^0^)┘= :-)


Verwijderd

BastiaanN schreef op zondag 26 oktober 2008 @ 12:12:
Ik beheer nu al enige tijd een website die zich in het, door tweakers omgeschreven "grijze gebied" bevind. Ik ga verder niet in op het hoe of wat :) De gegevens van deze website blijven maximaal 140 dagen in de database staan en worden daarna verwijderd, elk uur komen er in deze database +/- 10.000 rijen bij en gaan er ook weer ongeveer 10.000 uit.

Ik probeer al enige tijd een goede back-up oplossing te vinden voor de database van deze website welke inmiddels al op 32,4GB zit. Door de hoeveelheid data wat er per uur in en uit gaat is een incrementele back-up bijna ondoenbaar.

De back-up gaat om het totaal plaatje, het is niet zo heel erg als we bijvoorbeeld 2 dagen aan data kwijtraken maar we willen niet dat we bijvoorbeeld de complete database kwijtraken door een harddisk crash.

Het probleem is dus dat,
  1. Een hardcopy bijna niet te doen is omdat de inhoud van de database met grote mate wijzigt.
  2. mysqldump bijna 2 dagen nodig heeft om een back-up te maken.
  3. Er bij replicatie alle wijzigingen 1-op-1 worden doorgevoerd naar een andere MySQL database.
  4. Door de hoeveelheid data is een incrementele back-up ook bijna niet te doen is
Ik heb wél de beschikking over 2 servers welke beide op een andere, fysieke locatie staan. (Groningen en Amsterdam)

Ten slotte nog even de specs van de server:

- Supermicro PDSMi+ Server Moederbord
- 2x Western Digital 160GB, SATA II, 8MB, 7200rpm
- Intel Pentium E2160, 1.8Ghz Dual Core, FSB800, 1MB, 32/64 bit, 65W
- 4096MB DDR-2 Geheugen
Ik heb niet zoveel verstand van mysql databases maar ik zie een beetje een raar iets staan. Je schrijft dat je een mysqldump doet van 32 GB en daar 2 dagen mee bezig is ? Ik ken data bases welke een stuk drukker/groter zijn en draaien met MSsql en die kunnen het binnnen enkele uren. Hier zit echter een fatsoenlijk disksysteem onder dus ik denk dat je eens moet gaan kijken naar je sata systeem en deze vervangen door iets serieus sas achtigs met een echte hardware raid controller icm 15k rpm disken.

  • PerfectPC
  • Registratie: Februari 2004
  • Laatst online: 01-02 11:46
BastiaanN schreef op zondag 26 oktober 2008 @ 12:12:
• mysqldump bijna 2 dagen nodig heeft om een back-up te maken.

Ik heb wél de beschikking over 2 servers welke beide op een andere, fysieke locatie staan. (Groningen en Amsterdam)

- 2x Western Digital 160GB, SATA II, 8MB, 7200rpm
geen probleem toch?
- je schijven draaien in RAID1 (mag ik hopen !)
- je hebt een 2de server waar je je mysqldumps naar kan kopieren. ok ze zijn 2 dagen oud, maar dat was geen probleem had je al aangegeven
- als het echt HA moet zijn kan je hier eens gaan kijken: http://www.webhostingtalk.com/showthread.php?p=4898384

  • axis
  • Registratie: Juni 2000
  • Laatst online: 26-01-2023
Ik vind het ook een beetje vreemd dat mysqldump er zo lang over doet.. Nu ben ik ook alleen gewend aan MSSQL en machines met 10 15k disks in RAID10, waar ik hot backups maak over het netwerk met ongeveer 150GB/uur (40-50MBps).

Ik denk dat je misschien toch eens moet investeren in een fatsoenlijk disk-subsystem..

DAS cabinetje misschien idee?: V&A aangeboden: Sun D1000 + 12 X 36Gb SCSI 10K Of misschien even kijken op wht voor een fatsoenlijke 2e server, zoals een dual xeon doos met 6 of 8 disks..

Two advices for network troubleshooting.. learn to draw diagrams in Visio, and THINK IN LAYERS!


  • BastiaanN
  • Registratie: September 2003
  • Niet online
Het vreemde is wel dat als ik bijvoorbeeld een hotcopy doe, dit binnen 1,5 uur kan, echter krijg ik dan inconsistentie door de updater.

Maar misschien is het inderdaad verstanding om eens te kijken naar een ander disk-systeem.

[ Voor 25% gewijzigd door BastiaanN op 28-10-2008 09:30 ]

Strava | :-( + ┌(^0^)┘= :-)


  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 16:53

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

BastiaanN schreef op dinsdag 28 oktober 2008 @ 09:30:
Maar misschien is het inderdaad verstanding om eens te kijken naar een ander disk-systeem.
Ik ken CentOs niet, maar een bottleneck op je disksystem zou je toch terug moeten vinden in een of andere performance counter? Het lijkt mij handiger om een backup te starten en eens flink te meten waar nu precies de bottleneck zit.

Al vermoed ik ook wel dat je disk-system niet optimaal is voor een DB, zeker weten weet je het pas na meten. :)

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B

Pagina: 1