Grote mysql database dumpen geeft teveel load

Script op 1 CPU scripten? Desnoods in een eigen protected environment?

[ Voor 48% gewijzigd door MAX3400 op 08-05-2006 16:23 ]

Wat voor DB's ? MyISAM ? innoDB ? Wat voor dumpopties ? etc, etc, etc.

Misschien is dit een heel stom idee, maar is het geen idee om we website 's nachts even plat te halen (MySQL ff lamleggen.)

/var/lib/mysql backuppen, en mysql weer te starten.. (dit mogelijk met behulp van een bash scriptje zodat het zo snel mogelijk gaat..)

Op deze manier maak k eigenlijk altijd mijn MySQL backup's, en dat werkt prima

Kun je het proces niet gewoon nicen?

Ik zou ze snachts stoppen, backuppen en weer starten Het restoren is ook sneller dan.

Op het werk hebben we enorm veel databases die we ook op die manier backuppen. (denk aan honderden, geen mysql of wat er op lijkt trouwens)

zomertje schreef op maandag 08 mei 2006 @ 22:50:
Ik zou ze snachts stoppen, backuppen en weer starten Het restoren is ook sneller dan.

Ik zou ze gewoon leeg-gooien. Hoef je ze
1) niet te stoppen
2) niet te backuppen
3) nooit te restoren

Scheelt veel in tijdswinst

Inderdaad wel een goeie vraag aan een serveradmin hier (Kees?), hoe ze hier MySQL backup's draaien


_{Om vervolgens t antwoord te krijgen:"Onze servers zijn uberstabiel, wij maken geen backup's"terug te krijgen}

SyS_ErroR schreef op dinsdag 09 mei 2006 @ 11:45:
Inderdaad wel een goeie vraag aan een serveradmin hier (Kees?), hoe ze hier MySQL backup's draaien

* nero355 is ook benieuwd : Dump op een PII 350 MHz was niet grappig met een 20 MB oid database Wat als die straks groter wordt ... help !!

_{Om vervolgens t antwoord te krijgen:"Onze servers zijn uberstabiel, wij maken geen backup's"terug te krijgen}

HD's crashen ook in stabiele server hoor

/EDIT : Oei bedenk net iets => @ Werk hier hebben we een Win2K3 server en die draait vrolijk zijn back-ups terwijl MS SQL server draait ... Open File Option oid gok ik dan ?? Ding draait perfect dus wil er liever niet aan zitten

[ Voor 26% gewijzigd door nero355 op 09-05-2006 11:53 ]

Ik doe hier ook wel eens backups van draaiende MySQL databases.
nice helpt bij mij wel en geeft toch bepaalde prioriteiten
nice -n 19 geeft automatisch de laagste prioriteit aan het dump proces. Je database wordt wel langzamer, maar de snelheid blijft acceptabel...

Eens kijken of ik Kees in de richting van dit topic kan schoppen, ik ben nu ook wel benieuwd hoe het vandaag de dag werkt bij tweakers.

backups?

Kees schreef op dinsdag 09 mei 2006 @ 17:04:
backups?

Wat zijn dat? Onze servers crashen toch nooit? (herinnert zich BC3 nog als de dag van gisteren )

Backups zijn voor mietjes!!

Uhm, maar wat Kees denk ik bedoelt, is dat gewoon het hele filesystem gebackuped wordt, en geen dump van de database.

Ja dan is je database misschien een tikje inconsistent daarna. Als het om een forum gaat, boeit dat dan echt ongelooflijk veel?

Zo ja, dan moet je hardware kopen die snapshots ondersteunt ofzo, of andere ingewikkelde database-setups in elkaar gaan sleutelen. Of offline backups maken, maar da's geen keuze zeg je zelf al. Btw. als je gewoon de files kopieert, moet 3 GB in een minuutje of 2 wel lukken right? Dus op zich, rustigste tijdstip van de dag kiezen en dan het forum 5 mins offline houden, tja....

[ Voor 70% gewijzigd door Wilke op 09-05-2006 17:11 ]

Aike schreef op maandag 08 mei 2006 @ 16:32:
Het dumpregeltje is zo.

code:

1	"/usr/bin/mysqldump -v -q -uroot -pwachtwoord ${DBASE} | gzip -c" > ${MYSQLDSTFILE}.sql.gz

Da's de helft van de info. Wat voor tabellen gebruik je ? InnoDB ? MyISAM ? wat anders ? Da's wel handig om te weten, aangezien je met issues als locking zit.

waren ze niet bezig om een replication server te maken (of hebben die misschien al in gebruik) waardoor een dump van de database niet (heel erg) nodig is?

(hoewel off-site een backup hebben natuurlijk wel beter is )

replicatie onder mysql zuigt keihard. De enige manier waarop dat kan is in memory, en da's ehm.. niet handig.

Volgens mij bestaat ons backupscript ook uit wat gerichte mysqldump-commando's.

Wij maken de backups elke nacht.

Backup van Apollo Gestart op 09-05-06 om 3:19:27

Samenvatting • Aantal databases 7 • Aantal tabellen 97 • Uncompressed 31 GB • Compressed 8 GB • Ratio 75.69% • Tijd 5430.78 seconden • Snelheid 6055 KB/s

Zoals je aan de statistieken op de FP kan zien is het forum niet elke nacht down, ergo, deze backups zijn niet consistent (vb: message table wordt eerst gebackupped, dan de topics table, als er tijdens die twee een nieuw topic geplaatst wordt, dan zal die wel in de topic backup zitten, maar niet in de message backup). Dit is haast niet te vermijden met mysql zonder het elke nacht plat te leggen voor 5400+ seconden (bijna 1.5 uur).

Het commando:
Ik dump dus per table, en de table definitie wordt in een eerder commando er al uit gehaald en apart opgeslagen in een file. De load e.d. kun je op de frontpage zien.

Het voordeel van per table dumpen is dat je minder data per keer hoeft te verwerken, en je het makkelijker kan restoren. Qua snelheid zal het niet heel veel uitmaken. Maargoed, dumpen kost nu eenmaal tijd en cpu cycles, en een xeon als database proc zou ik niemand aanraden (persoonlijke ervaringen). Overigens gebeurd dit allemaal vanaf een externe server, zodat de database alleen maar de zooi hoeft te dumpen, het compressen gebeurd op Athena Zoals je ziet is dat heel erg processor intensief, dus het verdient de voorkeur het op een tweede server te laten doen.

Het gaat om MySQL 5 op Debian. De grootste database is een forum. vBulletin Version 3.0.13 om precies te zijn. En er zitten ook nog een aantal andere databases in die zowel myisam als innodb zijn. Maakt dat veel uit?

Wel goed lezen

[ Voor 12% gewijzigd door jurp5 op 09-05-2006 17:19 ]

moto-moi schreef op dinsdag 09 mei 2006 @ 17:15:
replicatie onder mysql zuigt keihard. De enige manier waarop dat kan is in memory, en da's ehm.. niet handig.

Volgens mij bestaat ons backupscript ook uit wat gerichte mysqldump-commando's.

Het kan ook op de disk, maar dan heb je gaan master-master-master, maar alleen master-slave-slave, dus een server om op te schrijven, de rest om op te lezen. En het breekt te vaak naar mijn mening.

Als het alleen gaat om het back-uppen, is mysqlhotcopy een stuk geschikter dan mysqldump. Met mysqlhotcopy worden gewoon de databasebestanden op een veilige manier gekopieert (en dan hoef je dus niet alle data uit te lezen en te converteren).

Groot nadeel is dat die tool niet werkt voor InnoDB databases, maar misschien is het grootste deel van de tabellen wel MyISAM?

Hm, ik ben nog niet zo thuis in mysql. Maar Progress waar ik veel mee werk kan gewoon een online backup maken en snel ook. Blijkbaar is dat luxe

Naar mijn idee is het beter om het volgende te doen.

Snapshots te maken:
Je kiest voor een filesysteem wat het ondersteund volgens mij vas het xfs wat dit kon.
Dan zou je hem heel even kunnen down brengen, dan een snapshot en daarvan dan de backup maken.

Dat is van redelijk wat factoren afhankelijk.
Deze zijn op internet te vinden.

Ik zou even een proof of concept maken, dus........ ontwerpen/testen.
Het is naar mijn idee een van de makkelijkste opties, je hoeft niet persee down maar mischien kun je kan ook heel kort in read only mode gaan.

Analyseer de trend waar heb ik de minste load/bezoekers/afhankelijkheden.
Afhankelijk daarvan ga je plannen en ontwerpen van je backup strategie.

De situatie is te specifiek en te weinig info om echt een antwoord te kunnen geven.

Just curious, maar je zegt dat een downtime van meer dan ~10 sec. onacceptabel is. Om wat voor site gaat het in godsnaam? Ik kan echt niets bedenken. En als er dan zoveel geld in omgaat, dan kom je toch niet hier om te vragen hoe je dit oplost, dan huur je toch gewoon een prof in

Ik poste dit net in het HK topic, maar aangezien dit bijna hetzelfde is cross-post ik maar even hier:

Als je DB cluster software gebruikt zoals Sequoia ( http://sequoia.continuent.org/HomePage ), dan kun je gewoon 1 DB uit het cluster halen en die volledig (traditioneel) backuppen. Als je die DB bak dan later weer terugzet in het cluster wordt ie weer gesynched met de rest.

Nu is Sequoia maar 1 van dergelijke oplossingen, maar er zijn er vast meer. Oorspronkelijk is Sequoia een Java oplossing, maar tegenwoordig is het ook bruikbaar voor andere omgevingen. Een hele andere mogelijkheid is wellicht de streaming backup feature in PG 8.1. Ik heb hier nog nooit mee gewerkt, maar dit klinkt alsof er continu een incrementele backup wordt gemaakt. Je backup is dus altijd slechts enkele seconden tot minuten oud.

Wij zelf zitten ook met het backup probleem. Onze DB (PG 8.1) is een GB of 14 groot en de backup duurt een minuut of 20. Zelfs als geniced process is de load toename absoluut significant tijdens de backup tijden (we backupen 6 keer per dag). Vandaar dus dat we zeker willen gaan kijken naar die streaming backup feature of Sequoia (tot op heden nog geen tijd gehad daarvoor helaas).

Aike schreef op woensdag 10 mei 2006 @ 13:50:
[...]

Daar heb ik iets over gelezen. Zou dat ook met lvm gaan? Maar hoe lang moet je hem dan stoppen? Meer dan ~10sec is onacceptabel....

In de manual van mysql staat een voorbeeld met LVM.

You can also take very fast online or hot backups if you have linux volume management or LVM. You must have snapshots enabled. Basically follow the recipie given for veritas except use lvm. Of course your DB must live on a logical volume like /dev/vg01/mysql for example.

In a mysql shell (as root@unix and root@mysql):

mysql> flush tables with read lock;
mysql> flush logs;
mysql> system lvcreate --snapshot ?-size=500M --name=backup /dev/vg01/mysql;
mysql> unlock tables;

Then back in shell land (as root@unix):

$ mount -o ro /dev/vg01/backup /mnt/tmp
$ cd /mnt/tmp/
$ tar czf backup-`date +%Y%m%d`.tgz mysql
$ umount /mnt/tmp
$ lvremove -f /dev/vg01/backup